From ecrit-bounces@ietf.org Fri Oct 3 06:31:33 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02BF83A68E1; Fri, 3 Oct 2008 06:31:33 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34E2D3A68EE for ; Fri, 3 Oct 2008 06:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRvwm09nV5CX for ; Fri, 3 Oct 2008 06:31:31 -0700 (PDT) Received: from mail-gx0-f16.google.com (mail-gx0-f16.google.com [209.85.217.16]) by core3.amsl.com (Postfix) with ESMTP id 6EBC23A6452 for ; Fri, 3 Oct 2008 06:31:30 -0700 (PDT) Received: by gxk9 with SMTP id 9so2520852gxk.13 for ; Fri, 03 Oct 2008 06:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=T3AwmztumfUQqK/JfNwZt+TBO9e3ubgie6YFnMqt2Y8=; b=AajK0Gmk+ucZJSY3jBBhKsuK8WdwQYYGTBwAXriwDRiA7cAtr2XtBgoPCfhkCv+u4Y 6gEREzkpRiJE3kIEU6EHc+ftTor9WgRf1KN+OYLm/AiEcCRdm/QVvfuHApiN1LOyj2zN 5n2ZtLobgUMHh6usJbvRsIq+B7V/LAzJZGrTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=TkOZY4at/5ohJf383cZXhpEG0YBvBNM/xdsrsIpD99zJ7qYs8gn8c0uIA9td2NqyDU 98kcHpEC/ueiXDxHmuClZoa9RicRBJdWm5OO+P3qfKdyz683MWDp86u5uyk9lOpPq5H/ rTOVsu0f5FeUwh2ST02U6GU5NBryuYOmGWCgw= Received: by 10.150.202.9 with SMTP id z9mr1861767ybf.203.1223040718001; Fri, 03 Oct 2008 06:31:58 -0700 (PDT) Received: by 10.150.140.2 with HTTP; Fri, 3 Oct 2008 06:31:57 -0700 (PDT) Message-ID: <385b0c950810030631m10a6e47ehd07dc417700fa528@mail.gmail.com> Date: Fri, 3 Oct 2008 09:31:57 -0400 From: "John-Luc Bakker" To: ECRIT In-Reply-To: <48CE0D9F.8080406@gmx.net> MIME-Version: 1.0 Content-Disposition: inline References: <48CE0D9F.8080406@gmx.net> Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Milan, The proposed new URI parameter is opaque. It marks the call as an emergency call but fails to convey the emergency call type even if an emergency call type could be deduced from the original request. Particularly if the Emergency Service URN in the Request-URI is replaced by a network entity, as you suggest, not loosing the emergency call type information seems useful. In some deployments, emergency calls are routed to PSAPs that support the requested emergency types. Kind regards, John-Luc On Mon, Sep 15, 2008 at 3:24 AM, Hannes Tschofenig wrote: > Please take a look at this document. Milan would like to hear some comments! > > Ciao > Hannes > > -------- Original Message -------- > Subject: I-D Action:draft-patel-ecrit-sos-parameter-00.txt > Date: Fri, 12 Sep 2008 09:45:01 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : SOS Uniform Resource Identifier (URI) parameter for marking of Session Initiation Protocol (SIP) requests related to emergency services > Author(s) : M. Patel > Filename : draft-patel-ecrit-sos-parameter-00.txt > Pages : 9 > Date : 2008-09-12 > > This memo describes requirements and protocol conventions for a new > SIP (Session Initiation Protocol) URI parameter intended for marking > SIP requests and responses related to emergency services. This > proposal addresses issues that exist in the current 3rd Generation > Partnership Project IP Multimedia Subsystem (IMS) Emergency services > solution, but is not precluded from being used by other SIP-based > emergency services solutions. It is not intended as a replacement > for the service URN. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-parameter-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 3 06:45:06 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19B843A67F4; Fri, 3 Oct 2008 06:45:06 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55CF3A67F4 for ; Fri, 3 Oct 2008 06:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wMwJFJ3D2hJ for ; Fri, 3 Oct 2008 06:44:57 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 52FBA3A67B4 for ; Fri, 3 Oct 2008 06:44:55 -0700 (PDT) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m93DjL500822; Fri, 3 Oct 2008 13:45:21 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 3 Oct 2008 14:45:08 +0100 Message-ID: <0913B6CD18F370498CD65864CF254E9006BFCF94@zharhxm1.corp.nortel.com> In-Reply-To: <385b0c950810030631m10a6e47ehd07dc417700fa528@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] Thread-Index: AcklXM0v3DWcQkerSz+0dKuGXD4ZiQAACaKA From: "Milan Patel" To: "John-Luc Bakker" , "ECRIT" Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi John-Luc, Currently the draft only specifies that the "sos" parameter only conveys information that the request/response is related to an emergency session. But I do find your use case valid. I'd like to know what others think, but can propose the extension in version-01 if there is wider support. Best regards, Milan -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of John-Luc Bakker Sent: 03 October 2008 14:32 To: ECRIT Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] Milan, The proposed new URI parameter is opaque. It marks the call as an emergency call but fails to convey the emergency call type even if an emergency call type could be deduced from the original request. Particularly if the Emergency Service URN in the Request-URI is replaced by a network entity, as you suggest, not loosing the emergency call type information seems useful. In some deployments, emergency calls are routed to PSAPs that support the requested emergency types. Kind regards, John-Luc On Mon, Sep 15, 2008 at 3:24 AM, Hannes Tschofenig wrote: > Please take a look at this document. Milan would like to hear some comments! > > Ciao > Hannes > > -------- Original Message -------- > Subject: I-D Action:draft-patel-ecrit-sos-parameter-00.txt > Date: Fri, 12 Sep 2008 09:45:01 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : SOS Uniform Resource Identifier (URI) parameter for marking of Session Initiation Protocol (SIP) requests related to emergency services > Author(s) : M. Patel > Filename : draft-patel-ecrit-sos-parameter-00.txt > Pages : 9 > Date : 2008-09-12 > > This memo describes requirements and protocol conventions for a new > SIP (Session Initiation Protocol) URI parameter intended for marking > SIP requests and responses related to emergency services. This > proposal addresses issues that exist in the current 3rd Generation > Partnership Project IP Multimedia Subsystem (IMS) Emergency services > solution, but is not precluded from being used by other SIP-based > emergency services solutions. It is not intended as a replacement > for the service URN. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-parameter-00.t xt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 3 08:15:00 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990F93A6AC4; Fri, 3 Oct 2008 08:15:00 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47EBF3A6859 for ; Fri, 3 Oct 2008 08:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fi0MoJyQhOyA for ; Fri, 3 Oct 2008 08:14:58 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 0BE673A6B50 for ; Fri, 3 Oct 2008 08:14:58 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KlmMp-0007NK-Qz; Fri, 03 Oct 2008 10:14:56 -0500 From: "Brian Rosen" To: "'Milan Patel'" , "'John-Luc Bakker'" , "'ECRIT'" References: <385b0c950810030631m10a6e47ehd07dc417700fa528@mail.gmail.com> <0913B6CD18F370498CD65864CF254E9006BFCF94@zharhxm1.corp.nortel.com> In-Reply-To: <0913B6CD18F370498CD65864CF254E9006BFCF94@zharhxm1.corp.nortel.com> Date: Fri, 3 Oct 2008 11:14:56 -0400 Message-ID: <019801c9256a$cd661430$68323c90$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcklXM0v3DWcQkerSz+0dKuGXD4ZiQAACaKAAALu2NA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I am still opposed to this mechanism. There seems to be four threads here: 1. Marking an emergency registration 2. Keeping the Route header with the sos urn on the call as far as it needs to go 3. Making the UA aware of an emergency call when it didn't recognize that itself 4. Marking a call back I recognize a need to mark an emergency registration. As before, I'm not convinced this is the best solution, but there is a problem that needs to be solved. I see no reason why the Route header with the sos urn does not get put on the call as soon as it is recognized, and remain on the call until it gets to the last SIP hop (a gateway in the case that is being discussed, a PSAP if the call is terminated in PS). Leave the Route header on, and use that as the marking. The UA should recognize the emergency call. If you are planning a system where you know it won't, fix that. Having a backup mechanism is okay. The way to alert the UA is to redirect the call to urn:service:sos. Then the UA knows it's an emergency call. Call backs have not yet really been addressed well, but "recognize the domain" works. It works for everyone: it works for the gateway, it works for a proxy, it works for the UA if the UA knows it was an emergency call. I will say that I would prefer a more specific marking for a call back. I'd prefer to have a comprehensive discussion of call backs and make sure we have all the parts dealt with. I will say this: there are two kinds of call backs. One is immediate, when a call is lost, or while the call is being handled more information is needed. The address used for that is the Contact, not the AoR. The latter is a follow up call placed later, and does use AoR (or P-A-I). The former needs marking, the latter doesn't. It may be that we make that the URI in Contact is distinguished in some way that lets us know that this is a call back of an emergency call. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Milan Patel Sent: Friday, October 03, 2008 9:45 AM To: John-Luc Bakker; ECRIT Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] Hi John-Luc, Currently the draft only specifies that the "sos" parameter only conveys information that the request/response is related to an emergency session. But I do find your use case valid. I'd like to know what others think, but can propose the extension in version-01 if there is wider support. Best regards, Milan -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of John-Luc Bakker Sent: 03 October 2008 14:32 To: ECRIT Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] Milan, The proposed new URI parameter is opaque. It marks the call as an emergency call but fails to convey the emergency call type even if an emergency call type could be deduced from the original request. Particularly if the Emergency Service URN in the Request-URI is replaced by a network entity, as you suggest, not loosing the emergency call type information seems useful. In some deployments, emergency calls are routed to PSAPs that support the requested emergency types. Kind regards, John-Luc On Mon, Sep 15, 2008 at 3:24 AM, Hannes Tschofenig wrote: > Please take a look at this document. Milan would like to hear some comments! > > Ciao > Hannes > > -------- Original Message -------- > Subject: I-D Action:draft-patel-ecrit-sos-parameter-00.txt > Date: Fri, 12 Sep 2008 09:45:01 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : SOS Uniform Resource Identifier (URI) parameter for marking of Session Initiation Protocol (SIP) requests related to emergency services > Author(s) : M. Patel > Filename : draft-patel-ecrit-sos-parameter-00.txt > Pages : 9 > Date : 2008-09-12 > > This memo describes requirements and protocol conventions for a new > SIP (Session Initiation Protocol) URI parameter intended for marking > SIP requests and responses related to emergency services. This > proposal addresses issues that exist in the current 3rd Generation > Partnership Project IP Multimedia Subsystem (IMS) Emergency services > solution, but is not precluded from being used by other SIP-based > emergency services solutions. It is not intended as a replacement > for the service URN. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-parameter-00.t xt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 6 08:52:56 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6913A67FC; Mon, 6 Oct 2008 08:52:56 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDBA13A688C for ; Mon, 6 Oct 2008 08:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bOTEaEGbZeZ for ; Mon, 6 Oct 2008 08:52:54 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7276E3A66B4 for ; Mon, 6 Oct 2008 08:52:52 -0700 (PDT) Received: (qmail invoked by alias); 06 Oct 2008 15:53:27 -0000 Received: from unknown (EHLO [10.183.181.235]) [192.100.124.156] by mail.gmx.net (mp017) with SMTP; 06 Oct 2008 17:53:27 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX189JeMrAqQ9URCk4HiQCYGnkjxzX+ML0QBaxLIFZ8 fq5FkJoCKKlR9a Message-ID: <48EA3476.6000806@gmx.net> Date: Mon, 06 Oct 2008 18:53:26 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 Subject: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, we had a chat with Jon on how to make some progress on the subject of "Premature Call Termination" and here is the plan we came up with: * We delete the sentence that talks about the UAC not generating a BYE request in http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt We progress the document through the IETF process as "planned". * At the same time we create a design team in ECRIT to work on "Premature Call Termination". Depending on the progress of the design team we are able to incorporate the results of it into the document (even at a fairly late stage of the document process). If the design team does not produce results then anything that comes out of it can be seen as an extension to the Phone BCP document. We need members for the design team! We have already received the commitment of folks from NENA but we also need some guys from the ECRIT group. Who is interested in participating? Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 6 11:17:56 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E9D3A69DD; Mon, 6 Oct 2008 11:17:56 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2E73A69DD for ; Mon, 6 Oct 2008 11:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.562 X-Spam-Level: X-Spam-Status: No, score=-105.562 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfP4h4ZRJBZF for ; Mon, 6 Oct 2008 11:17:50 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 958453A6AD4 for ; Mon, 6 Oct 2008 11:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1223317107; x=1254853107; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<48EA3476.6000806@gmx.ne t>|References:=20<48EA3476.6000806@gmx.net>|Date:=20Mon, =206=20Oct=202008=2011:16:49=20-0700|To:=20Hannes=20Tscho fenig=20,=20"'ECRIT'"=20|From:=20Ted=20Hardie=20 |Subject:=20Re:=20[Ecrit]=20IETF=20ECRIT=20Design=20Team =20on=20Premature=20Call=20Termination|Content-Type:=20te xt/plain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5300,2777,5399"=3B=20a=3D"10132220"; bh=WqU/JYBk+Y5BEZlgddFJqG9fcSykkjYsj0HbBaRj0Rs=; b=f3sLz1uRsOYcBhghDd+la90EDe7NoKAbMqcPlmc4MvTRsVbzuTS1nv+V n8//peU2aC1MA++K451SgC5CWdqeweXUjup8hu8emO7NwW50EAKIsmO55 MtW++FX+LLPim37nBCpviuO5lZwVRuzahGHhbw44HfMiyUXjiV+HXqcX3 o=; X-IronPort-AV: E=McAfee;i="5300,2777,5399"; a="10132220" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Oct 2008 11:17:37 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m96IHaqm021167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Oct 2008 11:17:36 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m96IHWrI022332 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 6 Oct 2008 11:17:36 -0700 Received: from [10.227.68.106] (10.227.68.106) by qcmail1.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 6 Oct 2008 11:16:52 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <48EA3476.6000806@gmx.net> References: <48EA3476.6000806@gmx.net> Date: Mon, 6 Oct 2008 11:16:49 -0700 To: Hannes Tschofenig , "'ECRIT'" From: Ted Hardie Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > >* At the same time we create a design team in ECRIT to work on >"Premature Call Termination". This seems to me to presume a fundamental requirement and to define the terms in a way that isn't appropriate. Can we define the deliverables, to clear this up? For example, could the design team reasonably determine that call termination in SIP-based systems was fundamentally different from the wireline and that wireline models of what "premature" meant did not apply? Or does this presume the Canadian requirements as a new, global requirement? Or does this include some negotiation phase requirement that didn't exist before? >Depending on the progress of the design team we are able to incorporate >the results of it into the document (even at a fairly late stage >of the document process). If the design team does not produce results >then anything that comes out of it can be seen as an extension to the >Phone BCP document. Any design team document that does not go through the full IETF process can expect an appeal. This isn't the role of design teams--they make proposals to a working group, which then has every opportunity to review them as it would any other input. The same is true for IETF Last Call review. Assuming that the results of this can be incorporated into a document that has already passed IESG review without updating that document and going through the process is just not how things work. >We need members for the design team! We have already received the >commitment of folks from NENA but we also need some guys from the ECRIT >group. Who is interested in participating? Sorry, maybe I have misunderstood this totally. How do you have volunteers from NENA for an IETF document without having announced the need before today? Are you planning this as a design team to help NENA define a requirement in its own documents? Or is this meant to produce an IETF document? If a NENA document, my discussion of design teams is off-base, and I apologize, but it would be useful to identify the target here. thanks, Ted >Ciao >Hannes & Marc > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 6 11:27:11 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD833A69B8; Mon, 6 Oct 2008 11:27:11 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3153A69B8 for ; Mon, 6 Oct 2008 11:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8kH+aPFAE20 for ; Mon, 6 Oct 2008 11:27:09 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id DDCB53A68AE for ; Mon, 6 Oct 2008 11:27:08 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m96IR477008797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 6 Oct 2008 14:27:05 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Hannes Tschofenig In-Reply-To: <48EA3476.6000806@gmx.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 6 Oct 2008 14:27:04 -0400 References: <48EA3476.6000806@gmx.net> X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree with Ted's concerns. In particular, "premature call termination" has never been defined precisely and many of the fears are based on the old single-line physical phone model which just don't apply here. Carrying forward notions that apply to black phones with rotary dials just seems unhelpful. In particular, the topic is strongly connected to call-back and should not be treated in isolation. Henning On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote: > Hi all, > > we had a chat with Jon on how to make some progress on the subject > of "Premature Call Termination" and here is the plan we came up with: > > * We delete the sentence that talks about the UAC not generating a > BYE request in > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt > We progress the document through the IETF process as "planned". > > * At the same time we create a design team in ECRIT to work on > "Premature Call Termination". > > Depending on the progress of the design team we are able to > incorporate the results of it into the document (even at a fairly > late stage > of the document process). If the design team does not produce > results then anything that comes out of it can be seen as an > extension to the > Phone BCP document. > > We need members for the design team! We have already received the > commitment of folks from NENA but we also need some guys from the > ECRIT group. Who is interested in participating? > > Ciao > Hannes & Marc > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 6 12:16:51 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7FD528C20A; Mon, 6 Oct 2008 12:16:51 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E50A28C20A for ; Mon, 6 Oct 2008 12:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSJH97VZmscQ for ; Mon, 6 Oct 2008 12:16:50 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 7395A28C135 for ; Mon, 6 Oct 2008 12:16:50 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KmvZT-0008Gk-9J; Mon, 06 Oct 2008 14:16:43 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Hannes Tschofenig'" References: <48EA3476.6000806@gmx.net> In-Reply-To: Date: Mon, 6 Oct 2008 15:16:51 -0400 Message-ID: <02eb01c927e8$18468320$48d38960$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ackn4TlYGfmZ71DdRfOBXVz056y4PQABmv6A Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It was defined in draft-rosen-ecrit-abpd-reqs-00. It was: when on an emergency call, a caller hangs up the call before the call taker is finished acquiring enough information. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, October 06, 2008 2:27 PM To: Hannes Tschofenig Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination I agree with Ted's concerns. In particular, "premature call termination" has never been defined precisely and many of the fears are based on the old single-line physical phone model which just don't apply here. Carrying forward notions that apply to black phones with rotary dials just seems unhelpful. In particular, the topic is strongly connected to call-back and should not be treated in isolation. Henning On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote: > Hi all, > > we had a chat with Jon on how to make some progress on the subject > of "Premature Call Termination" and here is the plan we came up with: > > * We delete the sentence that talks about the UAC not generating a > BYE request in > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt > We progress the document through the IETF process as "planned". > > * At the same time we create a design team in ECRIT to work on > "Premature Call Termination". > > Depending on the progress of the design team we are able to > incorporate the results of it into the document (even at a fairly > late stage > of the document process). If the design team does not produce > results then anything that comes out of it can be seen as an > extension to the > Phone BCP document. > > We need members for the design team! We have already received the > commitment of folks from NENA but we also need some guys from the > ECRIT group. Who is interested in participating? > > Ciao > Hannes & Marc > > _______________________________________________ > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 6 13:00:30 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2303A6804; Mon, 6 Oct 2008 13:00:30 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36F083A676A for ; Mon, 6 Oct 2008 13:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wKmRgdThgsd for ; Mon, 6 Oct 2008 13:00:27 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1AB813A6804 for ; Mon, 6 Oct 2008 13:00:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,368,1220227200"; d="scan'208";a="169837471" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Oct 2008 20:01:04 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m96K14OK008782; Mon, 6 Oct 2008 13:01:04 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m96K14kC011875; Mon, 6 Oct 2008 20:01:04 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 13:01:03 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.73.33]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 13:01:03 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 06 Oct 2008 15:01:20 -0500 To: "Brian Rosen" , "'Henning Schulzrinne'" , "'Hannes Tschofenig'" From: "James M. Polk" In-Reply-To: <02eb01c927e8$18468320$48d38960$@net> References: <48EA3476.6000806@gmx.net> <02eb01c927e8$18468320$48d38960$@net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 06 Oct 2008 20:01:03.0114 (UTC) FILETIME=[42AD8EA0:01C927EE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3173; t=1223323264; x=1224187264; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20IETF=20ECRIT=20Design=20Team= 20on=20Premature=20Call=0A=20=20Termination |Sender:=20; bh=pyLZcGhNd5Ig3SVv8MAfO5gM4PCUWxrIKUriCIkyJm4=; b=dZnqbXh5/hCQwYw98T9cwAW5SKWIjhYCA/cIyC+BxqamOq/CTYzFjf1nWB FGAwAEWnoX0x2A5Iv50Rtiy68HWmVvXTjMW24K3aijIPgdIXemv7pHjXY0UK c0b+Ot1NJ4; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This sounds a bit like a subjective thing, verses a quantifiable definitive thing. How exactly does a UAC know when it has achieved this status (i.e., provided enough information)? I assume the goal is to have something in signaling that communicates this to the UAC, right? Or is this merely at the discretion of the called party (i.e., the call taker's personal satisfaction)? Where I'm going with this is that I'm beginning to wonder if, then how a signaling protocol document should address this, or should this not be dealt with in signaling (which is nearly 100% of what we are defining -- only!) IMO... James At 02:16 PM 10/6/2008, Brian Rosen wrote: >It was defined in draft-rosen-ecrit-abpd-reqs-00. It was: >when on an emergency call, a caller hangs up the call before the call taker >is finished acquiring enough information. > >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >Henning Schulzrinne >Sent: Monday, October 06, 2008 2:27 PM >To: Hannes Tschofenig >Cc: 'ECRIT' >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > >I agree with Ted's concerns. In particular, "premature call >termination" has never been defined precisely and many of the fears >are based on the old single-line physical phone model which just don't >apply here. Carrying forward notions that apply to black phones with >rotary dials just seems unhelpful. In particular, the topic is >strongly connected to call-back and should not be treated in isolation. > >Henning > >On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote: > > > Hi all, > > > > we had a chat with Jon on how to make some progress on the subject > > of "Premature Call Termination" and here is the plan we came up with: > > > > * We delete the sentence that talks about the UAC not generating a > > BYE request in > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt > > We progress the document through the IETF process as "planned". > > > > * At the same time we create a design team in ECRIT to work on > > "Premature Call Termination". > > > > Depending on the progress of the design team we are able to > > incorporate the results of it into the document (even at a fairly > > late stage > > of the document process). If the design team does not produce > > results then anything that comes out of it can be seen as an > > extension to the > > Phone BCP document. > > > > We need members for the design team! We have already received the > > commitment of folks from NENA but we also need some guys from the > > ECRIT group. Who is interested in participating? > > > > Ciao > > Hannes & Marc > > > > _______________________________________________ > > 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 > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 6 13:39:39 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E19928C1F4; Mon, 6 Oct 2008 13:39:39 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8246F28C1BA for ; Mon, 6 Oct 2008 13:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.769 X-Spam-Level: X-Spam-Status: No, score=-105.769 tagged_above=-999 required=5 tests=[AWL=0.830, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhevcHsLu0+w for ; Mon, 6 Oct 2008 13:39:37 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 87A0D28C1F4 for ; Mon, 6 Oct 2008 13:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1223325614; x=1254861614; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<02eb01c927e8$18468320$4 8d38960$@net>|References:=20<48EA3476.6000806@gmx.net>=0D =0A=20=0D=0A=20<02eb01c927e8$18468320$48d38960$@net>|Date: =20Mon,=206=20Oct=202008=2013:40:06=20-0700|To:=20Brian =20Rosen=20,=0D=0A=20=20=20=20=20=20 =20=20"'Henning=20Schulzrinne'"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"'Hannes=20Tschofenig' "=20|From:=20Ted=20Hardie=20|Subject:=20Re:=20[Ecrit]=20IETF=20ECR IT=20Design=20Team=20on=20Premature=20Call=20Termination |CC:=20"'ECRIT'"=20|Content-Type:=20text/ plain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcAf ee=3Bi=3D"5300,2777,5399"=3B=20a=3D"10144327"; bh=3/G/Bm5VpW5mHiPyuQjtco0MiQmBrJ+xwE3IWJ68T3k=; b=FYqnKPTrVjBvdIZrl1nqILlCh2ca26yOy4JLh94t5Wd4I+FsJwNvwcBm axRD+hY23x4j3y20BxwvX5qGQ4uYQpYx/+EWGV2KKhd5FDjyXZVena3c2 vAO18hMIkhO7/PlUTy9pAYMz+0MeJt6EzVP+7uI13+M7HIIutuN7YGSTd U=; X-IronPort-AV: E=McAfee;i="5300,2777,5399"; a="10144327" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Oct 2008 13:40:12 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m96KeBjl014326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Oct 2008 13:40:11 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m96KeB5R028994 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 6 Oct 2008 13:40:11 -0700 Received: from [10.227.68.106] (10.227.68.106) by qcmail1.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 6 Oct 2008 13:40:10 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <02eb01c927e8$18468320$48d38960$@net> References: <48EA3476.6000806@gmx.net> <02eb01c927e8$18468320$48d38960$@net> Date: Mon, 6 Oct 2008 13:40:06 -0700 To: Brian Rosen , "'Henning Schulzrinne'" , "'Hannes Tschofenig'" From: Ted Hardie Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 12:16 PM -0700 10/6/08, Brian Rosen wrote: >It was defined in draft-rosen-ecrit-abpd-reqs-00. The tracker does not find that draft; it does find: draft-rosen-ecrit-premature-disconnect-rqmts-00.txt Is that the one you meant? I do not believe we have WG consensus on that document; John Hearty had comments on it, as did Keith Drage and James Polk (at least judging by the thread "Let's make some decisions regarding draft-rosen-ecrit-premature-disconnect-reqmts", which is the only one discussing I find in my personal archives). None of those seems to have been addressed; nor have the comments I made on the issue in Dublin. These were minuted, and Hannes copied the relevant minutes to the list under the title "Premature Disconnect (feedback from the meeting)". Is the design team, then, going to work with Brian to settle the requirements? Because if we don't have consensus on the requirements, the design team seems to have a hard row to hoe. regards, Ted > It was: >when on an emergency call, a caller hangs up the call before the call taker >is finished acquiring enough information. > >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >Henning Schulzrinne >Sent: Monday, October 06, 2008 2:27 PM >To: Hannes Tschofenig >Cc: 'ECRIT' >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > >I agree with Ted's concerns. In particular, "premature call >termination" has never been defined precisely and many of the fears >are based on the old single-line physical phone model which just don't >apply here. Carrying forward notions that apply to black phones with >rotary dials just seems unhelpful. In particular, the topic is >strongly connected to call-back and should not be treated in isolation. > >Henning > >On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote: > >> Hi all, >> >> we had a chat with Jon on how to make some progress on the subject >> of "Premature Call Termination" and here is the plan we came up with: >> >> * We delete the sentence that talks about the UAC not generating a >> BYE request in >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt >> We progress the document through the IETF process as "planned". >> >> * At the same time we create a design team in ECRIT to work on >> "Premature Call Termination". >> >> Depending on the progress of the design team we are able to >> incorporate the results of it into the document (even at a fairly >> late stage >> of the document process). If the design team does not produce >> results then anything that comes out of it can be seen as an >> extension to the >> Phone BCP document. >> >> We need members for the design team! We have already received the >> commitment of folks from NENA but we also need some guys from the >> ECRIT group. Who is interested in participating? >> >> Ciao >> Hannes & Marc >> >> _______________________________________________ >> 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 > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 6 14:20:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AACC3A69F2; Mon, 6 Oct 2008 14:20:45 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39CD83A676A for ; Mon, 6 Oct 2008 14:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOtwoisBDFY8 for ; Mon, 6 Oct 2008 14:20:43 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 3E1E83A69F2 for ; Mon, 6 Oct 2008 14:20:43 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KmxVv-00078U-En; Mon, 06 Oct 2008 16:21:11 -0500 From: "Brian Rosen" To: "'James M. Polk'" , "'Henning Schulzrinne'" , "'Hannes Tschofenig'" References: <48EA3476.6000806@gmx.net> <02eb01c927e8$18468320$48d38960$@net> In-Reply-To: Date: Mon, 6 Oct 2008 17:21:20 -0400 Message-ID: <034401c927f9$7c1041f0$7430c5d0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ackn7mBpsNy08kg3Qwq91ApWs0OP0QACul+g Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org No, actually, it's pretty precise. It's "premature" unless the PSAP says otherwise (that is, if the caller attempts to disconnect before the PSAP does, then it's a premature disconnect). Brian -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Monday, October 06, 2008 4:01 PM To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig' Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination This sounds a bit like a subjective thing, verses a quantifiable definitive thing. How exactly does a UAC know when it has achieved this status (i.e., provided enough information)? I assume the goal is to have something in signaling that communicates this to the UAC, right? Or is this merely at the discretion of the called party (i.e., the call taker's personal satisfaction)? Where I'm going with this is that I'm beginning to wonder if, then how a signaling protocol document should address this, or should this not be dealt with in signaling (which is nearly 100% of what we are defining -- only!) IMO... James At 02:16 PM 10/6/2008, Brian Rosen wrote: >It was defined in draft-rosen-ecrit-abpd-reqs-00. It was: >when on an emergency call, a caller hangs up the call before the call taker >is finished acquiring enough information. > >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >Henning Schulzrinne >Sent: Monday, October 06, 2008 2:27 PM >To: Hannes Tschofenig >Cc: 'ECRIT' >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > >I agree with Ted's concerns. In particular, "premature call >termination" has never been defined precisely and many of the fears >are based on the old single-line physical phone model which just don't >apply here. Carrying forward notions that apply to black phones with >rotary dials just seems unhelpful. In particular, the topic is >strongly connected to call-back and should not be treated in isolation. > >Henning > >On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote: > > > Hi all, > > > > we had a chat with Jon on how to make some progress on the subject > > of "Premature Call Termination" and here is the plan we came up with: > > > > * We delete the sentence that talks about the UAC not generating a > > BYE request in > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt > > We progress the document through the IETF process as "planned". > > > > * At the same time we create a design team in ECRIT to work on > > "Premature Call Termination". > > > > Depending on the progress of the design team we are able to > > incorporate the results of it into the document (even at a fairly > > late stage > > of the document process). If the design team does not produce > > results then anything that comes out of it can be seen as an > > extension to the > > Phone BCP document. > > > > We need members for the design team! We have already received the > > commitment of folks from NENA but we also need some guys from the > > ECRIT group. Who is interested in participating? > > > > Ciao > > Hannes & Marc > > > > _______________________________________________ > > 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 > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 6 15:45:06 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1183A6B24; Mon, 6 Oct 2008 15:45:06 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093F73A6B24 for ; Mon, 6 Oct 2008 15:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXtelVf8IBTK for ; Mon, 6 Oct 2008 15:45:04 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id E6FC63A6804 for ; Mon, 6 Oct 2008 15:45:03 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m96MjTQt017431; Mon, 6 Oct 2008 17:45:29 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 17:45:29 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Oct 2008 00:45:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 00:45:25 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180023B0173@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Thread-Index: Ackn4UrEly4wcLPaRhO29+Va7KSyDQAIV5Sg References: <48EA3476.6000806@gmx.net> From: "DRAGE, Keith \(Keith\)" To: "Henning Schulzrinne" , "Hannes Tschofenig" X-OriginalArrivalTime: 06 Oct 2008 22:45:26.0187 (UTC) FILETIME=[39870FB0:01C92805] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: ECRIT Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I believe the previous agreement was that we would get the requirements drafted, and then decide whether there was consensus to implement those requirements. I do not see in Hannes mail any incorporation of this into the process. Regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Henning Schulzrinne > Sent: Monday, October 06, 2008 7:27 PM > To: Hannes Tschofenig > Cc: 'ECRIT' > Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call > Termination > > I agree with Ted's concerns. In particular, "premature call > termination" has never been defined precisely and many of the > fears are based on the old single-line physical phone model > which just don't apply here. Carrying forward notions that > apply to black phones with rotary dials just seems unhelpful. > In particular, the topic is strongly connected to call-back > and should not be treated in isolation. > > Henning > > On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote: > > > Hi all, > > > > we had a chat with Jon on how to make some progress on the > subject of > > "Premature Call Termination" and here is the plan we came up with: > > > > * We delete the sentence that talks about the UAC not > generating a BYE > > request in > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt > > We progress the document through the IETF process as "planned". > > > > * At the same time we create a design team in ECRIT to work on > > "Premature Call Termination". > > > > Depending on the progress of the design team we are able to > > incorporate the results of it into the document (even at a > fairly late > > stage of the document process). If the design team does not produce > > results then anything that comes out of it can be seen as > an extension > > to the Phone BCP document. > > > > We need members for the design team! We have already received the > > commitment of folks from NENA but we also need some guys from the > > ECRIT group. Who is interested in participating? > > > > Ciao > > Hannes & Marc > > > > _______________________________________________ > > 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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 6 15:45:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F004B28C14C; Mon, 6 Oct 2008 15:45:13 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E19013A6804 for ; Mon, 6 Oct 2008 15:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFRQAqMiYeVX for ; Mon, 6 Oct 2008 15:45:12 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 8B4F328C245 for ; Mon, 6 Oct 2008 15:45:10 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m96MjXJ9010771; Mon, 6 Oct 2008 17:45:35 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 17:45:30 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Oct 2008 00:45:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 00:45:26 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180023B0174@DEEXC1U01.de.lucent.com> In-Reply-To: <02eb01c927e8$18468320$48d38960$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Thread-Index: Ackn4TlYGfmZ71DdRfOBXVz056y4PQABmv6AAAbrhgA= References: <48EA3476.6000806@gmx.net> <02eb01c927e8$18468320$48d38960$@net> From: "DRAGE, Keith \(Keith\)" To: "Brian Rosen" , "Henning Schulzrinne" , "Hannes Tschofenig" X-OriginalArrivalTime: 06 Oct 2008 22:45:26.0983 (UTC) FILETIME=[3A008570:01C92805] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: ECRIT Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org And during the ecrit meeting I made a request that the draft was updated to clearly separate the concepts of user, UA and so on, and I believe that applies here as well. I am still waiting for that revision. Regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Monday, October 06, 2008 8:17 PM > To: 'Henning Schulzrinne'; 'Hannes Tschofenig' > Cc: 'ECRIT' > Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call > Termination > > It was defined in draft-rosen-ecrit-abpd-reqs-00. It was: > when on an emergency call, a caller hangs up the call before > the call taker is finished acquiring enough information. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Henning Schulzrinne > Sent: Monday, October 06, 2008 2:27 PM > To: Hannes Tschofenig > Cc: 'ECRIT' > Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call > Termination > > I agree with Ted's concerns. In particular, "premature call > termination" has never been defined precisely and many of the > fears are based on the old single-line physical phone model > which just don't apply here. Carrying forward notions that > apply to black phones with rotary dials just seems unhelpful. > In particular, the topic is strongly connected to call-back > and should not be treated in isolation. > > Henning > > On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote: > > > Hi all, > > > > we had a chat with Jon on how to make some progress on the > subject of > > "Premature Call Termination" and here is the plan we came up with: > > > > * We delete the sentence that talks about the UAC not > generating a BYE > > request in > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt > > We progress the document through the IETF process as "planned". > > > > * At the same time we create a design team in ECRIT to work on > > "Premature Call Termination". > > > > Depending on the progress of the design team we are able to > > incorporate the results of it into the document (even at a > fairly late > > stage of the document process). If the design team does not produce > > results then anything that comes out of it can be seen as > an extension > > to the Phone BCP document. > > > > We need members for the design team! We have already received the > > commitment of folks from NENA but we also need some guys from the > > ECRIT group. Who is interested in participating? > > > > Ciao > > Hannes & Marc > > > > _______________________________________________ > > 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 > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 6 17:06:26 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8DE73A6A3E; Mon, 6 Oct 2008 17:06:26 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED2B28C133 for ; Mon, 6 Oct 2008 17:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdkzHDQytrzW for ; Mon, 6 Oct 2008 17:06:24 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3C1D53A69AF for ; Mon, 6 Oct 2008 17:06:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,370,1220227200"; d="scan'208";a="106826406" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 07 Oct 2008 00:07:01 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m970718k012321; Mon, 6 Oct 2008 17:07:01 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m97071gS018632; Tue, 7 Oct 2008 00:07:01 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 17:07:01 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.73.33]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 17:07:00 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 06 Oct 2008 19:07:17 -0500 To: "Brian Rosen" , "'Henning Schulzrinne'" , "'Hannes Tschofenig'" From: "James M. Polk" In-Reply-To: <034401c927f9$7c1041f0$7430c5d0$@net> References: <48EA3476.6000806@gmx.net> <02eb01c927e8$18468320$48d38960$@net> <034401c927f9$7c1041f0$7430c5d0$@net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 07 Oct 2008 00:07:00.0499 (UTC) FILETIME=[9EC3CE30:01C92810] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5140; t=1223338021; x=1224202021; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20IETF=20ECRIT=20Design=20Team= 20on=20Premature=20Call=20=0A=20=20Termination |Sender:=20; bh=c8K2pxudzGgOBhwL35CL9ajIKPUwIvENqKFMsG52elM=; b=q6X5dVyFDCcnJu52x8H/acZLVP2nIEZl9DUoysg3iE/WDW1yLBvjd43RkM 02Z7A/5kcOtF/TUA9BB/e9IiYwFZYH8udGz5bNgR5DejWTYH/ICXxDmXORNJ iV4oU/Kfzz; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org OK, fair, I'm glad we are going in the precise direction. But I am curious about who determines "precise" within the PSAP (per your suggestion). Is it the call taker themselves, or is this somehow incorporated into a signaling protocol? It seems like the IETF is concerned with how this can be done in signaling somehow. I'm wonder aloud if this can be done in signaling either automatically (as a response or new transaction) to the calling party when some automaton determines it has received enough information (which is determined by a configurable API to know which fields or buckets get filled from the inbound signaling)? Or if the call taker hits a button - indicating they have enough information to allow the caller to terminate the call -- knowing there is sufficient location and/or callback information for this call? To me, these are completely different. In fact, I could argue that the idea that a call taker make a mental decision that they have enough information about the caller is something that is a brand new type of requirement, and one that inherently doesn't have precedent in today's architectures anywhere. This means we need to look at this as a fresh req that may or may not be necessary. just thinking out loud... At 04:21 PM 10/6/2008, Brian Rosen wrote: >No, actually, it's pretty precise. It's "premature" unless the PSAP says >otherwise (that is, if the caller attempts to disconnect before the PSAP >does, then it's a premature disconnect). > >Brian > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Monday, October 06, 2008 4:01 PM >To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig' >Cc: 'ECRIT' >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > >This sounds a bit like a subjective thing, verses a quantifiable >definitive thing. > >How exactly does a UAC know when it has achieved this status (i.e., >provided enough information)? > >I assume the goal is to have something in signaling that communicates >this to the UAC, right? > >Or is this merely at the discretion of the called party (i.e., the >call taker's personal satisfaction)? > >Where I'm going with this is that I'm beginning to wonder if, then >how a signaling protocol document should address this, or should this >not be dealt with in signaling (which is nearly 100% of what we are >defining -- only!) IMO... > >James > >At 02:16 PM 10/6/2008, Brian Rosen wrote: > >It was defined in draft-rosen-ecrit-abpd-reqs-00. It was: > >when on an emergency call, a caller hangs up the call before the call taker > >is finished acquiring enough information. > > > >Brian > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > >Henning Schulzrinne > >Sent: Monday, October 06, 2008 2:27 PM > >To: Hannes Tschofenig > >Cc: 'ECRIT' > >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > > > >I agree with Ted's concerns. In particular, "premature call > >termination" has never been defined precisely and many of the fears > >are based on the old single-line physical phone model which just don't > >apply here. Carrying forward notions that apply to black phones with > >rotary dials just seems unhelpful. In particular, the topic is > >strongly connected to call-back and should not be treated in isolation. > > > >Henning > > > >On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote: > > > > > Hi all, > > > > > > we had a chat with Jon on how to make some progress on the subject > > > of "Premature Call Termination" and here is the plan we came up with: > > > > > > * We delete the sentence that talks about the UAC not generating a > > > BYE request in > > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt > > > We progress the document through the IETF process as "planned". > > > > > > * At the same time we create a design team in ECRIT to work on > > > "Premature Call Termination". > > > > > > Depending on the progress of the design team we are able to > > > incorporate the results of it into the document (even at a fairly > > > late stage > > > of the document process). If the design team does not produce > > > results then anything that comes out of it can be seen as an > > > extension to the > > > Phone BCP document. > > > > > > We need members for the design team! We have already received the > > > commitment of folks from NENA but we also need some guys from the > > > ECRIT group. Who is interested in participating? > > > > > > Ciao > > > Hannes & Marc > > > > > > _______________________________________________ > > > 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 > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 6 23:34:22 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0E3C3A68BA; Mon, 6 Oct 2008 23:34:22 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D163A6778 for ; Mon, 6 Oct 2008 23:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.691 X-Spam-Level: X-Spam-Status: No, score=-3.691 tagged_above=-999 required=5 tests=[AWL=2.909, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgSjHlcfI+DM for ; Mon, 6 Oct 2008 23:34:20 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 12C923A68BA for ; Mon, 6 Oct 2008 23:34:19 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m976Ytik026187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Oct 2008 08:34:56 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m976YtI2017845; Tue, 7 Oct 2008 08:34:55 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 08:34:56 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 08:34:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 09:34:53 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Thread-Index: Ackn4EM+yS1+9RnqS9OUriin9krGHAAZiGew References: <48EA3476.6000806@gmx.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Ted Hardie" , "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 07 Oct 2008 06:34:55.0573 (UTC) FILETIME=[CFCA4050:01C92846] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081007083456-1EF13BB0-31538FD6/0-0/0-15 X-purgate-size: 2940/0 Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Ted, >>* At the same time we create a design team in ECRIT to work on >>"Premature Call Termination". > >This seems to me to presume a fundamental requirement and to >define the terms in a way that isn't appropriate. >Can we define the deliverables, to clear this up? For >example, could the design team reasonably determine that call >termination in SIP-based systems was fundamentally different >from the wireline and that wireline models of what "premature" >meant did not apply? Or does this presume the Canadian >requirements as a new, global requirement? Or does this >include some negotiation phase requirement that didn't exist before? We obviously have to discuss terminology, if that's your concern. > >>Depending on the progress of the design team we are able to >incorporate >>the results of it into the document (even at a fairly late >stage of the >>document process). If the design team does not produce results then >>anything that comes out of it can be seen as an extension to >the Phone >>BCP document. > >Any design team document that does not go through the full >IETF process can expect an appeal. This isn't the role of >design teams--they make proposals to a working group, which >then has every opportunity to review them as it would any other input. >The same is true for IETF Last Call review. Assuming that the >results of this can be incorporated into a document that has >already passed IESG review without updating that document and >going through the process is just not how things work. I know the process. Don't worry. > >>We need members for the design team! We have already received the >>commitment of folks from NENA but we also need some guys from >the ECRIT >>group. Who is interested in participating? > >Sorry, maybe I have misunderstood this totally. How do you >have volunteers from NENA for an IETF document without having >announced the need before today? Are you planning this as a >design team to help NENA define a requirement in its own >documents? Or is this meant to produce an IETF document? If >a NENA document, my discussion of design teams is off-base, >and I apologize, but it would be useful to identify the target here. > thanks, > Ted I thought it would be sensible to involve folks from NENA since the issue came up there. I want to make sure that key players from both groups are present. This is important to make some progress. Does my response help? Ciao Hannes > > > >>Ciao >>Hannes & Marc >> >>_______________________________________________ >>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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 6 23:35:42 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED5163A6778; Mon, 6 Oct 2008 23:35:42 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8E4F3A684C for ; Mon, 6 Oct 2008 23:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WbTTCVBrP7H for ; Mon, 6 Oct 2008 23:35:40 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id BC4953A6778 for ; Mon, 6 Oct 2008 23:35:39 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m976a4oM014328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Oct 2008 08:36:04 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m976a4i1022018; Tue, 7 Oct 2008 08:36:04 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 08:36:04 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 08:36:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 09:36:00 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Thread-Index: Ackn4T2Gh5lzS7HIQaeIlGN2kbqX5wAZZemA References: <48EA3476.6000806@gmx.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Henning Schulzrinne" , "Hannes Tschofenig" X-OriginalArrivalTime: 07 Oct 2008 06:36:03.0598 (UTC) FILETIME=[F8560AE0:01C92846] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081007083604-1B974BB0-7A4468F5/0-0/0-15 X-purgate-size: 2457/0 Cc: ECRIT Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I just had to give the topic a name. I selected this one since previous discussions used this term. I am happy to pick a different name for the DT. We will obviously go through the terminology first; Brian's doc is the starting point. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Henning Schulzrinne >Sent: 06 October, 2008 21:27 >To: Hannes Tschofenig >Cc: 'ECRIT' >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call >Termination > >I agree with Ted's concerns. In particular, "premature call >termination" has never been defined precisely and many of the >fears are based on the old single-line physical phone model >which just don't apply here. Carrying forward notions that >apply to black phones with rotary dials just seems unhelpful. >In particular, the topic is strongly connected to call-back >and should not be treated in isolation. > >Henning > >On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote: > >> Hi all, >> >> we had a chat with Jon on how to make some progress on the >subject of >> "Premature Call Termination" and here is the plan we came up with: >> >> * We delete the sentence that talks about the UAC not >generating a BYE >> request in >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt >> We progress the document through the IETF process as "planned". >> >> * At the same time we create a design team in ECRIT to work on >> "Premature Call Termination". >> >> Depending on the progress of the design team we are able to >> incorporate the results of it into the document (even at a >fairly late >> stage of the document process). If the design team does not produce >> results then anything that comes out of it can be seen as an >extension >> to the Phone BCP document. >> >> We need members for the design team! We have already received the >> commitment of folks from NENA but we also need some guys from the >> ECRIT group. Who is interested in participating? >> >> Ciao >> Hannes & Marc >> >> _______________________________________________ >> 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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 6 23:41:12 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2312B3A6778; Mon, 6 Oct 2008 23:41:12 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D1C73A6778 for ; Mon, 6 Oct 2008 23:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.327 X-Spam-Level: X-Spam-Status: No, score=-4.327 tagged_above=-999 required=5 tests=[AWL=2.272, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EH4lHPz86603 for ; Mon, 6 Oct 2008 23:41:10 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id DFEF83A63D3 for ; Mon, 6 Oct 2008 23:41:09 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m976fRlx007853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Oct 2008 08:41:27 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m976fQwk031228; Tue, 7 Oct 2008 08:41:27 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 08:41:27 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 08:41:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 09:41:25 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Thread-Index: Ackn88BckAHEHT2TT9abVw3ZFADE/wAU1avg References: <48EA3476.6000806@gmx.net><02eb01c927e8$18468320$48d38960$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Ted Hardie" , "Brian Rosen" , "Henning Schulzrinne" , "Hannes Tschofenig" X-OriginalArrivalTime: 07 Oct 2008 06:41:26.0368 (UTC) FILETIME=[B8B8D600:01C92847] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081007084127-1EF11BB0-BD61473D/0-0/0-15 X-purgate-size: 4129/0 Cc: ECRIT Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Ted, >I do not believe we have WG consensus on that document; John >Hearty had comments on it, as did Keith Drage and James Polk >(at least judging by the thread "Let's make some decisions >regarding draft-rosen-ecrit-premature-disconnect-reqmts", >which is the only one discussing I find in my personal >archives). None of those seems to have been addressed; nor >have the comments I made on the issue in Dublin. These were >minuted, and Hannes copied the relevant minutes to the list >under the title "Premature Disconnect (feedback from the meeting)". We don't have consensus on draft-rosen-ecrit-premature-disconnect-rqmts-00.txt We are going to discuss the feedback to that document (during the past IETF meeting) and also those posted to the list. > >Is the design team, then, going to work with Brian to settle >the requirements? Because if we don't have consensus on the >requirements, the design team seems to have a hard row to hoe. My plan was to start with the terminology. When we know what we will look at the requirements. After we understood the requirements then we will report back to the group and figure out what todo next. If we come to the conclusion that the requirements are not accomplishable or that we have all the necessary tools already then we next steps are easy. Does this help? Ciao Hannes > regards, > Ted > > > >> It was: >>when on an emergency call, a caller hangs up the call before the call >>taker is finished acquiring enough information. >> >>Brian >> >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >>Of Henning Schulzrinne >>Sent: Monday, October 06, 2008 2:27 PM >>To: Hannes Tschofenig >>Cc: 'ECRIT' >>Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call >>Termination >> >>I agree with Ted's concerns. In particular, "premature call >>termination" has never been defined precisely and many of the >fears are >>based on the old single-line physical phone model which just don't >>apply here. Carrying forward notions that apply to black phones with >>rotary dials just seems unhelpful. In particular, the topic >is strongly >>connected to call-back and should not be treated in isolation. >> >>Henning >> >>On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote: >> >>> Hi all, >>> >>> we had a chat with Jon on how to make some progress on the >subject of >>> "Premature Call Termination" and here is the plan we came up with: >>> >>> * We delete the sentence that talks about the UAC not generating a >>> BYE request in >>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt >>> We progress the document through the IETF process as "planned". >>> >>> * At the same time we create a design team in ECRIT to work on >>> "Premature Call Termination". >>> >>> Depending on the progress of the design team we are able to >>> incorporate the results of it into the document (even at a fairly >>> late stage of the document process). If the design team does not >>> produce results then anything that comes out of it can be >seen as an >>> extension to the Phone BCP document. >>> >>> We need members for the design team! We have already received the >>> commitment of folks from NENA but we also need some guys from the >>> ECRIT group. Who is interested in participating? >>> >>> Ciao >>> Hannes & Marc >>> >>> _______________________________________________ >>> 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 >> >>_______________________________________________ >>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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 6 23:42:50 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2E63A6883; Mon, 6 Oct 2008 23:42:50 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B8643A6883 for ; Mon, 6 Oct 2008 23:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDdOSUSsCejz for ; Mon, 6 Oct 2008 23:42:48 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 30CCF3A63D3 for ; Mon, 6 Oct 2008 23:42:48 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m976h53Z029035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Oct 2008 08:43:05 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m976gwBS001688; Tue, 7 Oct 2008 08:43:05 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 08:43:04 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 08:43:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 09:43:01 +0300 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE29180023B0173@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Thread-Index: Ackn4UrEly4wcLPaRhO29+Va7KSyDQAIV5SgABFHg9A= References: <48EA3476.6000806@gmx.net> <5D1A7985295922448D5550C94DE29180023B0173@DEEXC1U01.de.lucent.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext DRAGE, Keith (Keith)" , "Henning Schulzrinne" , "Hannes Tschofenig" X-OriginalArrivalTime: 07 Oct 2008 06:43:03.0491 (UTC) FILETIME=[F29CA130:01C92847] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081007084305-1B97DBB0-A56D0035/0-0/0-15 X-purgate-size: 2992/0 Cc: ECRIT Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >I believe the previous agreement was that we would get the >requirements drafted, and then decide whether there was >consensus to implement those requirements. This is the approach. Sorry that I was imprecise. Please note, however, that my mail was mainly intended to find folks with time and interest to discuss the subject. A design team needs folks to get the work started. > >I do not see in Hannes mail any incorporation of this into the process. > Ciao Hannes >Regards > >Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Henning Schulzrinne >> Sent: Monday, October 06, 2008 7:27 PM >> To: Hannes Tschofenig >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call >> Termination >> >> I agree with Ted's concerns. In particular, "premature call >> termination" has never been defined precisely and many of the fears >> are based on the old single-line physical phone model which >just don't >> apply here. Carrying forward notions that apply to black phones with >> rotary dials just seems unhelpful. >> In particular, the topic is strongly connected to call-back >and should >> not be treated in isolation. >> >> Henning >> >> On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote: >> >> > Hi all, >> > >> > we had a chat with Jon on how to make some progress on the >> subject of >> > "Premature Call Termination" and here is the plan we came up with: >> > >> > * We delete the sentence that talks about the UAC not >> generating a BYE >> > request in >> > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt >> > We progress the document through the IETF process as "planned". >> > >> > * At the same time we create a design team in ECRIT to work on >> > "Premature Call Termination". >> > >> > Depending on the progress of the design team we are able to >> > incorporate the results of it into the document (even at a >> fairly late >> > stage of the document process). If the design team does >not produce >> > results then anything that comes out of it can be seen as >> an extension >> > to the Phone BCP document. >> > >> > We need members for the design team! We have already received the >> > commitment of folks from NENA but we also need some guys from the >> > ECRIT group. Who is interested in participating? >> > >> > Ciao >> > Hannes & Marc >> > >> > _______________________________________________ >> > 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 >> >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 6 23:43:26 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD943A6857; Mon, 6 Oct 2008 23:43:26 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666753A6857 for ; Mon, 6 Oct 2008 23:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ge-OoI3eYUIj for ; Mon, 6 Oct 2008 23:43:24 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 35F733A63D3 for ; Mon, 6 Oct 2008 23:43:23 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m976hneO030732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Oct 2008 08:43:49 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m976hnGB004467; Tue, 7 Oct 2008 08:43:49 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 08:43:49 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 08:43:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 09:43:47 +0300 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE29180023B0174@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Thread-Index: Ackn4TlYGfmZ71DdRfOBXVz056y4PQABmv6AAAbrhgAAESpaoA== References: <48EA3476.6000806@gmx.net><02eb01c927e8$18468320$48d38960$@net> <5D1A7985295922448D5550C94DE29180023B0174@DEEXC1U01.de.lucent.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext DRAGE, Keith (Keith)" , "Brian Rosen" , "Henning Schulzrinne" , "Hannes Tschofenig" X-OriginalArrivalTime: 07 Oct 2008 06:43:49.0224 (UTC) FILETIME=[0DDEEE80:01C92848] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081007084349-1B977BB0-DD65FA54/0-0/0-15 X-purgate-size: 3817/0 Cc: ECRIT Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org That's a good comment. That's something we should be investigate as well. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext DRAGE, Keith (Keith) >Sent: 07 October, 2008 01:45 >To: Brian Rosen; Henning Schulzrinne; Hannes Tschofenig >Cc: ECRIT >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call >Termination > >And during the ecrit meeting I made a request that the draft >was updated to clearly separate the concepts of user, UA and >so on, and I believe that applies here as well. > >I am still waiting for that revision. > >Regards > >Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Brian Rosen >> Sent: Monday, October 06, 2008 8:17 PM >> To: 'Henning Schulzrinne'; 'Hannes Tschofenig' >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call >> Termination >> >> It was defined in draft-rosen-ecrit-abpd-reqs-00. It was: >> when on an emergency call, a caller hangs up the call before >the call >> taker is finished acquiring enough information. >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Henning Schulzrinne >> Sent: Monday, October 06, 2008 2:27 PM >> To: Hannes Tschofenig >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call >> Termination >> >> I agree with Ted's concerns. In particular, "premature call >> termination" has never been defined precisely and many of the fears >> are based on the old single-line physical phone model which >just don't >> apply here. Carrying forward notions that apply to black phones with >> rotary dials just seems unhelpful. >> In particular, the topic is strongly connected to call-back >and should >> not be treated in isolation. >> >> Henning >> >> On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote: >> >> > Hi all, >> > >> > we had a chat with Jon on how to make some progress on the >> subject of >> > "Premature Call Termination" and here is the plan we came up with: >> > >> > * We delete the sentence that talks about the UAC not >> generating a BYE >> > request in >> > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt >> > We progress the document through the IETF process as "planned". >> > >> > * At the same time we create a design team in ECRIT to work on >> > "Premature Call Termination". >> > >> > Depending on the progress of the design team we are able to >> > incorporate the results of it into the document (even at a >> fairly late >> > stage of the document process). If the design team does >not produce >> > results then anything that comes out of it can be seen as >> an extension >> > to the Phone BCP document. >> > >> > We need members for the design team! We have already received the >> > commitment of folks from NENA but we also need some guys from the >> > ECRIT group. Who is interested in participating? >> > >> > Ciao >> > Hannes & Marc >> > >> > _______________________________________________ >> > 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 >> >> _______________________________________________ >> 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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 6 23:44:42 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABC713A67F7; Mon, 6 Oct 2008 23:44:42 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4FEF3A67F7 for ; Mon, 6 Oct 2008 23:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPwlwu4wT1sk for ; Mon, 6 Oct 2008 23:44:41 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id BD2553A6778 for ; Mon, 6 Oct 2008 23:44:40 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m976j6WE001836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Oct 2008 08:45:06 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m976j43x005692; Tue, 7 Oct 2008 08:45:06 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 08:45:06 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 08:45:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 09:45:01 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Thread-Index: AckoEKM9ZiJN7cuwTpWsARdTq0J+bwAN3spQ References: <48EA3476.6000806@gmx.net><02eb01c927e8$18468320$48d38960$@net><034401c927f9$7c1041f0$7430c5d0$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext James M. Polk" , "Brian Rosen" , "Henning Schulzrinne" , "Hannes Tschofenig" X-OriginalArrivalTime: 07 Oct 2008 06:45:04.0928 (UTC) FILETIME=[3AFE7200:01C92848] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081007084506-1B973BB0-08BA10FF/0-0/0-15 X-purgate-size: 146/0 Cc: ECRIT Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Based on this discussion may I put * James * Ted * Henning, and * Keith On the design team? Someone else? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 7 05:46:41 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1129828C193; Tue, 7 Oct 2008 05:46:41 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0254B28C194 for ; Tue, 7 Oct 2008 05:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sv2ISKt8xZZd for ; Tue, 7 Oct 2008 05:46:39 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 4A29F28C13D for ; Tue, 7 Oct 2008 05:46:39 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KnBy5-0007Gq-L0; Tue, 07 Oct 2008 07:47:13 -0500 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext James M. Polk'" , "'Henning Schulzrinne'" , "'Hannes Tschofenig'" References: <48EA3476.6000806@gmx.net><02eb01c927e8$18468320$48d38960$@net><034401c927f9$7c1041f0$7430c5d0$@net> In-Reply-To: Date: Tue, 7 Oct 2008 08:47:13 -0400 Message-ID: <044801c9287a$d4786170$7d692450$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckoEKM9ZiJN7cuwTpWsARdTq0J+bwAN3spQAAyqUUA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Uh, me? -----Original Message----- From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] Sent: Tuesday, October 07, 2008 2:45 AM To: ext James M. Polk; Brian Rosen; Henning Schulzrinne; Hannes Tschofenig Cc: ECRIT Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Based on this discussion may I put * James * Ted * Henning, and * Keith On the design team? Someone else? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 7 05:47:54 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 430F83A6B66; Tue, 7 Oct 2008 05:47:54 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BF6928C1F2 for ; Tue, 7 Oct 2008 05:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.636 X-Spam-Level: X-Spam-Status: No, score=-4.636 tagged_above=-999 required=5 tests=[AWL=1.963, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5yJZMh-WFWG for ; Tue, 7 Oct 2008 05:47:50 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id CD6FD3A6B56 for ; Tue, 7 Oct 2008 05:47:47 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m97CmBQo003617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Oct 2008 14:48:11 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m97Cm7jk011319; Tue, 7 Oct 2008 14:48:11 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 14:48:11 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 14:48:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 15:48:20 +0300 Message-ID: In-Reply-To: <044801c9287a$d4786170$7d692450$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Thread-Index: AckoEKM9ZiJN7cuwTpWsARdTq0J+bwAN3spQAAyqUUAAAAoUEA== References: <48EA3476.6000806@gmx.net><02eb01c927e8$18468320$48d38960$@net><034401c927f9$7c1041f0$7430c5d0$@net> <044801c9287a$d4786170$7d692450$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Brian Rosen" , "ext James M. Polk" , "Henning Schulzrinne" , "Hannes Tschofenig" X-OriginalArrivalTime: 07 Oct 2008 12:48:11.0086 (UTC) FILETIME=[F48E56E0:01C9287A] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081007144811-40301BB0-FBD86527/0-0/0-15 X-purgate-size: 1095/0 Cc: ECRIT Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I counted you in already from the NENA side since you lead the discussions there. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Brian Rosen >Sent: 07 October, 2008 15:47 >To: Tschofenig, Hannes (NSN - FI/Espoo); 'ext James M. Polk'; >'Henning Schulzrinne'; 'Hannes Tschofenig' >Cc: 'ECRIT' >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call >Termination > >Uh, me? > >-----Original Message----- >From: Tschofenig, Hannes (NSN - FI/Espoo) >[mailto:hannes.tschofenig@nsn.com] > >Sent: Tuesday, October 07, 2008 2:45 AM >To: ext James M. Polk; Brian Rosen; Henning Schulzrinne; >Hannes Tschofenig >Cc: ECRIT >Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call >Termination > >Based on this discussion may I put >* James >* Ted >* Henning, and >* Keith >On the design team? > >Someone else? > >Ciao >Hannes > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 7 07:16:34 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104C63A6B3A; Tue, 7 Oct 2008 07:16:34 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886413A6B3A for ; Tue, 7 Oct 2008 07:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5TBRv-I4S4N for ; Tue, 7 Oct 2008 07:16:28 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 092A33A6829 for ; Tue, 7 Oct 2008 07:16:27 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KnDLv-0003Q8-UW; Tue, 07 Oct 2008 09:15:56 -0500 From: "Brian Rosen" To: "'James M. Polk'" , "'Henning Schulzrinne'" , "'Hannes Tschofenig'" References: <48EA3476.6000806@gmx.net> <02eb01c927e8$18468320$48d38960$@net> <034401c927f9$7c1041f0$7430c5d0$@net> In-Reply-To: Date: Tue, 7 Oct 2008 10:15:54 -0400 Message-ID: <048201c92887$37bb2f40$a7318dc0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckoEJwVhrhMFaKWTl+4DCqwhzENhQAajjvQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It's manual, not automatic. When the PSAP call taker decides the call is over, then call termination occurs. They release the call (with a button). In the proposed mechanisms, the caller cannot terminate until then. The signaling is how the call taker keeps the call up, how the UA signals its state (on hook/off hook or its logical equivalent) to the PSAP and how the PSAP signals various alerts (ringing, howler, etc) to the UA. The concern that has to be addressed is making sure that in failure conditions, we don't "brick" the UA. Please remember there are two problems: Premature Disconnect, which is what we are talking about, and "Abandoned Call", which is where the caller attempts to abandon placing an emergency call before it is answered by the PSAP. These really are the same thing, but the signaling problem is different. In "Premature Disconnect", the call completed, the call taker has answered, and conversation started. "Abandoned Call" is an attempt to take the call down some time between when the original call was placed and the beginning of that period. Brian -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Monday, October 06, 2008 8:07 PM To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig' Cc: 'ECRIT' Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination OK, fair, I'm glad we are going in the precise direction. But I am curious about who determines "precise" within the PSAP (per your suggestion). Is it the call taker themselves, or is this somehow incorporated into a signaling protocol? It seems like the IETF is concerned with how this can be done in signaling somehow. I'm wonder aloud if this can be done in signaling either automatically (as a response or new transaction) to the calling party when some automaton determines it has received enough information (which is determined by a configurable API to know which fields or buckets get filled from the inbound signaling)? Or if the call taker hits a button - indicating they have enough information to allow the caller to terminate the call -- knowing there is sufficient location and/or callback information for this call? To me, these are completely different. In fact, I could argue that the idea that a call taker make a mental decision that they have enough information about the caller is something that is a brand new type of requirement, and one that inherently doesn't have precedent in today's architectures anywhere. This means we need to look at this as a fresh req that may or may not be necessary. just thinking out loud... At 04:21 PM 10/6/2008, Brian Rosen wrote: >No, actually, it's pretty precise. It's "premature" unless the PSAP says >otherwise (that is, if the caller attempts to disconnect before the PSAP >does, then it's a premature disconnect). > >Brian > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Monday, October 06, 2008 4:01 PM >To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig' >Cc: 'ECRIT' >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > >This sounds a bit like a subjective thing, verses a quantifiable >definitive thing. > >How exactly does a UAC know when it has achieved this status (i.e., >provided enough information)? > >I assume the goal is to have something in signaling that communicates >this to the UAC, right? > >Or is this merely at the discretion of the called party (i.e., the >call taker's personal satisfaction)? > >Where I'm going with this is that I'm beginning to wonder if, then >how a signaling protocol document should address this, or should this >not be dealt with in signaling (which is nearly 100% of what we are >defining -- only!) IMO... > >James > >At 02:16 PM 10/6/2008, Brian Rosen wrote: > >It was defined in draft-rosen-ecrit-abpd-reqs-00. It was: > >when on an emergency call, a caller hangs up the call before the call taker > >is finished acquiring enough information. > > > >Brian > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > >Henning Schulzrinne > >Sent: Monday, October 06, 2008 2:27 PM > >To: Hannes Tschofenig > >Cc: 'ECRIT' > >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > > > >I agree with Ted's concerns. In particular, "premature call > >termination" has never been defined precisely and many of the fears > >are based on the old single-line physical phone model which just don't > >apply here. Carrying forward notions that apply to black phones with > >rotary dials just seems unhelpful. In particular, the topic is > >strongly connected to call-back and should not be treated in isolation. > > > >Henning > > > >On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote: > > > > > Hi all, > > > > > > we had a chat with Jon on how to make some progress on the subject > > > of "Premature Call Termination" and here is the plan we came up with: > > > > > > * We delete the sentence that talks about the UAC not generating a > > > BYE request in > > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt > > > We progress the document through the IETF process as "planned". > > > > > > * At the same time we create a design team in ECRIT to work on > > > "Premature Call Termination". > > > > > > Depending on the progress of the design team we are able to > > > incorporate the results of it into the document (even at a fairly > > > late stage > > > of the document process). If the design team does not produce > > > results then anything that comes out of it can be seen as an > > > extension to the > > > Phone BCP document. > > > > > > We need members for the design team! We have already received the > > > commitment of folks from NENA but we also need some guys from the > > > ECRIT group. Who is interested in participating? > > > > > > Ciao > > > Hannes & Marc > > > > > > _______________________________________________ > > > 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 > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 7 10:14:34 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6DD28C119; Tue, 7 Oct 2008 10:14:34 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984A83A6B77 for ; Tue, 7 Oct 2008 10:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.752 X-Spam-Level: X-Spam-Status: No, score=-102.752 tagged_above=-999 required=5 tests=[AWL=-2.463, BAYES_00=-2.599, SARE_URGBIZ=0.725, URG_BIZ=1.585, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1zN4CmlBUwg for ; Tue, 7 Oct 2008 10:14:31 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 41C323A6B76 for ; Tue, 7 Oct 2008 10:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1223399710; x=1254935710; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<048201c92887$37bb2f40$a 7318dc0$@net>|References:=20<48EA3476.6000806@gmx.net>=0D =0A=20=0D=0A=20<02eb01c927e8$18468320$48d38960$@net>=0D=0A =20=0D=0A=20<034401c927f9$7c1041f0$7430c5d0$@net>=0D=0A=20 =0D=0A=20<048201c92887$37bb2f40$a7318dc0$@net>|Date:=20Tu e,=207=20Oct=202008=2010:14:45=20-0700|To:=20Brian=20Rose n=20,=20"'James=20M.=20Polk'"=20,=0D=0A=20=20=20=20=20=20=20=20"'Henning=20Sc hulzrinne'"=20,=0D=0A=20=20=20=20=20 =20=20=20"'Hannes=20Tschofenig'"=0D=0A=09|From:=20Ted=20Hardie=20 |Subject:=20Re:=20[Ecrit]=20IETF=20ECRIT=20Design=20Team =20on=20Premature=20Call=20=20=20Termination|CC:=20"'ECRI T'"=20|Content-Type:=20text/plain=3B=20ch arset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"530 0,2777,5399"=3B=20a=3D"10144795"; bh=VjRnmMcZoZ4Yddw92OvUAvnLKuj1SNwtUkxEzPUc1nc=; b=ZrWLZ08NvTzLWpDDR4uW4mkNBNko4czIdbSfqlDEGk7Y8Proahk1G/+F NuGaNjLioZsg6byGhifk7i6lOaH1clgEk9JC9PfmAtmmTOywouESMlcK9 Rd+8eeK9T+ZU5pBu4yVlwiLlHUoyr7czD23O0SxZDcKopZWqyb5fj8CVI 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5399"; a="10144795" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Oct 2008 10:14:47 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m97HElsH028824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Oct 2008 10:14:47 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m97HEkm4001560 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Oct 2008 10:14:46 -0700 Received: from [10.227.68.106] (10.227.68.106) by qcmail1.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 7 Oct 2008 10:14:46 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <048201c92887$37bb2f40$a7318dc0$@net> References: <48EA3476.6000806@gmx.net> <02eb01c927e8$18468320$48d38960$@net> <034401c927f9$7c1041f0$7430c5d0$@net> <048201c92887$37bb2f40$a7318dc0$@net> Date: Tue, 7 Oct 2008 10:14:45 -0700 To: Brian Rosen , "'James M. Polk'" , "'Henning Schulzrinne'" , "'Hannes Tschofenig'" From: Ted Hardie Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 7:15 AM -0700 10/7/08, Brian Rosen wrote: >It's manual, not automatic. > >When the PSAP call taker decides the call is over, then call termination >occurs. They release the call (with a button). In the proposed mechanisms, >the caller cannot terminate until then. Is my memory correct that this mechanism is currently in place in Canada, desired by some operators in the U.S., but not a universal practice? One of my concerns here is that we do not impose this model onto systems which do not work this way now by encoding it into the signalling protocols. If, for example, it is the presumption of certain types of emergency services (spousal abuse crisis centers, to take an example), that the caller must always be able to terminate a call as swiftly and silently as possible, anything that keeps the call up so that an abusive spouse can hear that a call is present may be counter-productive. [This is not meant to reflect any real-world experience with these centers, as I have none. This is simply a way of getting at the idea that the desire to allow user termination may also occur because of a specific emergency setting; kidnap and home invasion have been used as examples in the past.] >The signaling is how the call taker keeps the call up, how the UA signals >its state (on hook/off hook or its logical equivalent) to the PSAP and how >the PSAP signals various alerts (ringing, howler, etc) to the UA. The >concern that has to be addressed is making sure that in failure conditions, >we don't "brick" the UA. > >Please remember there are two problems: >Premature Disconnect, which is what we are talking about, and "Abandoned >Call", which is where the caller attempts to abandon placing an emergency >call before it is answered by the PSAP. These really are the same thing, I think that is a remarkable presumption. They may not be the same thing at all. In jurisdictions which have multiple response numbers, for example, an abandoned call might reflect a realization from the caller that they need to call a different emergency number (I called the police when the fight started, but before they answered, I realized we urgently need medical response. Or, I called for medical help then saw the bottle that tells me I need a poison-specific response.). Systems which do not acknowledge that the people making these calls may have knowledge that causes them to change their response to an emergency should not be encoded in the signalling in my view. I am also seriously worried about the interaction of this with the no-SIM test call problem. If PSAPs MUST respond to these calls and handle abandoned calls, abandoned test calls take on an even more problematic aspect. At least now, those callers can hang up when they hear a ring. >but the signaling problem is different. In "Premature Disconnect", the call >completed, the call taker has answered, and conversation started. "Abandoned >Call" is an attempt to take the call down some time between when the >original call was placed and the beginning of that period. > >Brian > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Monday, October 06, 2008 8:07 PM >To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig' >Cc: 'ECRIT' >Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > >OK, fair, I'm glad we are going in the precise direction. But I am >curious about who determines "precise" within the PSAP (per your >suggestion). Is it the call taker themselves, or is this somehow >incorporated into a signaling protocol? > >It seems like the IETF is concerned with how this can be done in >signaling somehow. > >I'm wonder aloud if this can be done in signaling either >automatically (as a response or new transaction) to the calling party >when some automaton determines it has received enough information >(which is determined by a configurable API to know which fields or >buckets get filled from the inbound signaling)? > >Or if the call taker hits a button - indicating they have enough >information to allow the caller to terminate the call -- knowing >there is sufficient location and/or callback information for this call? > >To me, these are completely different. In fact, I could argue that >the idea that a call taker make a mental decision that they have >enough information about the caller is something that is a brand new >type of requirement, and one that inherently doesn't have precedent >in today's architectures anywhere. This means we need to look at >this as a fresh req that may or may not be necessary. > >just thinking out loud... > >At 04:21 PM 10/6/2008, Brian Rosen wrote: >>No, actually, it's pretty precise. It's "premature" unless the PSAP says >>otherwise (that is, if the caller attempts to disconnect before the PSAP >>does, then it's a premature disconnect). >> >>Brian >> >>-----Original Message----- >>From: James M. Polk [mailto:jmpolk@cisco.com] >>Sent: Monday, October 06, 2008 4:01 PM >>To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig' >>Cc: 'ECRIT' >>Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination >> >>This sounds a bit like a subjective thing, verses a quantifiable >>definitive thing. >> >>How exactly does a UAC know when it has achieved this status (i.e., >>provided enough information)? >> >>I assume the goal is to have something in signaling that communicates >>this to the UAC, right? >> >>Or is this merely at the discretion of the called party (i.e., the >>call taker's personal satisfaction)? >> >>Where I'm going with this is that I'm beginning to wonder if, then >>how a signaling protocol document should address this, or should this >>not be dealt with in signaling (which is nearly 100% of what we are >>defining -- only!) IMO... >> >>James >> >>At 02:16 PM 10/6/2008, Brian Rosen wrote: >> >It was defined in draft-rosen-ecrit-abpd-reqs-00. It was: >> >when on an emergency call, a caller hangs up the call before the call >taker >> >is finished acquiring enough information. >> > >> >Brian >> > >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> >Henning Schulzrinne >> >Sent: Monday, October 06, 2008 2:27 PM >> >To: Hannes Tschofenig >> >Cc: 'ECRIT' >> >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination >> > >> >I agree with Ted's concerns. In particular, "premature call >> >termination" has never been defined precisely and many of the fears >> >are based on the old single-line physical phone model which just don't >> >apply here. Carrying forward notions that apply to black phones with >> >rotary dials just seems unhelpful. In particular, the topic is >> >strongly connected to call-back and should not be treated in isolation. >> > >> >Henning >> > >> >On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote: >> > >> > > Hi all, >> > > >> > > we had a chat with Jon on how to make some progress on the subject >> > > of "Premature Call Termination" and here is the plan we came up with: >> > > >> > > * We delete the sentence that talks about the UAC not generating a >> > > BYE request in >> > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt >> > > We progress the document through the IETF process as "planned". >> > > >> > > * At the same time we create a design team in ECRIT to work on >> > > "Premature Call Termination". >> > > >> > > Depending on the progress of the design team we are able to >> > > incorporate the results of it into the document (even at a fairly >> > > late stage >> > > of the document process). If the design team does not produce >> > > results then anything that comes out of it can be seen as an >> > > extension to the >> > > Phone BCP document. >> > > >> > > We need members for the design team! We have already received the >> > > commitment of folks from NENA but we also need some guys from the >> > > ECRIT group. Who is interested in participating? >> > > >> > > Ciao >> > > Hannes & Marc >> > > >> > > _______________________________________________ > > > > 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 >> > >> >_______________________________________________ >> >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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 7 10:47:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4D33A6768; Tue, 7 Oct 2008 10:47:45 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1252A28C12F for ; Tue, 7 Oct 2008 10:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_00=-2.599, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1w+opx02Xs3v for ; Tue, 7 Oct 2008 10:47:42 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 628283A6A89 for ; Tue, 7 Oct 2008 10:47:42 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KnGfL-0006VG-Jj; Tue, 07 Oct 2008 12:48:12 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'James M. Polk'" , "'Henning Schulzrinne'" , "'Hannes Tschofenig'" References: <48EA3476.6000806@gmx.net> <02eb01c927e8$18468320$48d38960$@net> <034401c927f9$7c1041f0$7430c5d0$@net> <048201c92887$37bb2f40$a7318dc0$@net> In-Reply-To: Date: Tue, 7 Oct 2008 13:48:00 -0400 Message-ID: <04e701c928a4$d9277880$8b766980$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckooC/i8oVjuBu8S0uFXP7ygv670wABB+lA Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It is in use in some jurisdictions now. Canada is an example. It was deployed in the U.S., it got lost, and they mostly want it back. It is not deployed in some areas. The requirements state that if it's not needed, it doesn't stop termination, which implies some feature signaling with the appropriate defaults. In jurisdictions that have it deployed, I am not aware of the kind of problems you were imagining. The current implementations put the call taker in charge of signaling alerts. Brian -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: Tuesday, October 07, 2008 1:15 PM To: Brian Rosen; 'James M. Polk'; 'Henning Schulzrinne'; 'Hannes Tschofenig' Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination At 7:15 AM -0700 10/7/08, Brian Rosen wrote: >It's manual, not automatic. > >When the PSAP call taker decides the call is over, then call termination >occurs. They release the call (with a button). In the proposed mechanisms, >the caller cannot terminate until then. Is my memory correct that this mechanism is currently in place in Canada, desired by some operators in the U.S., but not a universal practice? One of my concerns here is that we do not impose this model onto systems which do not work this way now by encoding it into the signalling protocols. If, for example, it is the presumption of certain types of emergency services (spousal abuse crisis centers, to take an example), that the caller must always be able to terminate a call as swiftly and silently as possible, anything that keeps the call up so that an abusive spouse can hear that a call is present may be counter-productive. [This is not meant to reflect any real-world experience with these centers, as I have none. This is simply a way of getting at the idea that the desire to allow user termination may also occur because of a specific emergency setting; kidnap and home invasion have been used as examples in the past.] >The signaling is how the call taker keeps the call up, how the UA signals >its state (on hook/off hook or its logical equivalent) to the PSAP and how >the PSAP signals various alerts (ringing, howler, etc) to the UA. The >concern that has to be addressed is making sure that in failure conditions, >we don't "brick" the UA. > >Please remember there are two problems: >Premature Disconnect, which is what we are talking about, and "Abandoned >Call", which is where the caller attempts to abandon placing an emergency >call before it is answered by the PSAP. These really are the same thing, I think that is a remarkable presumption. They may not be the same thing at all. In jurisdictions which have multiple response numbers, for example, an abandoned call might reflect a realization from the caller that they need to call a different emergency number (I called the police when the fight started, but before they answered, I realized we urgently need medical response. Or, I called for medical help then saw the bottle that tells me I need a poison-specific response.). Systems which do not acknowledge that the people making these calls may have knowledge that causes them to change their response to an emergency should not be encoded in the signalling in my view. I am also seriously worried about the interaction of this with the no-SIM test call problem. If PSAPs MUST respond to these calls and handle abandoned calls, abandoned test calls take on an even more problematic aspect. At least now, those callers can hang up when they hear a ring. >but the signaling problem is different. In "Premature Disconnect", the call >completed, the call taker has answered, and conversation started. "Abandoned >Call" is an attempt to take the call down some time between when the >original call was placed and the beginning of that period. > >Brian > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Monday, October 06, 2008 8:07 PM >To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig' >Cc: 'ECRIT' >Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > >OK, fair, I'm glad we are going in the precise direction. But I am >curious about who determines "precise" within the PSAP (per your >suggestion). Is it the call taker themselves, or is this somehow >incorporated into a signaling protocol? > >It seems like the IETF is concerned with how this can be done in >signaling somehow. > >I'm wonder aloud if this can be done in signaling either >automatically (as a response or new transaction) to the calling party >when some automaton determines it has received enough information >(which is determined by a configurable API to know which fields or >buckets get filled from the inbound signaling)? > >Or if the call taker hits a button - indicating they have enough >information to allow the caller to terminate the call -- knowing >there is sufficient location and/or callback information for this call? > >To me, these are completely different. In fact, I could argue that >the idea that a call taker make a mental decision that they have >enough information about the caller is something that is a brand new >type of requirement, and one that inherently doesn't have precedent >in today's architectures anywhere. This means we need to look at >this as a fresh req that may or may not be necessary. > >just thinking out loud... > >At 04:21 PM 10/6/2008, Brian Rosen wrote: >>No, actually, it's pretty precise. It's "premature" unless the PSAP says >>otherwise (that is, if the caller attempts to disconnect before the PSAP >>does, then it's a premature disconnect). >> >>Brian >> >>-----Original Message----- >>From: James M. Polk [mailto:jmpolk@cisco.com] >>Sent: Monday, October 06, 2008 4:01 PM >>To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig' >>Cc: 'ECRIT' >>Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination >> >>This sounds a bit like a subjective thing, verses a quantifiable >>definitive thing. >> >>How exactly does a UAC know when it has achieved this status (i.e., >>provided enough information)? >> >>I assume the goal is to have something in signaling that communicates >>this to the UAC, right? >> >>Or is this merely at the discretion of the called party (i.e., the >>call taker's personal satisfaction)? >> >>Where I'm going with this is that I'm beginning to wonder if, then >>how a signaling protocol document should address this, or should this >>not be dealt with in signaling (which is nearly 100% of what we are >>defining -- only!) IMO... >> >>James >> >>At 02:16 PM 10/6/2008, Brian Rosen wrote: >> >It was defined in draft-rosen-ecrit-abpd-reqs-00. It was: >> >when on an emergency call, a caller hangs up the call before the call >taker >> >is finished acquiring enough information. >> > >> >Brian >> > >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> >Henning Schulzrinne >> >Sent: Monday, October 06, 2008 2:27 PM >> >To: Hannes Tschofenig >> >Cc: 'ECRIT' >> >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination >> > >> >I agree with Ted's concerns. In particular, "premature call >> >termination" has never been defined precisely and many of the fears >> >are based on the old single-line physical phone model which just don't >> >apply here. Carrying forward notions that apply to black phones with >> >rotary dials just seems unhelpful. In particular, the topic is >> >strongly connected to call-back and should not be treated in isolation. >> > >> >Henning >> > >> >On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote: >> > >> > > Hi all, >> > > >> > > we had a chat with Jon on how to make some progress on the subject >> > > of "Premature Call Termination" and here is the plan we came up with: >> > > >> > > * We delete the sentence that talks about the UAC not generating a >> > > BYE request in >> > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt >> > > We progress the document through the IETF process as "planned". >> > > >> > > * At the same time we create a design team in ECRIT to work on >> > > "Premature Call Termination". >> > > >> > > Depending on the progress of the design team we are able to >> > > incorporate the results of it into the document (even at a fairly >> > > late stage >> > > of the document process). If the design team does not produce >> > > results then anything that comes out of it can be seen as an >> > > extension to the >> > > Phone BCP document. >> > > >> > > We need members for the design team! We have already received the >> > > commitment of folks from NENA but we also need some guys from the >> > > ECRIT group. Who is interested in participating? >> > > >> > > Ciao >> > > Hannes & Marc >> > > >> > > _______________________________________________ > > > > 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 >> > >> >_______________________________________________ >> >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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 7 14:10:21 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA2B3A6967; Tue, 7 Oct 2008 14:10:21 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452C23A6967 for ; Tue, 7 Oct 2008 14:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=-2.111, BAYES_00=-2.599, SARE_URGBIZ=0.725, URG_BIZ=1.585, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIvHVaDXuKvo for ; Tue, 7 Oct 2008 14:10:17 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 906133A6889 for ; Tue, 7 Oct 2008 14:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1223413857; x=1254949857; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<04e701c928a4$d9277880$8 b766980$@net>|References:=20<48EA3476.6000806@gmx.net>=0D =0A=20=0D=0A=20<02eb01c927e8$18468320$48d38960$@net>=0D=0A =20=0D=0A=20<034401c927f9$7c1041f0$7430c5d0$@net>=0D=0A=20 =0D=0A=20<048201c92887$37bb2f40$a7318dc0$@net>=0D=0A=20

=0D=0A=20<04e701c928 a4$d9277880$8b766980$@net>|Date:=20Tue,=207=20Oct=202008 =2014:10:12=20-0700|To:=20Brian=20Rosen=20,=20"'James=20M.=20Polk'"=20,=0D=0A =20=20=20=20=20=20=20=20"'Henning=20Schulzrinne'"=20,=0D=0A=20=20=20=20=20=20=20=20"'Hannes =20Tschofenig'"=0D=0A=09|From: =20Ted=20Hardie=20|Subject:=20RE:=20 [Ecrit]=20IETF=20ECRIT=20Design=20Team=20on=20Premature =20Call=20=20=20Termination|CC:=20"'ECRIT'"=20|Content-Type:=20text/plain=3B=20charset=3D"us-ascii "|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5400"=3B =20a=3D"10167512"; bh=BNTDJZttq+zjHdASuohCj/TPsYrHyshRN0Zp5jb+zSM=; b=ih063kUToDGSnD4K7o0tGFLGaecspJP8lLD+4o8WSQ8yrzRC7YZWy//v ZHMkRJtcHF6vRmpe3tox03nlrbqCAxs4JZsL+1UmYKxgCNIQhi+ej46d/ Hfdb/16jDJGIVzN9ChEHXNXdqcgTr3HFZ7gNopn4A54cqOXl3RMPB8b0c s=; X-IronPort-AV: E=McAfee;i="5300,2777,5400"; a="10167512" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Oct 2008 14:10:16 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m97LAGpo020288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Oct 2008 14:10:16 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m97LAFSk025943 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Oct 2008 14:10:15 -0700 Received: from [10.227.68.106] (10.227.68.106) by qcmail1.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 7 Oct 2008 14:10:14 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <04e701c928a4$d9277880$8b766980$@net> References: <48EA3476.6000806@gmx.net> <02eb01c927e8$18468320$48d38960$@net> <034401c927f9$7c1041f0$7430c5d0$@net> <048201c92887$37bb2f40$a7318dc0$@net> <04e701c928a4$d9277880$8b766980$@net> Date: Tue, 7 Oct 2008 14:10:12 -0700 To: Brian Rosen , "'James M. Polk'" , "'Henning Schulzrinne'" , "'Hannes Tschofenig'" From: Ted Hardie Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 10:48 AM -0700 10/7/08, Brian Rosen wrote: >It is in use in some jurisdictions now. To clarify, this system works now only with wireline deployments, not with any cellular technology, right? What happens in Canada or other jurisdictions when cell phone callers abandon calls or disconnect before the call taker would have? Ted > Canada is an example. It was >deployed in the U.S., it got lost, and they mostly want it back. It is not >deployed in some areas. The requirements state that if it's not needed, it >doesn't stop termination, which implies some feature signaling with the >appropriate defaults. > >In jurisdictions that have it deployed, I am not aware of the kind of >problems you were imagining. The current implementations put the call taker >in charge of signaling alerts. > >Brian > >-----Original Message----- >From: Ted Hardie [mailto:hardie@qualcomm.com] >Sent: Tuesday, October 07, 2008 1:15 PM >To: Brian Rosen; 'James M. Polk'; 'Henning Schulzrinne'; 'Hannes Tschofenig' >Cc: 'ECRIT' >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > >At 7:15 AM -0700 10/7/08, Brian Rosen wrote: >>It's manual, not automatic. >> >>When the PSAP call taker decides the call is over, then call termination >>occurs. They release the call (with a button). In the proposed >mechanisms, >>the caller cannot terminate until then. > >Is my memory correct that this mechanism is currently in place >in Canada, desired by some operators in the U.S., but not a universal >practice? One of my concerns here is that we do not impose this >model onto systems which do not work this way now by encoding >it into the signalling protocols. If, for example, it is the presumption >of certain types of emergency services (spousal abuse crisis centers, >to take an example), that the caller must always be able to >terminate a call as swiftly and silently as possible, anything that >keeps the call up so that an abusive spouse can hear that a call >is present may be counter-productive. [This is not meant to reflect >any real-world experience with these centers, as I have none. This >is simply a way of getting at the idea that the desire to allow >user termination may also occur because of a specific emergency >setting; kidnap and home invasion have been used as examples >in the past.] > > >>The signaling is how the call taker keeps the call up, how the UA signals >>its state (on hook/off hook or its logical equivalent) to the PSAP and how >>the PSAP signals various alerts (ringing, howler, etc) to the UA. The >>concern that has to be addressed is making sure that in failure conditions, >>we don't "brick" the UA. >> >>Please remember there are two problems: >>Premature Disconnect, which is what we are talking about, and "Abandoned >>Call", which is where the caller attempts to abandon placing an emergency >>call before it is answered by the PSAP. These really are the same thing, > >I think that is a remarkable presumption. They may not be the same >thing at all. In jurisdictions which have multiple response numbers, >for example, an abandoned call might reflect a realization from the >caller that they need to call a different emergency number (I called >the police when the fight started, but before they answered, I realized >we urgently need medical response. Or, I called for medical help then >saw the bottle that tells me I need a poison-specific response.). > >Systems which do not acknowledge that the people making these calls >may have knowledge that causes them to change their response to >an emergency should not be encoded in the signalling in my view. >I am also seriously worried about the interaction of this with the >no-SIM test call problem. If PSAPs MUST respond to these calls >and handle abandoned calls, abandoned test calls take on an >even more problematic aspect. At least now, those callers can >hang up when they hear a ring. > > >>but the signaling problem is different. In "Premature Disconnect", the >call >>completed, the call taker has answered, and conversation started. >"Abandoned >>Call" is an attempt to take the call down some time between when the >>original call was placed and the beginning of that period. >> >>Brian >> >>-----Original Message----- >>From: James M. Polk [mailto:jmpolk@cisco.com] >>Sent: Monday, October 06, 2008 8:07 PM >>To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig' >>Cc: 'ECRIT' >>Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination >> >>OK, fair, I'm glad we are going in the precise direction. But I am >>curious about who determines "precise" within the PSAP (per your >>suggestion). Is it the call taker themselves, or is this somehow >>incorporated into a signaling protocol? >> >>It seems like the IETF is concerned with how this can be done in >>signaling somehow. >> >>I'm wonder aloud if this can be done in signaling either >>automatically (as a response or new transaction) to the calling party >>when some automaton determines it has received enough information >>(which is determined by a configurable API to know which fields or >>buckets get filled from the inbound signaling)? >> >>Or if the call taker hits a button - indicating they have enough >>information to allow the caller to terminate the call -- knowing >>there is sufficient location and/or callback information for this call? >> >>To me, these are completely different. In fact, I could argue that >>the idea that a call taker make a mental decision that they have >>enough information about the caller is something that is a brand new >>type of requirement, and one that inherently doesn't have precedent >>in today's architectures anywhere. This means we need to look at >>this as a fresh req that may or may not be necessary. >> >>just thinking out loud... >> >>At 04:21 PM 10/6/2008, Brian Rosen wrote: >>>No, actually, it's pretty precise. It's "premature" unless the PSAP says >>>otherwise (that is, if the caller attempts to disconnect before the PSAP >>>does, then it's a premature disconnect). >>> >>>Brian >>> >>>-----Original Message----- >>>From: James M. Polk [mailto:jmpolk@cisco.com] >>>Sent: Monday, October 06, 2008 4:01 PM >>>To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig' >>>Cc: 'ECRIT' >>>Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination >>> >>>This sounds a bit like a subjective thing, verses a quantifiable >>>definitive thing. >>> >>>How exactly does a UAC know when it has achieved this status (i.e., >>>provided enough information)? >>> >>>I assume the goal is to have something in signaling that communicates >>>this to the UAC, right? >>> >>>Or is this merely at the discretion of the called party (i.e., the >>>call taker's personal satisfaction)? >>> >>>Where I'm going with this is that I'm beginning to wonder if, then >>>how a signaling protocol document should address this, or should this >>>not be dealt with in signaling (which is nearly 100% of what we are >>>defining -- only!) IMO... >>> >>>James >>> >>>At 02:16 PM 10/6/2008, Brian Rosen wrote: >>> >It was defined in draft-rosen-ecrit-abpd-reqs-00. It was: >>> >when on an emergency call, a caller hangs up the call before the call >>taker >>> >is finished acquiring enough information. >>> > >>> >Brian >>> > >>> >-----Original Message----- >>> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of >>> >Henning Schulzrinne >>> >Sent: Monday, October 06, 2008 2:27 PM >>> >To: Hannes Tschofenig >>> >Cc: 'ECRIT' >>> >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call >Termination >>> > >>> >I agree with Ted's concerns. In particular, "premature call >>> >termination" has never been defined precisely and many of the fears >>> >are based on the old single-line physical phone model which just don't >>> >apply here. Carrying forward notions that apply to black phones with >>> >rotary dials just seems unhelpful. In particular, the topic is >>> >strongly connected to call-back and should not be treated in isolation. >>> > >>> >Henning >>> > >>> >On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote: > >> > >>> > > Hi all, >>> > > >>> > > we had a chat with Jon on how to make some progress on the subject >>> > > of "Premature Call Termination" and here is the plan we came up with: >>> > > >>> > > * We delete the sentence that talks about the UAC not generating a >>> > > BYE request in >>> > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt >>> > > We progress the document through the IETF process as "planned". >>> > > >>> > > * At the same time we create a design team in ECRIT to work on >>> > > "Premature Call Termination". >>> > > >>> > > Depending on the progress of the design team we are able to >>> > > incorporate the results of it into the document (even at a fairly >>> > > late stage >>> > > of the document process). If the design team does not produce >>> > > results then anything that comes out of it can be seen as an >>> > > extension to the >>> > > Phone BCP document. >>> > > >>> > > We need members for the design team! We have already received the >>> > > commitment of folks from NENA but we also need some guys from the >>> > > ECRIT group. Who is interested in participating? >>> > > >>> > > Ciao >>> > > Hannes & Marc >>> > > >>> > > _______________________________________________ >> > > > 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 >>> > >>> >_______________________________________________ >>> >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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 7 14:27:31 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88D5F3A6AA0; Tue, 7 Oct 2008 14:27:31 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F85F3A686C for ; Tue, 7 Oct 2008 14:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPDlvs31fl2j for ; Tue, 7 Oct 2008 14:27:29 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2F2643A6AB0 for ; Tue, 7 Oct 2008 14:27:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,375,1220227200"; d="scan'208";a="23526445" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 07 Oct 2008 21:28:07 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m97LS7l9007567; Tue, 7 Oct 2008 17:28:07 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m97LS7Fx022138; Tue, 7 Oct 2008 21:28:07 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Oct 2008 17:28:07 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Oct 2008 17:28:06 -0400 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Tue, 07 Oct 2008 17:28:04 -0400 From: Marc Linsner To: Brian Rosen Message-ID: Thread-Topic: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Thread-Index: AckooC/i8oVjuBu8S0uFXP7ygv670wABB+lAAAfRXW4= In-Reply-To: <04e701c928a4$d9277880$8b766980$@net> Mime-version: 1.0 X-OriginalArrivalTime: 07 Oct 2008 21:28:06.0701 (UTC) FILETIME=[96976DD0:01C928C3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1399; t=1223414887; x=1224278887; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20IETF=20ECRIT=20Design=20Team= 20on=20Premature=20Call=20=20=20Termination |Sender:=20 |To:=20Brian=20Rosen=20; bh=OPMamItgsrySV9Z7Pmn1ottvGVH5Vvxs45luy5eePxw=; b=FDFrCLhr7ch4erQtvgzMbZEZG539MFKI54LyKDUVmtsh1GFMBniRSqXQmX bea0CtEE/IY5VA1jsAktnC90qgrySjxXYsyF47kxUpw7cRCKCA+8YpoINiok 404tzZR6SG; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, On 10/7/08 1:48 PM, "Brian Rosen" wrote: > It is in use in some jurisdictions now. Canada is an example. It was > deployed in the U.S., it got lost, and they mostly want it back. It is not > deployed in some areas. The requirements state that if it's not needed, it > doesn't stop termination, which implies some feature signaling with the > appropriate defaults. Remember, in the jurisdictions where this is currently deployed, it works for only 35% of 9-1-1 calls (as 65% are from cellular). > > In jurisdictions that have it deployed, I am not aware of the kind of > problems you were imagining. The current implementations put the call taker > in charge of signaling alerts. > > Brian > > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Tuesday, October 07, 2008 1:15 PM > To: Brian Rosen; 'James M. Polk'; 'Henning Schulzrinne'; 'Hannes Tschofenig' > Cc: 'ECRIT' > Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > > At 7:15 AM -0700 10/7/08, Brian Rosen wrote: >> It's manual, not automatic. >> >> When the PSAP call taker decides the call is over, then call termination >> occurs. They release the call (with a button). In the proposed > mechanisms, >> the caller cannot terminate until then. What document contains the proposed mechanisms? -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 7 16:41:20 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504713A689F; Tue, 7 Oct 2008 16:41:20 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBAB23A681A for ; Tue, 7 Oct 2008 16:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeqeKJqEbPz3 for ; Tue, 7 Oct 2008 16:41:17 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7F1283A6767 for ; Tue, 7 Oct 2008 16:41:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,376,1220227200"; d="scan'208";a="107133920" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 07 Oct 2008 23:41:57 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m97NfvSC005330; Tue, 7 Oct 2008 16:41:57 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m97NfvR1003784; Tue, 7 Oct 2008 23:41:57 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Oct 2008 16:41:57 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.148.6]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Oct 2008 16:41:56 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 07 Oct 2008 18:42:13 -0500 To: "Brian Rosen" , "'Henning Schulzrinne'" , "'Hannes Tschofenig'" From: "James M. Polk" In-Reply-To: <048201c92887$37bb2f40$a7318dc0$@net> References: <48EA3476.6000806@gmx.net> <02eb01c927e8$18468320$48d38960$@net> <034401c927f9$7c1041f0$7430c5d0$@net> <048201c92887$37bb2f40$a7318dc0$@net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 07 Oct 2008 23:41:56.0648 (UTC) FILETIME=[48D01A80:01C928D6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7870; t=1223422917; x=1224286917; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20IETF=20ECRIT=20Design=20Team= 20on=20Premature=20Call=20=20=0A=20=20Termination |Sender:=20; bh=0j28rGC4j3lu7bftACY3AVkpUmvtmWIcTKfX7f0Z7sc=; b=NDVfs+9jwTBWqTDALIrdNnlBpnq7TTJ7va9SZL1Vo5rx7Ko+vPraFjWZqn ibP114UoAHurnmPMvG+OsvPrbib7k2/q5rYcTzPBvIJV+sT/Z7ZGo4jPK+0L pDBOM7OYQI8wBhQzB8bEuS8ljbYx+ZaTzJ5u6i7pLsUSQiTzll5gY=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org in-line At 09:15 AM 10/7/2008, Brian Rosen wrote: >It's manual, not automatic. I'm wondering if it can/should be automated, that once the receiver fills all the fields it needs to fill, the caller can now disconnect whenever they wish (because sufficient location has been conveyed, and the callback number/URI has been captured - both by the PSAP UAS).... >When the PSAP call taker decides the call is over, then call termination >occurs. This means the UAC cannot send a BYE (you can spin it any other way, this is the results of what you are looking for) > They release the call (with a button). In the proposed mechanisms, >the caller cannot terminate until then. This seems like the no one can terminate the call until the call taker does (which means the caller doesn't have the ability to send a BYE) >The signaling is how the call taker keeps the call up, how the UA signals >its state (on hook/off hook or its logical equivalent) to the PSAP and how >the PSAP signals various alerts (ringing, howler, etc) to the UA. >The >concern that has to be addressed is making sure that in failure conditions, >we don't "brick" the UA. that would be bad! >Please remember there are two problems: >Premature Disconnect, which is what we are talking about, and "Abandoned >Call", which is where the caller attempts to abandon placing an emergency >call before it is answered by the PSAP. The latter of these appears to me to be a prevention of sending a CANCEL request, in addition to a BYE... this "feature" is expanding (or creeping) >These really are the same thing, >but the signaling problem is different. In "Premature Disconnect", the call >completed, the call taker has answered, and conversation started. "Abandoned >Call" is an attempt to take the call down some time between when the >original call was placed and the beginning of that period. i.e., sending a CANCEL, regardless of Reason header, is also prevented I have to think about that one before I agree it's a good idea in all cases. There's easily one good case for it (robber hangs up the call), one annoying case (prank call), and one honest mistaken case (unintended call) >Brian > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Monday, October 06, 2008 8:07 PM >To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig' >Cc: 'ECRIT' >Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > >OK, fair, I'm glad we are going in the precise direction. But I am >curious about who determines "precise" within the PSAP (per your >suggestion). Is it the call taker themselves, or is this somehow >incorporated into a signaling protocol? > >It seems like the IETF is concerned with how this can be done in >signaling somehow. > >I'm wonder aloud if this can be done in signaling either >automatically (as a response or new transaction) to the calling party >when some automaton determines it has received enough information >(which is determined by a configurable API to know which fields or >buckets get filled from the inbound signaling)? > >Or if the call taker hits a button - indicating they have enough >information to allow the caller to terminate the call -- knowing >there is sufficient location and/or callback information for this call? > >To me, these are completely different. In fact, I could argue that >the idea that a call taker make a mental decision that they have >enough information about the caller is something that is a brand new >type of requirement, and one that inherently doesn't have precedent >in today's architectures anywhere. This means we need to look at >this as a fresh req that may or may not be necessary. > >just thinking out loud... > >At 04:21 PM 10/6/2008, Brian Rosen wrote: > >No, actually, it's pretty precise. It's "premature" unless the PSAP says > >otherwise (that is, if the caller attempts to disconnect before the PSAP > >does, then it's a premature disconnect). > > > >Brian > > > >-----Original Message----- > >From: James M. Polk [mailto:jmpolk@cisco.com] > >Sent: Monday, October 06, 2008 4:01 PM > >To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig' > >Cc: 'ECRIT' > >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > > > >This sounds a bit like a subjective thing, verses a quantifiable > >definitive thing. > > > >How exactly does a UAC know when it has achieved this status (i.e., > >provided enough information)? > > > >I assume the goal is to have something in signaling that communicates > >this to the UAC, right? > > > >Or is this merely at the discretion of the called party (i.e., the > >call taker's personal satisfaction)? > > > >Where I'm going with this is that I'm beginning to wonder if, then > >how a signaling protocol document should address this, or should this > >not be dealt with in signaling (which is nearly 100% of what we are > >defining -- only!) IMO... > > > >James > > > >At 02:16 PM 10/6/2008, Brian Rosen wrote: > > >It was defined in draft-rosen-ecrit-abpd-reqs-00. It was: > > >when on an emergency call, a caller hangs up the call before the call >taker > > >is finished acquiring enough information. > > > > > >Brian > > > > > >-----Original Message----- > > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > > >Henning Schulzrinne > > >Sent: Monday, October 06, 2008 2:27 PM > > >To: Hannes Tschofenig > > >Cc: 'ECRIT' > > >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > > > > > >I agree with Ted's concerns. In particular, "premature call > > >termination" has never been defined precisely and many of the fears > > >are based on the old single-line physical phone model which just don't > > >apply here. Carrying forward notions that apply to black phones with > > >rotary dials just seems unhelpful. In particular, the topic is > > >strongly connected to call-back and should not be treated in isolation. > > > > > >Henning > > > > > >On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote: > > > > > > > Hi all, > > > > > > > > we had a chat with Jon on how to make some progress on the subject > > > > of "Premature Call Termination" and here is the plan we came up with: > > > > > > > > * We delete the sentence that talks about the UAC not generating a > > > > BYE request in > > > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt > > > > We progress the document through the IETF process as "planned". > > > > > > > > * At the same time we create a design team in ECRIT to work on > > > > "Premature Call Termination". > > > > > > > > Depending on the progress of the design team we are able to > > > > incorporate the results of it into the document (even at a fairly > > > > late stage > > > > of the document process). If the design team does not produce > > > > results then anything that comes out of it can be seen as an > > > > extension to the > > > > Phone BCP document. > > > > > > > > We need members for the design team! We have already received the > > > > commitment of folks from NENA but we also need some guys from the > > > > ECRIT group. Who is interested in participating? > > > > > > > > Ciao > > > > Hannes & Marc > > > > > > > > _______________________________________________ > > > > 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 > > > > > >_______________________________________________ > > >Ecrit mailing list > > >Ecrit@ietf.org > > >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 8 05:51:12 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059CF3A6774; Wed, 8 Oct 2008 05:51:12 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB6ED3A659A for ; Wed, 8 Oct 2008 05:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1s5mlRwEpnrS for ; Wed, 8 Oct 2008 05:51:10 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 0E8853A6774 for ; Wed, 8 Oct 2008 05:51:10 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KnYV1-0007oR-J9; Wed, 08 Oct 2008 07:50:43 -0500 From: "Brian Rosen" To: "'Marc Linsner'" References: <04e701c928a4$d9277880$8b766980$@net> In-Reply-To: Date: Wed, 8 Oct 2008 08:50:41 -0400 Message-ID: <068a01c92944$7a72d230$6f587690$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckooC/i8oVjuBu8S0uFXP7ygv670wABB+lAAAfRXW4AH/rlAA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org So, what, because wireless carriers refused to implement it, despite repeated requests to do so, and wireless is now more popular, we should strike the requirement? PSAPs I talk to consider this a requirement. They are VERY unhappy the carriers do not honor the requirement, in both wireline and wireless, in the U.S. Canada is very unhappy about the wireless situation. Both are adamant that they have a REQUIREMENT for this capability. As with any other protocol issue, there are no protocol police. We can define the mechanism, but implementation may or may not occur. The PSAPs have a requirement. It comes from experience. We should honor it I think. Brian -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Tuesday, October 07, 2008 5:28 PM To: Brian Rosen Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Brian, On 10/7/08 1:48 PM, "Brian Rosen" wrote: > It is in use in some jurisdictions now. Canada is an example. It was > deployed in the U.S., it got lost, and they mostly want it back. It is not > deployed in some areas. The requirements state that if it's not needed, it > doesn't stop termination, which implies some feature signaling with the > appropriate defaults. Remember, in the jurisdictions where this is currently deployed, it works for only 35% of 9-1-1 calls (as 65% are from cellular). > > In jurisdictions that have it deployed, I am not aware of the kind of > problems you were imagining. The current implementations put the call taker > in charge of signaling alerts. > > Brian > > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Tuesday, October 07, 2008 1:15 PM > To: Brian Rosen; 'James M. Polk'; 'Henning Schulzrinne'; 'Hannes Tschofenig' > Cc: 'ECRIT' > Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > > At 7:15 AM -0700 10/7/08, Brian Rosen wrote: >> It's manual, not automatic. >> >> When the PSAP call taker decides the call is over, then call termination >> occurs. They release the call (with a button). In the proposed > mechanisms, >> the caller cannot terminate until then. What document contains the proposed mechanisms? -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 8 06:20:42 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32A53A6892; Wed, 8 Oct 2008 06:20:42 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8C253A6892 for ; Wed, 8 Oct 2008 06:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4SsKXgOLY39 for ; Wed, 8 Oct 2008 06:20:40 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 941E93A6803 for ; Wed, 8 Oct 2008 06:20:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,378,1220227200"; d="scan'208";a="23626752" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 08 Oct 2008 13:20:23 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m98DKMqG002880; Wed, 8 Oct 2008 09:20:23 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m98DKLUP003392; Wed, 8 Oct 2008 13:20:22 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 09:19:10 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 09:19:09 -0400 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 08 Oct 2008 09:19:07 -0400 From: Marc Linsner To: Brian Rosen Message-ID: Thread-Topic: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Thread-Index: AckooC/i8oVjuBu8S0uFXP7ygv670wABB+lAAAfRXW4AH/rlAAABPCgY In-Reply-To: <068a01c92944$7a72d230$6f587690$@net> Mime-version: 1.0 X-OriginalArrivalTime: 08 Oct 2008 13:19:09.0389 (UTC) FILETIME=[729A9FD0:01C92948] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2867; t=1223472023; x=1224336023; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20IETF=20ECRIT=20Design=20Team= 20on=20Premature=20Call=20=20=20Termination |Sender:=20 |To:=20Brian=20Rosen=20; bh=JYc0TeBpHl4rGoeEV2AB7Q66UWrifeuVYVO4jEDZfXw=; b=ekxPLhHGPXJ5bJAwL8ba45QcUuT7LtfgAkoGdGv2CzjCc1piURI7nAF2yQ snp2FLpmJ44D50i398cc4SEJJKTwP2xEkV7GledOoFEgi5Be5dnhlqs904a2 6GyZNPRTTe; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, I have no problem entertaining new requirements. I simply want the motivation ("We have to do this because") to be spun correctly. I also believe this demands a viewpoint from the 'other' party, the PSAP customer, Joe Citizen. If in fact a solution can to designed that fulfills the requirement and protects Joe's desires, I have no problem. -Marc- On 10/8/08 8:50 AM, "Brian Rosen" wrote: > So, what, because wireless carriers refused to implement it, despite > repeated requests to do so, and wireless is now more popular, we should > strike the requirement? > > PSAPs I talk to consider this a requirement. They are VERY unhappy the > carriers do not honor the requirement, in both wireline and wireless, in the > U.S. Canada is very unhappy about the wireless situation. Both are adamant > that they have a REQUIREMENT for this capability. > > As with any other protocol issue, there are no protocol police. We can > define the mechanism, but implementation may or may not occur. The PSAPs > have a requirement. It comes from experience. We should honor it I think. > > Brian > > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Tuesday, October 07, 2008 5:28 PM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > > Brian, > > On 10/7/08 1:48 PM, "Brian Rosen" wrote: > >> It is in use in some jurisdictions now. Canada is an example. It was >> deployed in the U.S., it got lost, and they mostly want it back. It is > not >> deployed in some areas. The requirements state that if it's not needed, > it >> doesn't stop termination, which implies some feature signaling with the >> appropriate defaults. > > Remember, in the jurisdictions where this is currently deployed, it works > for only 35% of 9-1-1 calls (as 65% are from cellular). > >> >> In jurisdictions that have it deployed, I am not aware of the kind of >> problems you were imagining. The current implementations put the call > taker >> in charge of signaling alerts. >> >> Brian >> >> -----Original Message----- >> From: Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: Tuesday, October 07, 2008 1:15 PM >> To: Brian Rosen; 'James M. Polk'; 'Henning Schulzrinne'; 'Hannes > Tschofenig' >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination >> >> At 7:15 AM -0700 10/7/08, Brian Rosen wrote: >>> It's manual, not automatic. >>> >>> When the PSAP call taker decides the call is over, then call termination >>> occurs. They release the call (with a button). In the proposed >> mechanisms, >>> the caller cannot terminate until then. > > What document contains the proposed mechanisms? > > -Marc- > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 8 07:03:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1C143A6BD8; Wed, 8 Oct 2008 07:03:14 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F743A6A9B for ; Wed, 8 Oct 2008 07:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jo1l4R+Og0qj for ; Wed, 8 Oct 2008 07:03:13 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id CFA013A6BD6 for ; Wed, 8 Oct 2008 07:03:12 -0700 (PDT) Received: from [192.168.0.61] (pool-71-250-72-76.nwrknj.east.verizon.net [71.250.72.76]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m98E3T6S025441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Oct 2008 10:03:30 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Marc Linsner In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 8 Oct 2008 10:03:29 -0400 References: X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org No requirement stands on its own. Particularly in this case, proposed solutions have had severe side effects that may well outweigh whatever call handling functionality is gained. Thus, we need to look at the whole picture, not just one requirement. For example, any such mechanism must not brick a caller's phone, must not create the ability to eavesdrop on users and must not increase security vulnerabilities. It may also help to have a less-mechanism-focused requirement. Since the user has placed the receiver on hook (on a traditional phone, at least), from a user perspective, this is no different than being called back, unless you indeed make the phone non-operable. In the end, the user also has a right to be left alone. If the caller no longer wants to talk to the PSAP, forcing him to do that seems inappropriate and may well be against the law (or at least should be, in a society that calls itself free). We want to prevent accidental disconnects, but the PSAP has no right to take over the user's phone, listen to the user's environment without permission or perform other intrusive acts. Unfortunately, the current requirement document does not reflect any of these concerns. Henning On Oct 8, 2008, at 9:19 AM, Marc Linsner wrote: > Brian, > > I have no problem entertaining new requirements. I simply want the > motivation ("We have to do this because") to be spun correctly. > > I also believe this demands a viewpoint from the 'other' party, the > PSAP > customer, Joe Citizen. > > If in fact a solution can to designed that fulfills the requirement > and > protects Joe's desires, I have no problem. > > -Marc- > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 8 08:25:52 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253863A6BD0; Wed, 8 Oct 2008 08:25:52 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F313A6B30 for ; Wed, 8 Oct 2008 08:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSRl1VrPeh96 for ; Wed, 8 Oct 2008 08:25:50 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 3C8D53A67DF for ; Wed, 8 Oct 2008 08:25:49 -0700 (PDT) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m98FPD25019223; Wed, 8 Oct 2008 10:25:13 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 10:25:13 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 17:25:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Oct 2008 17:25:13 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180023B06A7@DEEXC1U01.de.lucent.com> In-Reply-To: <068a01c92944$7a72d230$6f587690$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Thread-Index: AckooC/i8oVjuBu8S0uFXP7ygv670wABB+lAAAfRXW4AH/rlAAAFmpzQ References: <04e701c928a4$d9277880$8b766980$@net> <068a01c92944$7a72d230$6f587690$@net> From: "DRAGE, Keith \(Keith\)" To: "Brian Rosen" , "Marc Linsner" X-OriginalArrivalTime: 08 Oct 2008 15:25:09.0999 (UTC) FILETIME=[0D1427F0:01C9295A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: ECRIT Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org So now we seem to be indulging in the discussion of whether we should honour the requirements. There are still open issues on the requirements that have been raised. Until we have got the requirements right, we cannot decide that we should work on implementing them or not. Regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Wednesday, October 08, 2008 1:51 PM > To: 'Marc Linsner' > Cc: 'ECRIT' > Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call > Termination > > So, what, because wireless carriers refused to implement it, > despite repeated requests to do so, and wireless is now more > popular, we should strike the requirement? > > PSAPs I talk to consider this a requirement. They are VERY > unhappy the carriers do not honor the requirement, in both > wireline and wireless, in the U.S. Canada is very unhappy > about the wireless situation. Both are adamant that they > have a REQUIREMENT for this capability. > > As with any other protocol issue, there are no protocol > police. We can define the mechanism, but implementation may > or may not occur. The PSAPs have a requirement. It comes > from experience. We should honor it I think. > > Brian > > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Tuesday, October 07, 2008 5:28 PM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call > Termination > > Brian, > > On 10/7/08 1:48 PM, "Brian Rosen" wrote: > > > It is in use in some jurisdictions now. Canada is an > example. It was > > deployed in the U.S., it got lost, and they mostly want it > back. It > > is > not > > deployed in some areas. The requirements state that if it's not > > needed, > it > > doesn't stop termination, which implies some feature signaling with > > the appropriate defaults. > > Remember, in the jurisdictions where this is currently > deployed, it works for only 35% of 9-1-1 calls (as 65% are > from cellular). > > > > > In jurisdictions that have it deployed, I am not aware of > the kind of > > problems you were imagining. The current implementations > put the call > taker > > in charge of signaling alerts. > > > > Brian > > > > -----Original Message----- > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > Sent: Tuesday, October 07, 2008 1:15 PM > > To: Brian Rosen; 'James M. Polk'; 'Henning Schulzrinne'; 'Hannes > Tschofenig' > > Cc: 'ECRIT' > > Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call > > Termination > > > > At 7:15 AM -0700 10/7/08, Brian Rosen wrote: > >> It's manual, not automatic. > >> > >> When the PSAP call taker decides the call is over, then call > >> termination occurs. They release the call (with a > button). In the > >> proposed > > mechanisms, > >> the caller cannot terminate until then. > > What document contains the proposed mechanisms? > > -Marc- > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 8 09:30:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D3B3A6B9F; Wed, 8 Oct 2008 09:30:14 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DCBC28C155 for ; Wed, 8 Oct 2008 09:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.291 X-Spam-Level: X-Spam-Status: No, score=-105.291 tagged_above=-999 required=5 tests=[AWL=1.308, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOhTaJFsa1o1 for ; Wed, 8 Oct 2008 09:30:08 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id CFFFB3A6892 for ; Wed, 8 Oct 2008 09:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1223483450; x=1255019450; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20=0D=0A=20|Date:=20Wed,=208=20Oct=20200 8=2009:30:12=20-0700|To:=20Henning=20Schulzrinne=20,=0D=0A=20=20=20=20=20=20=20=20Marc=20Lins ner=0D=0A=09|From:=20Ted=20Hardie=20< hardie@qualcomm.com>|Subject:=20Re:=20[Ecrit]=20IETF=20EC RIT=20Design=20Team=20on=20Premature=20Call=20=20=20Termi nation|CC:=20"'ECRIT'"=20|Content-Type: =20text/plain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20 E=3DMcAfee=3Bi=3D"5300,2777,5400"=3B=20a=3D"10351213"; bh=9hbdaZIJU38azwUxcIgF5rABTQsb7kaDaBXHxeu8SL0=; b=rXqzLRBzzvHCXrJkJpeJ9WV0IhRnglJ5eIvbVxkhIEO7tBSXmzfQlh9e qFUn0B9SNE65XDqWZ3BJQ0wUdmooxqH2xdFcOK/DTH2Mh92X6Xkn4WSU0 PiHeOQWUipcE9gcKwbgG2UWEniXYfYGTyXbxjLGJoz0exbLR+7HY/TkMe M=; X-IronPort-AV: E=McAfee;i="5300,2777,5400"; a="10351213" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Oct 2008 09:30:16 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m98GUGfP025725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Oct 2008 09:30:16 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m98GUFZg022657 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Oct 2008 09:30:15 -0700 (PDT) Received: from [10.227.68.106] (10.227.68.106) by qcmail1.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 8 Oct 2008 09:30:15 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: Date: Wed, 8 Oct 2008 09:30:12 -0700 To: Henning Schulzrinne , Marc Linsner From: Ted Hardie Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 7:03 AM -0700 10/8/08, Henning Schulzrinne wrote: >No requirement stands on its own. Particularly in this case, proposed >solutions have had severe side effects that may well outweigh whatever >call handling functionality is gained. Thus, we need to look at the >whole picture, not just one requirement. The "whole picture" issue is the key point here, and I agree with Henning that some of the key issues we need to treat are whether the mechanism interferes with the user's use of the phone, whether it creates security vulnerabilities, and whether it has privacy implications. I also worry, personally, that the introduction of this requirement implies either a new requirement for a negotiation phase or that other responders take up this behavior. Both possibilities introduce fragility into the system and its deployment. As an additional point, I really question whether the right place to do this is in the network protocol. The majority of this behavior is actually better achieved in the UI, at least in my opinion. Having the phone software disable the terminate button for emergency calls and emit a warning when it is pressed gets the 80% of the 80/20 with no protocol behavior at all. I think you'd have to have some UI changes anyway, simply because this requirement violates the principle of least surprise. If I think pressing the red button ends a call and it does for every call but calls to 911 in Canada, you're going to want some additional UI signal to let the user known the call didn't end. Having the PSAPs say "We have a requirement" is a useful part of the dialog on this, and goodness knows that the IETF is not filled with the sum total of expertise in this area. But we may well have the expertise to say "This belongs in some other part of the system in a world based on multi-line phones using VoIP; the circuit switched model for this won't work well here". In fact, I think we *have* said that, and we're trying to achieve consensus while talking past each other. To quote my favorite flying squirrel: "That trick never works". Ted >For example, any such >mechanism must not brick a caller's phone, must not create the ability >to eavesdrop on users and must not increase security vulnerabilities. >It may also help to have a less-mechanism-focused requirement. Since >the user has placed the receiver on hook (on a traditional phone, at >least), from a user perspective, this is no different than being >called back, unless you indeed make the phone non-operable. > >In the end, the user also has a right to be left alone. If the caller >no longer wants to talk to the PSAP, forcing him to do that seems >inappropriate and may well be against the law (or at least should be, >in a society that calls itself free). We want to prevent accidental >disconnects, but the PSAP has no right to take over the user's phone, >listen to the user's environment without permission or perform other >intrusive acts. Unfortunately, the current requirement document does >not reflect any of these concerns. > >Henning > >On Oct 8, 2008, at 9:19 AM, Marc Linsner wrote: > >> Brian, >> >> I have no problem entertaining new requirements. I simply want the >> motivation ("We have to do this because") to be spun correctly. >> >> I also believe this demands a viewpoint from the 'other' party, the >> PSAP >> customer, Joe Citizen. >> >> If in fact a solution can to designed that fulfills the requirement >> and >> protects Joe's desires, I have no problem. >> >> -Marc- >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 8 10:57:31 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9703A685B; Wed, 8 Oct 2008 10:57:31 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623613A6847 for ; Wed, 8 Oct 2008 10:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StDEIXy6X3xC for ; Wed, 8 Oct 2008 10:57:29 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 4E89B3A683F for ; Wed, 8 Oct 2008 10:57:29 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KndHX-0007Gr-6e; Wed, 08 Oct 2008 12:57:10 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Henning Schulzrinne'" , "'Marc Linsner'" References: In-Reply-To: Date: Wed, 8 Oct 2008 13:57:11 -0400 Message-ID: <073101c9296f$4ddbd110$e9937330$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckpYzx7gwWFOvaDT3Ct2aQ0XFND3wACQJ0w Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I disagree. What we have is a bunch of amateurs on how you handle emergency calls trying to tell the experts that what they want is wrong. Every one of the kinds of user related issues that have been raised have occurred enough times that we can listen to the PSAP guys who say "on balance, its better to have the PSAP control disconnect". It's not foolproof, and I agree that we can't brick a phone, and I agree you can always pull the plug or pull out the battery or whatever. There are, I believe, jurisdictions to actively don't want this feature, and others who insist it is a REQUIREMENT to have the feature. There a lots who are "it would be nice". Sure, UI is important here. Some text on multiline might be appropriate that is all about UI and But the IETF problem is the signaling: no one is arguing that it is sometimes the right thing to let the user disconnect. So it's not an absolute, "don't send BYE" or disable the button on the UI. There is negotiation of the feature. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Ted Hardie Sent: Wednesday, October 08, 2008 12:30 PM To: Henning Schulzrinne; Marc Linsner Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination At 7:03 AM -0700 10/8/08, Henning Schulzrinne wrote: >No requirement stands on its own. Particularly in this case, proposed >solutions have had severe side effects that may well outweigh whatever >call handling functionality is gained. Thus, we need to look at the >whole picture, not just one requirement. The "whole picture" issue is the key point here, and I agree with Henning that some of the key issues we need to treat are whether the mechanism interferes with the user's use of the phone, whether it creates security vulnerabilities, and whether it has privacy implications. I also worry, personally, that the introduction of this requirement implies either a new requirement for a negotiation phase or that other responders take up this behavior. Both possibilities introduce fragility into the system and its deployment. As an additional point, I really question whether the right place to do this is in the network protocol. The majority of this behavior is actually better achieved in the UI, at least in my opinion. Having the phone software disable the terminate button for emergency calls and emit a warning when it is pressed gets the 80% of the 80/20 with no protocol behavior at all. I think you'd have to have some UI changes anyway, simply because this requirement violates the principle of least surprise. If I think pressing the red button ends a call and it does for every call but calls to 911 in Canada, you're going to want some additional UI signal to let the user known the call didn't end. Having the PSAPs say "We have a requirement" is a useful part of the dialog on this, and goodness knows that the IETF is not filled with the sum total of expertise in this area. But we may well have the expertise to say "This belongs in some other part of the system in a world based on multi-line phones using VoIP; the circuit switched model for this won't work well here". In fact, I think we *have* said that, and we're trying to achieve consensus while talking past each other. To quote my favorite flying squirrel: "That trick never works". Ted >For example, any such >mechanism must not brick a caller's phone, must not create the ability >to eavesdrop on users and must not increase security vulnerabilities. >It may also help to have a less-mechanism-focused requirement. Since >the user has placed the receiver on hook (on a traditional phone, at >least), from a user perspective, this is no different than being >called back, unless you indeed make the phone non-operable. > >In the end, the user also has a right to be left alone. If the caller >no longer wants to talk to the PSAP, forcing him to do that seems >inappropriate and may well be against the law (or at least should be, >in a society that calls itself free). We want to prevent accidental >disconnects, but the PSAP has no right to take over the user's phone, >listen to the user's environment without permission or perform other >intrusive acts. Unfortunately, the current requirement document does >not reflect any of these concerns. > >Henning > >On Oct 8, 2008, at 9:19 AM, Marc Linsner wrote: > >> Brian, >> >> I have no problem entertaining new requirements. I simply want the >> motivation ("We have to do this because") to be spun correctly. >> >> I also believe this demands a viewpoint from the 'other' party, the >> PSAP >> customer, Joe Citizen. >> >> If in fact a solution can to designed that fulfills the requirement >> and >> protects Joe's desires, I have no problem. >> >> -Marc- >> > >_______________________________________________ >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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 8 11:46:33 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720963A6946; Wed, 8 Oct 2008 11:46:33 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293A63A6765 for ; Wed, 8 Oct 2008 11:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jplpt9UGDB38 for ; Wed, 8 Oct 2008 11:46:32 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id DE9643A6909 for ; Wed, 8 Oct 2008 11:46:31 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m98IkMi6026275; Wed, 8 Oct 2008 13:46:25 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 13:46:21 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 20:46:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Oct 2008 20:46:12 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180023B06DB@DEEXC1U01.de.lucent.com> In-Reply-To: <073101c9296f$4ddbd110$e9937330$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Thread-Index: AckpYzx7gwWFOvaDT3Ct2aQ0XFND3wACQJ0wAAJg5aA= References: <073101c9296f$4ddbd110$e9937330$@net> From: "DRAGE, Keith \(Keith\)" To: "Brian Rosen" , "Ted Hardie" , "Henning Schulzrinne" , "Marc Linsner" X-OriginalArrivalTime: 08 Oct 2008 18:46:18.0187 (UTC) FILETIME=[264781B0:01C92976] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: ECRIT Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Speaking as an amateur who has been working in the telecommunication industry for 30 years: There are multiple interests to balance here, and the PSAP provider is only one of these. Emergency calls do not override other telecommunication needs, the user may need to make another call, the telecommunications operator may need the resources for other purposes, etc. Different regulators specify different things. Regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Wednesday, October 08, 2008 6:57 PM > To: 'Ted Hardie'; 'Henning Schulzrinne'; 'Marc Linsner' > Cc: 'ECRIT' > Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call > Termination > > I disagree. > > What we have is a bunch of amateurs on how you handle > emergency calls trying to tell the experts that what they > want is wrong. > > Every one of the kinds of user related issues that have been > raised have occurred enough times that we can listen to the > PSAP guys who say "on balance, its better to have the PSAP > control disconnect". It's not foolproof, and I agree that we > can't brick a phone, and I agree you can always pull the plug > or pull out the battery or whatever. There are, I believe, > jurisdictions to actively don't want this feature, and others > who insist it is a REQUIREMENT to have the feature. There a > lots who are "it would be nice". > > Sure, UI is important here. Some text on multiline might be > appropriate that is all about UI and But the IETF problem is > the signaling: no one is arguing that it is sometimes the > right thing to let the user disconnect. So it's not an > absolute, "don't send BYE" or disable the button on the UI. > There is negotiation of the feature. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Ted Hardie > Sent: Wednesday, October 08, 2008 12:30 PM > To: Henning Schulzrinne; Marc Linsner > Cc: 'ECRIT' > Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call > Termination > > At 7:03 AM -0700 10/8/08, Henning Schulzrinne wrote: > >No requirement stands on its own. Particularly in this case, > proposed > >solutions have had severe side effects that may well > outweigh whatever > >call handling functionality is gained. Thus, we need to look at the > >whole picture, not just one requirement. > > The "whole picture" issue is the key point here, and I agree > with Henning that some of the key issues we need to treat > are whether the mechanism interferes with the user's use of > the phone, whether it creates security vulnerabilities, and > whether it has privacy implications. I also worry, > personally, that the introduction of this requirement implies > either a new requirement for a negotiation phase or that > other responders take up this behavior. Both possibilities > introduce fragility into the system and its deployment. > > As an additional point, I really question whether the right > place to do this is in the network protocol. The majority of > this behavior is actually better achieved in the UI, at least > in my opinion. Having the phone software disable the > terminate button for emergency calls and emit a warning when > it is pressed gets the 80% of the 80/20 with no protocol > behavior at all. I think you'd have to have some UI changes > anyway, simply because this requirement violates the > principle of least surprise. If I think pressing the red > button ends a call and it does for every call but calls to > 911 in Canada, you're going to want some additional UI signal > to let the user known the call didn't end. > > Having the PSAPs say "We have a requirement" is a useful part > of the dialog on this, and goodness knows that the IETF is > not filled with the sum total of expertise in this area. But > we may well have the expertise to say "This belongs in some > other part of the system in a world based on multi-line > phones using VoIP; the circuit switched model for this won't > work well here". In fact, I think we *have* said that, and > we're trying to achieve consensus while talking past each > other. To quote my favorite flying squirrel: > "That trick never works". > > Ted > > > > > >For example, any such > >mechanism must not brick a caller's phone, must not create > the ability > >to eavesdrop on users and must not increase security vulnerabilities. > >It may also help to have a less-mechanism-focused requirement. Since > >the user has placed the receiver on hook (on a traditional phone, at > >least), from a user perspective, this is no different than > being called > >back, unless you indeed make the phone non-operable. > > > >In the end, the user also has a right to be left alone. If > the caller > >no longer wants to talk to the PSAP, forcing him to do that seems > >inappropriate and may well be against the law (or at least > should be, > >in a society that calls itself free). We want to prevent accidental > >disconnects, but the PSAP has no right to take over the > user's phone, > >listen to the user's environment without permission or perform other > >intrusive acts. Unfortunately, the current requirement document does > >not reflect any of these concerns. > > > >Henning > > > >On Oct 8, 2008, at 9:19 AM, Marc Linsner wrote: > > > >> Brian, > >> > >> I have no problem entertaining new requirements. I simply > want the > >> motivation ("We have to do this because") to be spun correctly. > >> > >> I also believe this demands a viewpoint from the 'other' > party, the > >> PSAP customer, Joe Citizen. > >> > >> If in fact a solution can to designed that fulfills the > requirement > >> and protects Joe's desires, I have no problem. > >> > >> -Marc- > >> > > > >_______________________________________________ > >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 > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 8 13:41:47 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC1B3A68D5; Wed, 8 Oct 2008 13:41:47 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAAE63A68CE for ; Wed, 8 Oct 2008 13:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEdggU7LIpKX for ; Wed, 8 Oct 2008 13:41:44 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 7869B3A6890 for ; Wed, 8 Oct 2008 13:41:44 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KnfrN-0007NG-Te; Wed, 08 Oct 2008 15:42:18 -0500 From: "Brian Rosen" To: "'DRAGE, Keith \(Keith\)'" , "'Ted Hardie'" , "'Henning Schulzrinne'" , "'Marc Linsner'" References: <073101c9296f$4ddbd110$e9937330$@net> <5D1A7985295922448D5550C94DE29180023B06DB@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180023B06DB@DEEXC1U01.de.lucent.com> Date: Wed, 8 Oct 2008 16:42:21 -0400 Message-ID: <003f01c92986$5ecbf0b0$1c63d210$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckpYzx7gwWFOvaDT3Ct2aQ0XFND3wACQJ0wAAJg5aAAA4d5gA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I do not accept that the telecommunications industry can override a reasonable requirement like this making an argument that "the operator may need resources for other purposes". This is an individual call, and we're talking about disconnect under control of one of two humans. There aren't many 'resources' that are available for 'other purposes'. PSAPs aren't dictators, nor do they have veto rights, but this is a pretty reasonable requirement I believe. Regulation is an area we have to be cognizant of, and I do think we will have areas where this gets regulated on or off, but that just shows that the feature does need to be negotiated. We have experience here. Lots of experience. The experience says that the value of the feature is much greater than the problems it creates, at least when implemented the way it is/was implemented. Different technology brings different challenges, but the core requirement, and it's value judgment, doesn't change. One of the things I have to keep repeating to PSAPs is that in this change from TDM termination (at the PSAP) to IP termination, lots and lots of technology is changing. Nearly every subsystem they now have will be obsolete. However, the way the call taker handles a call won't fundamentally change. They still answer a call the way any call taker in any call center answers a call, they still "say" the local equivalent of "9-1-1, what is your emergency?". The experience answering millions of calls suggests that the caller is better served when the call taker controls disconnect. It isn't ALWAYS true. It's mostly true. That's the basis of a good requirement. Brian -----Original Message----- From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] Sent: Wednesday, October 08, 2008 2:46 PM To: Brian Rosen; Ted Hardie; Henning Schulzrinne; Marc Linsner Cc: ECRIT Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Speaking as an amateur who has been working in the telecommunication industry for 30 years: There are multiple interests to balance here, and the PSAP provider is only one of these. Emergency calls do not override other telecommunication needs, the user may need to make another call, the telecommunications operator may need the resources for other purposes, etc. Different regulators specify different things. Regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Wednesday, October 08, 2008 6:57 PM > To: 'Ted Hardie'; 'Henning Schulzrinne'; 'Marc Linsner' > Cc: 'ECRIT' > Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call > Termination > > I disagree. > > What we have is a bunch of amateurs on how you handle > emergency calls trying to tell the experts that what they > want is wrong. > > Every one of the kinds of user related issues that have been > raised have occurred enough times that we can listen to the > PSAP guys who say "on balance, its better to have the PSAP > control disconnect". It's not foolproof, and I agree that we > can't brick a phone, and I agree you can always pull the plug > or pull out the battery or whatever. There are, I believe, > jurisdictions to actively don't want this feature, and others > who insist it is a REQUIREMENT to have the feature. There a > lots who are "it would be nice". > > Sure, UI is important here. Some text on multiline might be > appropriate that is all about UI and But the IETF problem is > the signaling: no one is arguing that it is sometimes the > right thing to let the user disconnect. So it's not an > absolute, "don't send BYE" or disable the button on the UI. > There is negotiation of the feature. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Ted Hardie > Sent: Wednesday, October 08, 2008 12:30 PM > To: Henning Schulzrinne; Marc Linsner > Cc: 'ECRIT' > Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call > Termination > > At 7:03 AM -0700 10/8/08, Henning Schulzrinne wrote: > >No requirement stands on its own. Particularly in this case, > proposed > >solutions have had severe side effects that may well > outweigh whatever > >call handling functionality is gained. Thus, we need to look at the > >whole picture, not just one requirement. > > The "whole picture" issue is the key point here, and I agree > with Henning that some of the key issues we need to treat > are whether the mechanism interferes with the user's use of > the phone, whether it creates security vulnerabilities, and > whether it has privacy implications. I also worry, > personally, that the introduction of this requirement implies > either a new requirement for a negotiation phase or that > other responders take up this behavior. Both possibilities > introduce fragility into the system and its deployment. > > As an additional point, I really question whether the right > place to do this is in the network protocol. The majority of > this behavior is actually better achieved in the UI, at least > in my opinion. Having the phone software disable the > terminate button for emergency calls and emit a warning when > it is pressed gets the 80% of the 80/20 with no protocol > behavior at all. I think you'd have to have some UI changes > anyway, simply because this requirement violates the > principle of least surprise. If I think pressing the red > button ends a call and it does for every call but calls to > 911 in Canada, you're going to want some additional UI signal > to let the user known the call didn't end. > > Having the PSAPs say "We have a requirement" is a useful part > of the dialog on this, and goodness knows that the IETF is > not filled with the sum total of expertise in this area. But > we may well have the expertise to say "This belongs in some > other part of the system in a world based on multi-line > phones using VoIP; the circuit switched model for this won't > work well here". In fact, I think we *have* said that, and > we're trying to achieve consensus while talking past each > other. To quote my favorite flying squirrel: > "That trick never works". > > Ted > > > > > >For example, any such > >mechanism must not brick a caller's phone, must not create > the ability > >to eavesdrop on users and must not increase security vulnerabilities. > >It may also help to have a less-mechanism-focused requirement. Since > >the user has placed the receiver on hook (on a traditional phone, at > >least), from a user perspective, this is no different than > being called > >back, unless you indeed make the phone non-operable. > > > >In the end, the user also has a right to be left alone. If > the caller > >no longer wants to talk to the PSAP, forcing him to do that seems > >inappropriate and may well be against the law (or at least > should be, > >in a society that calls itself free). We want to prevent accidental > >disconnects, but the PSAP has no right to take over the > user's phone, > >listen to the user's environment without permission or perform other > >intrusive acts. Unfortunately, the current requirement document does > >not reflect any of these concerns. > > > >Henning > > > >On Oct 8, 2008, at 9:19 AM, Marc Linsner wrote: > > > >> Brian, > >> > >> I have no problem entertaining new requirements. I simply > want the > >> motivation ("We have to do this because") to be spun correctly. > >> > >> I also believe this demands a viewpoint from the 'other' > party, the > >> PSAP customer, Joe Citizen. > >> > >> If in fact a solution can to designed that fulfills the > requirement > >> and protects Joe's desires, I have no problem. > >> > >> -Marc- > >> > > > >_______________________________________________ > >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 > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 8 14:40:09 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 874553A68A1; Wed, 8 Oct 2008 14:40:09 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D98E3A68A1 for ; Wed, 8 Oct 2008 14:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.553 X-Spam-Level: X-Spam-Status: No, score=-103.553 tagged_above=-999 required=5 tests=[AWL=-0.954, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIbtYY5AnfO9 for ; Wed, 8 Oct 2008 14:40:07 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 4341B3A689E for ; Wed, 8 Oct 2008 14:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1223502049; x=1255038049; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<003f01c92986$5ecbf0b0$1 c63d210$@net>|References:=20=0D=0A=20=20<073101c9296f$4ddbd110$e9937330$@net>=0D=0A=20<5D1A7 985295922448D5550C94DE29180023B06DB@DEEXC1U01.de.lucent.c om>=0D=0A=20<003f01c92986$5ecbf0b0$1c63d210$@net>|Date: =20Wed,=208=20Oct=202008=2014:40:37=20-0700|To:=20Brian =20Rosen=20,=0D=0A=20=20=20=20=20=20 =20=20"'DRAGE,=20Keith=20(Keith)'"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"'Henning=20Sc hulzrinne'"=20,=0D=0A=20=20=20=20=20 =20=20=20"'Marc=20Linsner'"=20|From: =20Ted=20Hardie=20|Subject:=20RE:=20 [Ecrit]=20IETF=20ECRIT=20Design=20Team=20on=20Premature =20Call=20=20=20Termination|CC:=20"'ECRIT'"=20|Content-Type:=20text/plain=3B=20charset=3D"us-ascii "|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5401"=3B =20a=3D"10294224"; bh=YhiWjWxJewVsydgPaUObiy8hDq54loFEsYdnZW3HqQ8=; b=A+ZZROE3Pnd2KbAg1uluuA8WfsMvANTUWqpOZLr3A9o1SxH8O2558wcl ioSL01Tz3NSKG0dywb2qv7E1UJtLyi4VapxzX5iUZZVFnc5ciOnd37Qi3 De00q3b8o3gJSYNk9Q8yggvn2D0O8L29E2Sy31V0IcTNAofUWUkoYKXQI w=; X-IronPort-AV: E=McAfee;i="5300,2777,5401"; a="10294224" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Oct 2008 14:40:41 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m98LeetN027103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Oct 2008 14:40:41 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m98LeedN012122 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Oct 2008 14:40:40 -0700 (PDT) Received: from [10.227.68.106] (10.227.68.106) by qcmail1.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 8 Oct 2008 14:40:39 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <003f01c92986$5ecbf0b0$1c63d210$@net> References: <073101c9296f$4ddbd110$e9937330$@net> <5D1A7985295922448D5550C94DE29180023B06DB@DEEXC1U01.de.lucent.com> <003f01c92986$5ecbf0b0$1c63d210$@net> Date: Wed, 8 Oct 2008 14:40:37 -0700 To: Brian Rosen , "'DRAGE, Keith (Keith)'" , "'Henning Schulzrinne'" , "'Marc Linsner'" From: Ted Hardie Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 1:42 PM -0700 10/8/08, Brian Rosen wrote: >I do not accept that the telecommunications industry can override a >reasonable requirement like this making an argument that "the operator may >need resources for other purposes". This is an individual call, and we're >talking about disconnect under control of one of two humans. There aren't >many 'resources' that are available for 'other purposes'. PSAPs aren't >dictators, nor do they have veto rights, but this is a pretty reasonable >requirement I believe. I continue to believe we're talking past each other here, and my experience has been that folks talking past each other tend to get louder and listen less. I'm trying to avoid that by trying to go back to the basics here, and I hope you'll take that in the spirit meant--trying to avoid this turning into a situation where anyone stops listening. At the base line, I think one of the issues is your use of the term "requirement". A group of PSAP operators would like the system that replaces the current system to have specific characteristics. One of the desired characteristics is that only a PSAP call-taker can terminate a call which has reached the PSAP. If Marc is correct, the Canadian jurisdiction PSAPs live without this characteristic for about two-thirds of their calls. The system clearly works when this characteristic is not present. It may be a very strong desire, but there is no overall system failure when it is not present. U.S. PSAPs had this characteristic and it was dropped, over their objections. The 911 system continues to work here, even without this. Call-backs and other methods are used instead. The PSAP operators feel that this is not as good, and they are the experts on what works for them here; no one is denying this. But some of us have serious concerns about adding protocol mechanisms to the ECRIT system to support this characteristic, especially if they necessitate the introduction of a negotiation phase that is not currently present. The risks here are quite real, and they are obvious enough that even amateurs can see them. If a negotiation phase adds significant latency, rates of call abandonment *will* go up. To take a ridiculous number, if it takes 20 seconds to do this negotiation, supporting this is out of the question. Way too many people will give up completely or be in seriously worse straits to make that sensible. That number is clearly not probable, but it indicates the need to balance. That same need for balance is needed in other arenas: the need to maintain the privacy of the user may be mandated or desired in some jurisdictions; the need to maintain the security of the communication channel; the need for the caller to make other calls; and, yes, the need to free resources so that *other* callers can make their own calls (which in disaster situations may also be to emergency services). I know I would feel more like I'm being heard if you acknowledged that there are other needs to balance here, and I hope you hear that I understand that PSAP operators have experience with this system that I do not. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 8 15:12:52 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86E1B28C18D; Wed, 8 Oct 2008 15:12:52 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E320628C17D for ; Wed, 8 Oct 2008 15:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ct46mArKRON for ; Wed, 8 Oct 2008 15:12:50 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id E1D1128C179 for ; Wed, 8 Oct 2008 15:12:49 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KnhHW-0003en-QO; Wed, 08 Oct 2008 17:13:23 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'DRAGE, Keith \(Keith\)'" , "'Henning Schulzrinne'" , "'Marc Linsner'" References: <073101c9296f$4ddbd110$e9937330$@net> <5D1A7985295922448D5550C94DE29180023B06DB@DEEXC1U01.de.lucent.com> <003f01c92986$5ecbf0b0$1c63d210$@net> In-Reply-To: Date: Wed, 8 Oct 2008 18:13:25 -0400 Message-ID: <005601c92993$17feb6b0$47fc2410$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ackpjn5t94UDpSNVRr+DCVTYUeiODgAAXtAg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Ted Lots of systems get used even when they don't meet the user's requirements. That's what happened. I don't mean to imply that the whole thing won't work without this feature. On the other hand, as you know, sometimes implementers ignore requirements for financial or other reasons. I don't think that applies here in ecrit, but it may. I just don't see how you take a situation where carriers flat out refused to meet the requirement as justification for not considering the requirement, or negating its importance. The 9-1-1 system "worked" without any location. When wireless first started, it didn't provide ANY location at all. Are you suggesting that the location reporting requirement be dropped because millions of 9-1-1 calls were completed without it? Then, I think you drop immediately into mechanism issues. You, for example, get worried about some new negotiation phase. No one has suggested that. The proposals that are at the front of the table use the existing Supported/Required option negotiation mechanism. The UA indicates that it can support the option in Supported. The PSAP indicates that it can implement the option, and desires to employ it on the specific call, by including it in Required. If the UA sees it in Required, and it sent it in Supported, it enables the function. If it doesn't understand it, or doesn't see it in Required, it's not enabled. In some folk's preferred implementation, you use the existing Hold signaling (SDP sendrecv=inactive) to indicate "hook state", and rather than sending BYE from the UA. The PSAP terminates the call. The UA can terminate if it doesn't complete the ReINVITE that signals a hook state change. I think that avoids the "brick" problem. There is NO added latency. It doesn't use any resources that weren't already allocated for the call. You do something similar with CANCEL. Brian (who is still listening) -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: Wednesday, October 08, 2008 5:41 PM To: Brian Rosen; 'DRAGE, Keith (Keith)'; 'Henning Schulzrinne'; 'Marc Linsner' Cc: 'ECRIT' Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination At 1:42 PM -0700 10/8/08, Brian Rosen wrote: >I do not accept that the telecommunications industry can override a >reasonable requirement like this making an argument that "the operator may >need resources for other purposes". This is an individual call, and we're >talking about disconnect under control of one of two humans. There aren't >many 'resources' that are available for 'other purposes'. PSAPs aren't >dictators, nor do they have veto rights, but this is a pretty reasonable >requirement I believe. I continue to believe we're talking past each other here, and my experience has been that folks talking past each other tend to get louder and listen less. I'm trying to avoid that by trying to go back to the basics here, and I hope you'll take that in the spirit meant--trying to avoid this turning into a situation where anyone stops listening. At the base line, I think one of the issues is your use of the term "requirement". A group of PSAP operators would like the system that replaces the current system to have specific characteristics. One of the desired characteristics is that only a PSAP call-taker can terminate a call which has reached the PSAP. If Marc is correct, the Canadian jurisdiction PSAPs live without this characteristic for about two-thirds of their calls. The system clearly works when this characteristic is not present. It may be a very strong desire, but there is no overall system failure when it is not present. U.S. PSAPs had this characteristic and it was dropped, over their objections. The 911 system continues to work here, even without this. Call-backs and other methods are used instead. The PSAP operators feel that this is not as good, and they are the experts on what works for them here; no one is denying this. But some of us have serious concerns about adding protocol mechanisms to the ECRIT system to support this characteristic, especially if they necessitate the introduction of a negotiation phase that is not currently present. The risks here are quite real, and they are obvious enough that even amateurs can see them. If a negotiation phase adds significant latency, rates of call abandonment *will* go up. To take a ridiculous number, if it takes 20 seconds to do this negotiation, supporting this is out of the question. Way too many people will give up completely or be in seriously worse straits to make that sensible. That number is clearly not probable, but it indicates the need to balance. That same need for balance is needed in other arenas: the need to maintain the privacy of the user may be mandated or desired in some jurisdictions; the need to maintain the security of the communication channel; the need for the caller to make other calls; and, yes, the need to free resources so that *other* callers can make their own calls (which in disaster situations may also be to emergency services). I know I would feel more like I'm being heard if you acknowledged that there are other needs to balance here, and I hope you hear that I understand that PSAP operators have experience with this system that I do not. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 8 16:09:17 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8933A6BCF; Wed, 8 Oct 2008 16:09:17 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253393A6BCF for ; Wed, 8 Oct 2008 16:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVFL6xfCVW6d for ; Wed, 8 Oct 2008 16:09:14 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 997AF3A691D for ; Wed, 8 Oct 2008 16:09:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,381,1220227200"; d="scan'208";a="23689408" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Oct 2008 23:09:56 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m98N9uQU006086; Wed, 8 Oct 2008 19:09:56 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m98N9uue015750; Wed, 8 Oct 2008 23:09:56 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 19:09:56 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 19:09:55 -0400 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 08 Oct 2008 19:09:54 -0400 From: Marc Linsner To: Brian Rosen Message-ID: Thread-Topic: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Thread-Index: Ackpjn5t94UDpSNVRr+DCVTYUeiODgAAXtAgAAK/5N4= In-Reply-To: <005601c92993$17feb6b0$47fc2410$@net> Mime-version: 1.0 X-OriginalArrivalTime: 08 Oct 2008 23:09:55.0699 (UTC) FILETIME=[FA404C30:01C9299A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5776; t=1223507396; x=1224371396; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20IETF=20ECRIT=20Design=20Team= 20on=20Premature=20Call=20=20=20Termination |Sender:=20 |To:=20Brian=20Rosen=20; bh=7re7bweHGGRbVP6UZlf1g81ZwL7wEhsPX0k2L1YbhAo=; b=qVLQw8rc3vAJWGmsETpjX7LmyWYCRh4KrB4DY4FBP34RaFrHc5sPT0mMF3 GHgyXWprsSdAG1N/LaJN5jWIL9tCEK6z3XXhsp6CMK72tYStECh8oaD2Qwru FHHrmhM4Ct; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, What document contains your proposed mechanisms? -Marc- On 10/8/08 6:13 PM, "Brian Rosen" wrote: > Ted > > Lots of systems get used even when they don't meet the user's requirements. > That's what happened. I don't mean to imply that the whole thing won't work > without this feature. On the other hand, as you know, sometimes > implementers ignore requirements for financial or other reasons. I don't > think that applies here in ecrit, but it may. I just don't see how you take > a situation where carriers flat out refused to meet the requirement as > justification for not considering the requirement, or negating its > importance. The 9-1-1 system "worked" without any location. When wireless > first started, it didn't provide ANY location at all. Are you suggesting > that the location reporting requirement be dropped because millions of 9-1-1 > calls were completed without it? > > Then, I think you drop immediately into mechanism issues. You, for example, > get worried about some new negotiation phase. No one has suggested that. > The proposals that are at the front of the table use the existing > Supported/Required option negotiation mechanism. The UA indicates that it > can support the option in Supported. The PSAP indicates that it can > implement the option, and desires to employ it on the specific call, by > including it in Required. If the UA sees it in Required, and it sent it in > Supported, it enables the function. If it doesn't understand it, or doesn't > see it in Required, it's not enabled. In some folk's preferred > implementation, you use the existing Hold signaling (SDP sendrecv=inactive) > to indicate "hook state", and rather than sending BYE from the UA. The PSAP > terminates the call. The UA can terminate if it doesn't complete the > ReINVITE that signals a hook state change. I think that avoids the "brick" > problem. There is NO added latency. It doesn't use any resources that > weren't already allocated for the call. You do something similar with > CANCEL. > > Brian (who is still listening) > > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Wednesday, October 08, 2008 5:41 PM > To: Brian Rosen; 'DRAGE, Keith (Keith)'; 'Henning Schulzrinne'; 'Marc > Linsner' > Cc: 'ECRIT' > Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > > At 1:42 PM -0700 10/8/08, Brian Rosen wrote: >> I do not accept that the telecommunications industry can override a >> reasonable requirement like this making an argument that "the operator may >> need resources for other purposes". This is an individual call, and we're >> talking about disconnect under control of one of two humans. There aren't >> many 'resources' that are available for 'other purposes'. PSAPs aren't >> dictators, nor do they have veto rights, but this is a pretty reasonable >> requirement I believe. > > I continue to believe we're talking past each other here, and my experience > has been that folks talking past each other tend to get louder and listen > less. I'm trying to avoid that by trying to go back to the basics here, > and I hope you'll take that in the spirit meant--trying to avoid this > turning > into a situation where anyone stops listening. > > At the base line, I think one of the issues is your use of the term > "requirement". A group of PSAP operators would like the system > that replaces the current system to have specific characteristics. One > of the desired characteristics is that only a PSAP call-taker can terminate > a call which has reached the PSAP. > > If Marc is correct, the Canadian jurisdiction PSAPs live without this > characteristic > for about two-thirds of their calls. The system clearly works when this > characteristic is not present. It may be a very strong desire, but there is > no overall system failure when it is not present. U.S. PSAPs had this > characteristic and it was dropped, over their objections. The 911 system > continues to work here, even without this. Call-backs and other methods > are used instead. The PSAP operators feel that this is not as good, and > they > are the experts on what works for them here; no one is denying this. > > But some of us have serious concerns about adding protocol mechanisms > to the ECRIT system to support this characteristic, especially if they > necessitate > the introduction of a negotiation phase that is not currently present. The > risks here are quite real, and they are obvious enough that even amateurs > can > see them. If a negotiation phase adds significant latency, rates of > call abandonment *will* go up. To take a ridiculous number, if it > takes 20 seconds to do this negotiation, supporting this is out of the > question. Way too many people will give up completely or be in > seriously worse straits to make that sensible. That number is clearly > not probable, but it indicates the need to balance. That same need > for balance is needed in other arenas: the need to maintain the > privacy of the user may be mandated or desired in some jurisdictions; > the need to maintain the security of the communication channel; the > need for the caller to make other calls; and, yes, the need to free > resources so that *other* callers can make their own calls > (which in disaster situations may also be to emergency services). > > I know I would feel more like I'm being heard if you acknowledged > that there are other needs to balance here, and I hope you hear that > I understand that PSAP operators have experience with this system > that I do not. > regards, > Ted Hardie > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 8 16:34:55 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FAA73A6BF2; Wed, 8 Oct 2008 16:34:55 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 802B63A6BEE for ; Wed, 8 Oct 2008 16:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YTTuWkY7-ZR for ; Wed, 8 Oct 2008 16:34:53 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 7F44E3A6BDF for ; Wed, 8 Oct 2008 16:34:53 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KniYw-0006kc-Fg; Wed, 08 Oct 2008 18:35:26 -0500 From: "Brian Rosen" To: "'Marc Linsner'" References: <005601c92993$17feb6b0$47fc2410$@net> In-Reply-To: Date: Wed, 8 Oct 2008 19:35:37 -0400 Message-ID: <006e01c9299e$93246fa0$b96d4ee0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ackpjn5t94UDpSNVRr+DCVTYUeiODgAAXtAgAAK/5N4AANvtIA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Right now, it's in a NENA doc, because we thought we were supposed to finish the requirements before starting on the mechanisms. We'll bring it into ecrit as soon as its needed. Brian -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Wednesday, October 08, 2008 7:10 PM To: Brian Rosen Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Brian, What document contains your proposed mechanisms? -Marc- On 10/8/08 6:13 PM, "Brian Rosen" wrote: > Ted > > Lots of systems get used even when they don't meet the user's requirements. > That's what happened. I don't mean to imply that the whole thing won't work > without this feature. On the other hand, as you know, sometimes > implementers ignore requirements for financial or other reasons. I don't > think that applies here in ecrit, but it may. I just don't see how you take > a situation where carriers flat out refused to meet the requirement as > justification for not considering the requirement, or negating its > importance. The 9-1-1 system "worked" without any location. When wireless > first started, it didn't provide ANY location at all. Are you suggesting > that the location reporting requirement be dropped because millions of 9-1-1 > calls were completed without it? > > Then, I think you drop immediately into mechanism issues. You, for example, > get worried about some new negotiation phase. No one has suggested that. > The proposals that are at the front of the table use the existing > Supported/Required option negotiation mechanism. The UA indicates that it > can support the option in Supported. The PSAP indicates that it can > implement the option, and desires to employ it on the specific call, by > including it in Required. If the UA sees it in Required, and it sent it in > Supported, it enables the function. If it doesn't understand it, or doesn't > see it in Required, it's not enabled. In some folk's preferred > implementation, you use the existing Hold signaling (SDP sendrecv=inactive) > to indicate "hook state", and rather than sending BYE from the UA. The PSAP > terminates the call. The UA can terminate if it doesn't complete the > ReINVITE that signals a hook state change. I think that avoids the "brick" > problem. There is NO added latency. It doesn't use any resources that > weren't already allocated for the call. You do something similar with > CANCEL. > > Brian (who is still listening) > > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Wednesday, October 08, 2008 5:41 PM > To: Brian Rosen; 'DRAGE, Keith (Keith)'; 'Henning Schulzrinne'; 'Marc > Linsner' > Cc: 'ECRIT' > Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > > At 1:42 PM -0700 10/8/08, Brian Rosen wrote: >> I do not accept that the telecommunications industry can override a >> reasonable requirement like this making an argument that "the operator may >> need resources for other purposes". This is an individual call, and we're >> talking about disconnect under control of one of two humans. There aren't >> many 'resources' that are available for 'other purposes'. PSAPs aren't >> dictators, nor do they have veto rights, but this is a pretty reasonable >> requirement I believe. > > I continue to believe we're talking past each other here, and my experience > has been that folks talking past each other tend to get louder and listen > less. I'm trying to avoid that by trying to go back to the basics here, > and I hope you'll take that in the spirit meant--trying to avoid this > turning > into a situation where anyone stops listening. > > At the base line, I think one of the issues is your use of the term > "requirement". A group of PSAP operators would like the system > that replaces the current system to have specific characteristics. One > of the desired characteristics is that only a PSAP call-taker can terminate > a call which has reached the PSAP. > > If Marc is correct, the Canadian jurisdiction PSAPs live without this > characteristic > for about two-thirds of their calls. The system clearly works when this > characteristic is not present. It may be a very strong desire, but there is > no overall system failure when it is not present. U.S. PSAPs had this > characteristic and it was dropped, over their objections. The 911 system > continues to work here, even without this. Call-backs and other methods > are used instead. The PSAP operators feel that this is not as good, and > they > are the experts on what works for them here; no one is denying this. > > But some of us have serious concerns about adding protocol mechanisms > to the ECRIT system to support this characteristic, especially if they > necessitate > the introduction of a negotiation phase that is not currently present. The > risks here are quite real, and they are obvious enough that even amateurs > can > see them. If a negotiation phase adds significant latency, rates of > call abandonment *will* go up. To take a ridiculous number, if it > takes 20 seconds to do this negotiation, supporting this is out of the > question. Way too many people will give up completely or be in > seriously worse straits to make that sensible. That number is clearly > not probable, but it indicates the need to balance. That same need > for balance is needed in other arenas: the need to maintain the > privacy of the user may be mandated or desired in some jurisdictions; > the need to maintain the security of the communication channel; the > need for the caller to make other calls; and, yes, the need to free > resources so that *other* callers can make their own calls > (which in disaster situations may also be to emergency services). > > I know I would feel more like I'm being heard if you acknowledged > that there are other needs to balance here, and I hope you hear that > I understand that PSAP operators have experience with this system > that I do not. > regards, > Ted Hardie > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 8 16:46:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA1728C144; Wed, 8 Oct 2008 16:46:25 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B539A3A6BF6 for ; Wed, 8 Oct 2008 16:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kPS7o+VIEF2 for ; Wed, 8 Oct 2008 16:46:23 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 5DFAD28C144 for ; Wed, 8 Oct 2008 16:46:23 -0700 (PDT) Received: from [192.168.0.61] (pool-71-250-72-76.nwrknj.east.verizon.net [71.250.72.76]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m98Nkvgl000836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Oct 2008 19:46:59 -0400 (EDT) Message-Id: <5B027CEB-D700-446F-A768-601A9E659654@cs.columbia.edu> From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <005601c92993$17feb6b0$47fc2410$@net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 8 Oct 2008 19:46:55 -0400 References: <073101c9296f$4ddbd110$e9937330$@net> <5D1A7985295922448D5550C94DE29180023B06DB@DEEXC1U01.de.lucent.com> <003f01c92986$5ecbf0b0$1c63d210$@net> <005601c92993$17feb6b0$47fc2410$@net> X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: ECRIT Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, as I've tried to explain to you, this mechanism doesn't work and redefines existing SIP behavior by using the Require mechanism, which is a no-no. It's essentially a kludge. ECRIT shouldn't be redefining SIP, but having NENA do it seems even less appropriate. These end-runs don't exactly induce confidence. NENA has to trust IETF "representatives" to know their SIP stuff, but that relies on those representatives not riding off on their own. I'm sorry, but this smells, badly. Henning On Oct 8, 2008, at 6:13 PM, Brian Rosen wrote: > Ted > > Lots of systems get used even when they don't meet the user's > requirements. > That's what happened. I don't mean to imply that the whole thing > won't work > without this feature. On the other hand, as you know, sometimes > implementers ignore requirements for financial or other reasons. I > don't > think that applies here in ecrit, but it may. I just don't see how > you take > a situation where carriers flat out refused to meet the requirement as > justification for not considering the requirement, or negating its > importance. The 9-1-1 system "worked" without any location. When > wireless > first started, it didn't provide ANY location at all. Are you > suggesting > that the location reporting requirement be dropped because millions > of 9-1-1 > calls were completed without it? > > Then, I think you drop immediately into mechanism issues. You, for > example, > get worried about some new negotiation phase. No one has suggested > that. > The proposals that are at the front of the table use the existing > Supported/Required option negotiation mechanism. The UA indicates > that it > can support the option in Supported. The PSAP indicates that it can > implement the option, and desires to employ it on the specific call, > by > including it in Required. If the UA sees it in Required, and it > sent it in > Supported, it enables the function. If it doesn't understand it, or > doesn't > see it in Required, it's not enabled. In some folk's preferred > implementation, you use the existing Hold signaling (SDP > sendrecv=inactive) > to indicate "hook state", and rather than sending BYE from the UA. > The PSAP > terminates the call. The UA can terminate if it doesn't complete the > ReINVITE that signals a hook state change. I think that avoids the > "brick" > problem. There is NO added latency. It doesn't use any resources > that > weren't already allocated for the call. You do something similar with > CANCEL. > > Brian (who is still listening) > > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Wednesday, October 08, 2008 5:41 PM > To: Brian Rosen; 'DRAGE, Keith (Keith)'; 'Henning Schulzrinne'; 'Marc > Linsner' > Cc: 'ECRIT' > Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call > Termination > > At 1:42 PM -0700 10/8/08, Brian Rosen wrote: >> I do not accept that the telecommunications industry can override a >> reasonable requirement like this making an argument that "the >> operator may >> need resources for other purposes". This is an individual call, >> and we're >> talking about disconnect under control of one of two humans. There >> aren't >> many 'resources' that are available for 'other purposes'. PSAPs >> aren't >> dictators, nor do they have veto rights, but this is a pretty >> reasonable >> requirement I believe. > > I continue to believe we're talking past each other here, and my > experience > has been that folks talking past each other tend to get louder and > listen > less. I'm trying to avoid that by trying to go back to the basics > here, > and I hope you'll take that in the spirit meant--trying to avoid this > turning > into a situation where anyone stops listening. > > At the base line, I think one of the issues is your use of the term > "requirement". A group of PSAP operators would like the system > that replaces the current system to have specific characteristics. > One > of the desired characteristics is that only a PSAP call-taker can > terminate > a call which has reached the PSAP. > > If Marc is correct, the Canadian jurisdiction PSAPs live without this > characteristic > for about two-thirds of their calls. The system clearly works when > this > characteristic is not present. It may be a very strong desire, but > there is > no overall system failure when it is not present. U.S. PSAPs had this > characteristic and it was dropped, over their objections. The 911 > system > continues to work here, even without this. Call-backs and other > methods > are used instead. The PSAP operators feel that this is not as > good, and > they > are the experts on what works for them here; no one is denying this. > > But some of us have serious concerns about adding protocol mechanisms > to the ECRIT system to support this characteristic, especially if they > necessitate > the introduction of a negotiation phase that is not currently > present. The > risks here are quite real, and they are obvious enough that even > amateurs > can > see them. If a negotiation phase adds significant latency, rates of > call abandonment *will* go up. To take a ridiculous number, if it > takes 20 seconds to do this negotiation, supporting this is out of the > question. Way too many people will give up completely or be in > seriously worse straits to make that sensible. That number is clearly > not probable, but it indicates the need to balance. That same need > for balance is needed in other arenas: the need to maintain the > privacy of the user may be mandated or desired in some jurisdictions; > the need to maintain the security of the communication channel; the > need for the caller to make other calls; and, yes, the need to free > resources so that *other* callers can make their own calls > (which in disaster situations may also be to emergency services). > > I know I would feel more like I'm being heard if you acknowledged > that there are other needs to balance here, and I hope you hear that > I understand that PSAP operators have experience with this system > that I do not. > regards, > Ted Hardie > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 9 05:12:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0BEA3A68FF; Thu, 9 Oct 2008 05:12:32 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC8D3A69F5 for ; Thu, 9 Oct 2008 05:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.415 X-Spam-Level: X-Spam-Status: No, score=-6.415 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWp8VKtFdXlG for ; Thu, 9 Oct 2008 05:12:30 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E082E3A68F9 for ; Thu, 9 Oct 2008 05:12:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,382,1220227200"; d="scan'208";a="23697352" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Oct 2008 12:12:59 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m99CCxtM032495; Thu, 9 Oct 2008 08:12:59 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m99CCxn8008675; Thu, 9 Oct 2008 12:12:59 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 08:12:19 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 08:12:18 -0400 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 09 Oct 2008 08:12:15 -0400 From: Marc Linsner To: Brian Rosen Message-ID: Thread-Topic: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Thread-Index: Ackpjn5t94UDpSNVRr+DCVTYUeiODgAAXtAgAAK/5N4AANvtIAAadtQH In-Reply-To: <006e01c9299e$93246fa0$b96d4ee0$@net> Mime-version: 1.0 X-OriginalArrivalTime: 09 Oct 2008 12:12:18.0654 (UTC) FILETIME=[466EC7E0:01C92A08] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6541; t=1223554379; x=1224418379; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20IETF=20ECRIT=20Design=20Team= 20on=20Premature=20Call=20=20=20Termination |Sender:=20 |To:=20Brian=20Rosen=20; bh=+B8E3goF7fr3leSTQT4Wd1rCeRDg9LqnHQImxk7OEpM=; b=RCl8DH9FrI/epbrZ/bh0GhSBoRVslp2StZYkZlLxZ8YUuG0sPh5mKXan+E Ub9Ppn2by8OgKpuNNlLvMHEsFd4ShsZWAId/nrEqRrJsc/cAM1YimpH4MU2l qv5TBDN4sJ; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, What was your comment about amateurs? :^) -Marc- On 10/8/08 7:35 PM, "Brian Rosen" wrote: > Right now, it's in a NENA doc, because we thought we were supposed to finish > the requirements before starting on the mechanisms. > > We'll bring it into ecrit as soon as its needed. > > Brian > > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Wednesday, October 08, 2008 7:10 PM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > > Brian, > > What document contains your proposed mechanisms? > > -Marc- > > > On 10/8/08 6:13 PM, "Brian Rosen" wrote: > >> Ted >> >> Lots of systems get used even when they don't meet the user's > requirements. >> That's what happened. I don't mean to imply that the whole thing won't > work >> without this feature. On the other hand, as you know, sometimes >> implementers ignore requirements for financial or other reasons. I don't >> think that applies here in ecrit, but it may. I just don't see how you > take >> a situation where carriers flat out refused to meet the requirement as >> justification for not considering the requirement, or negating its >> importance. The 9-1-1 system "worked" without any location. When > wireless >> first started, it didn't provide ANY location at all. Are you suggesting >> that the location reporting requirement be dropped because millions of > 9-1-1 >> calls were completed without it? >> >> Then, I think you drop immediately into mechanism issues. You, for > example, >> get worried about some new negotiation phase. No one has suggested that. >> The proposals that are at the front of the table use the existing >> Supported/Required option negotiation mechanism. The UA indicates that it >> can support the option in Supported. The PSAP indicates that it can >> implement the option, and desires to employ it on the specific call, by >> including it in Required. If the UA sees it in Required, and it sent it > in >> Supported, it enables the function. If it doesn't understand it, or > doesn't >> see it in Required, it's not enabled. In some folk's preferred >> implementation, you use the existing Hold signaling (SDP > sendrecv=inactive) >> to indicate "hook state", and rather than sending BYE from the UA. The > PSAP >> terminates the call. The UA can terminate if it doesn't complete the >> ReINVITE that signals a hook state change. I think that avoids the > "brick" >> problem. There is NO added latency. It doesn't use any resources that >> weren't already allocated for the call. You do something similar with >> CANCEL. >> >> Brian (who is still listening) >> >> -----Original Message----- >> From: Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: Wednesday, October 08, 2008 5:41 PM >> To: Brian Rosen; 'DRAGE, Keith (Keith)'; 'Henning Schulzrinne'; 'Marc >> Linsner' >> Cc: 'ECRIT' >> Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination >> >> At 1:42 PM -0700 10/8/08, Brian Rosen wrote: >>> I do not accept that the telecommunications industry can override a >>> reasonable requirement like this making an argument that "the operator > may >>> need resources for other purposes". This is an individual call, and > we're >>> talking about disconnect under control of one of two humans. There > aren't >>> many 'resources' that are available for 'other purposes'. PSAPs aren't >>> dictators, nor do they have veto rights, but this is a pretty reasonable >>> requirement I believe. >> >> I continue to believe we're talking past each other here, and my > experience >> has been that folks talking past each other tend to get louder and listen >> less. I'm trying to avoid that by trying to go back to the basics here, >> and I hope you'll take that in the spirit meant--trying to avoid this >> turning >> into a situation where anyone stops listening. >> >> At the base line, I think one of the issues is your use of the term >> "requirement". A group of PSAP operators would like the system >> that replaces the current system to have specific characteristics. One >> of the desired characteristics is that only a PSAP call-taker can > terminate >> a call which has reached the PSAP. >> >> If Marc is correct, the Canadian jurisdiction PSAPs live without this >> characteristic >> for about two-thirds of their calls. The system clearly works when this >> characteristic is not present. It may be a very strong desire, but there > is >> no overall system failure when it is not present. U.S. PSAPs had this >> characteristic and it was dropped, over their objections. The 911 system >> continues to work here, even without this. Call-backs and other methods >> are used instead. The PSAP operators feel that this is not as good, and >> they >> are the experts on what works for them here; no one is denying this. >> >> But some of us have serious concerns about adding protocol mechanisms >> to the ECRIT system to support this characteristic, especially if they >> necessitate >> the introduction of a negotiation phase that is not currently present. > The >> risks here are quite real, and they are obvious enough that even amateurs >> can >> see them. If a negotiation phase adds significant latency, rates of >> call abandonment *will* go up. To take a ridiculous number, if it >> takes 20 seconds to do this negotiation, supporting this is out of the >> question. Way too many people will give up completely or be in >> seriously worse straits to make that sensible. That number is clearly >> not probable, but it indicates the need to balance. That same need >> for balance is needed in other arenas: the need to maintain the >> privacy of the user may be mandated or desired in some jurisdictions; >> the need to maintain the security of the communication channel; the >> need for the caller to make other calls; and, yes, the need to free >> resources so that *other* callers can make their own calls >> (which in disaster situations may also be to emergency services). >> >> I know I would feel more like I'm being heard if you acknowledged >> that there are other needs to balance here, and I hope you hear that >> I understand that PSAP operators have experience with this system >> that I do not. >> regards, >> Ted Hardie >> >> >> >> >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 9 06:13:24 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0EE3A6A78; Thu, 9 Oct 2008 06:13:24 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD5A23A68F9 for ; Thu, 9 Oct 2008 06:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.039 X-Spam-Level: X-Spam-Status: No, score=-5.039 tagged_above=-999 required=5 tests=[AWL=1.245, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOE0Gs8bOEmS for ; Thu, 9 Oct 2008 06:13:22 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 301C83A68C0 for ; Thu, 9 Oct 2008 06:13:21 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m99DDlKe026458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Oct 2008 15:13:47 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m99DDipp008383; Thu, 9 Oct 2008 15:13:46 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Oct 2008 15:13:45 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Oct 2008 15:13:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Oct 2008 16:13:39 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] IETF ECRIT Design Team on Premature Call Termination Thread-Index: Ackpjn5t94UDpSNVRr+DCVTYUeiODgAAXtAgAAK/5N4AANvtIAAadtQHAAGed9A= References: <006e01c9299e$93246fa0$b96d4ee0$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Marc Linsner" , "Brian Rosen" X-OriginalArrivalTime: 09 Oct 2008 13:13:44.0912 (UTC) FILETIME=[DB9D1D00:01C92A10] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081009151347-40300BB0-00FA8813/0-0/0-15 X-purgate-size: 8037/0 Cc: ECRIT Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Folks, we need to get things going. Here is my suggestion: 1) Read through Brian's draft again http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnect-rqmts-00 .txt 2) Take a look at the previously received comments - during the IETF meeting - after the meeting on the list Here are some links: http://www.ietf.org/mail-archive/web/ecrit/current/msg05450.html http://www.ietf.org/mail-archive/web/ecrit/current/msg05447.html 3) Determine whether we can agree on some of the requirements. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Marc Linsner >Sent: 09 October, 2008 15:12 >To: Brian Rosen >Cc: 'ECRIT' >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call >Termination > >Brian, > >What was your comment about amateurs? > >:^) > >-Marc- > > >On 10/8/08 7:35 PM, "Brian Rosen" wrote: > >> Right now, it's in a NENA doc, because we thought we were >supposed to >> finish the requirements before starting on the mechanisms. >> >> We'll bring it into ecrit as soon as its needed. >> >> Brian >> >> -----Original Message----- >> From: Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: Wednesday, October 08, 2008 7:10 PM >> To: Brian Rosen >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call >> Termination >> >> Brian, >> >> What document contains your proposed mechanisms? >> >> -Marc- >> >> >> On 10/8/08 6:13 PM, "Brian Rosen" wrote: >> >>> Ted >>> >>> Lots of systems get used even when they don't meet the user's >> requirements. >>> That's what happened. I don't mean to imply that the whole thing >>> won't >> work >>> without this feature. On the other hand, as you know, sometimes >>> implementers ignore requirements for financial or other reasons. I >>> don't think that applies here in ecrit, but it may. I just >don't see >>> how you >> take >>> a situation where carriers flat out refused to meet the requirement >>> as justification for not considering the requirement, or >negating its >>> importance. The 9-1-1 system "worked" without any location. When >> wireless >>> first started, it didn't provide ANY location at all. Are you >>> suggesting that the location reporting requirement be >dropped because >>> millions of >> 9-1-1 >>> calls were completed without it? >>> >>> Then, I think you drop immediately into mechanism issues. You, for >> example, >>> get worried about some new negotiation phase. No one has >suggested that. >>> The proposals that are at the front of the table use the existing >>> Supported/Required option negotiation mechanism. The UA indicates >>> that it can support the option in Supported. The PSAP >indicates that >>> it can implement the option, and desires to employ it on >the specific >>> call, by including it in Required. If the UA sees it in Required, >>> and it sent it >> in >>> Supported, it enables the function. If it doesn't understand it, or >> doesn't >>> see it in Required, it's not enabled. In some folk's preferred >>> implementation, you use the existing Hold signaling (SDP >> sendrecv=inactive) >>> to indicate "hook state", and rather than sending BYE from the UA. >>> The >> PSAP >>> terminates the call. The UA can terminate if it doesn't >complete the >>> ReINVITE that signals a hook state change. I think that avoids the >> "brick" >>> problem. There is NO added latency. It doesn't use any resources >>> that weren't already allocated for the call. You do something >>> similar with CANCEL. >>> >>> Brian (who is still listening) >>> >>> -----Original Message----- >>> From: Ted Hardie [mailto:hardie@qualcomm.com] >>> Sent: Wednesday, October 08, 2008 5:41 PM >>> To: Brian Rosen; 'DRAGE, Keith (Keith)'; 'Henning >Schulzrinne'; 'Marc >>> Linsner' >>> Cc: 'ECRIT' >>> Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call >>> Termination >>> >>> At 1:42 PM -0700 10/8/08, Brian Rosen wrote: >>>> I do not accept that the telecommunications industry can >override a >>>> reasonable requirement like this making an argument that "the >>>> operator >> may >>>> need resources for other purposes". This is an individual >call, and >> we're >>>> talking about disconnect under control of one of two humans. There >> aren't >>>> many 'resources' that are available for 'other purposes'. PSAPs >>>> aren't dictators, nor do they have veto rights, but this >is a pretty >>>> reasonable requirement I believe. >>> >>> I continue to believe we're talking past each other here, and my >> experience >>> has been that folks talking past each other tend to get >louder and listen >>> less. I'm trying to avoid that by trying to go back to >the basics here, >>> and I hope you'll take that in the spirit meant--trying to >avoid this >>> turning into a situation where anyone stops listening. >>> >>> At the base line, I think one of the issues is your use of >the term >>> "requirement". A group of PSAP operators would like the >system that >>> replaces the current system to have specific >characteristics. One of >>> the desired characteristics is that only a PSAP call-taker can >> terminate >>> a call which has reached the PSAP. >>> >>> If Marc is correct, the Canadian jurisdiction PSAPs live >without this >>> characteristic for about two-thirds of their calls. The system >>> clearly works when this characteristic is not present. It may be a >>> very strong desire, but there >> is >>> no overall system failure when it is not present. U.S. PSAPs had >>> this characteristic and it was dropped, over their objections. The >>> 911 system continues to work here, even without this. >Call-backs and other methods >>> are used instead. The PSAP operators feel that this is >not as good, and >>> they >>> are the experts on what works for them here; no one is denying this. >>> >>> But some of us have serious concerns about adding protocol >mechanisms >>> to the ECRIT system to support this characteristic, especially if >>> they necessitate the introduction of a negotiation phase >that is not >>> currently present. >> The >>> risks here are quite real, and they are obvious enough that even >>> amateurs can see them. If a negotiation phase adds significant >>> latency, rates of >>> call abandonment *will* go up. To take a ridiculous number, if it >>> takes 20 seconds to do this negotiation, supporting this is out of >>> the question. Way too many people will give up completely or be in >>> seriously worse straits to make that sensible. That number is >>> clearly not probable, but it indicates the need to balance. That >>> same need for balance is needed in other arenas: the need to >>> maintain the privacy of the user may be mandated or desired in some >>> jurisdictions; the need to maintain the security of the >communication >>> channel; the need for the caller to make other calls; and, yes, the >>> need to free resources so that *other* callers can make their own >>> calls (which in disaster situations may also be to >emergency services). >>> >>> I know I would feel more like I'm being heard if you acknowledged >>> that there are other needs to balance here, and I hope you >hear that >>> I understand that PSAP operators have experience with this system >>> that I do not. >>> regards, >>> Ted Hardie >>> >>> >>> >>> >>> >> >> > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 9 08:20:33 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFE673A6C83; Thu, 9 Oct 2008 08:20:33 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0AA03A6C87 for ; Thu, 9 Oct 2008 08:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.742 X-Spam-Level: X-Spam-Status: No, score=-5.742 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RaWHCUHv6BY for ; Thu, 9 Oct 2008 08:20:28 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id AB9233A6C20 for ; Thu, 9 Oct 2008 08:20:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,383,1220227200"; d="scan'208,217";a="107543100" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 09 Oct 2008 15:20:44 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m99FKiHM007160; Thu, 9 Oct 2008 08:20:44 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m99FKZcN018911; Thu, 9 Oct 2008 15:20:44 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 11:20:39 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 11:20:38 -0400 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 09 Oct 2008 11:20:37 -0400 From: Marc Linsner To: "'ECRIT'" , Brian Rosen Message-ID: Thread-Topic: draft-rosen-ecrit-premature-disconnect-rqmts-00.txt Thread-Index: AckqIpTFo+TlItaJFE2ju7LZkx2Y4g== Mime-version: 1.0 X-OriginalArrivalTime: 09 Oct 2008 15:20:38.0512 (UTC) FILETIME=[95AC4700:01C92A22] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2742; t=1223565644; x=1224429644; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20draft-rosen-ecrit-premature-disconnect-rqmts-00 .txt |Sender:=20; bh=gkNk2f6jiic6xSNIpycYfZMIbnGMYE9/w86L/ZLjlU4=; b=VEt1S+apSS/5n9AvPN+x2dfnYq703YKSYFM8OKoTXlpGZSnPvs9wtnF4Y+ fH/W52bX7bXykL30S9FmRUNPYq4fV0mH6/91kOHugJ3s6vc9km7R5LJKqF95 nA1Y9VqCNZ; Authentication-Results: sj-dkim-4; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1841162252==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1841162252== Content-type: multipart/alternative; boundary="B_3306396038_734984" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3306396038_734984 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I have objection with: =B3PD-5 When PD-1 is enforced, the caller must not be able to place another call until the PSAP allows the call to be released. Rationale: Priority must be given to the PSAP until such time the cal= l taker determines the call can be terminated.=B2 I strongly disagree with this requirement. Joe Citizen could very well hav= e a more important call to establish than continuing his conversation with th= e PSAP. If the intent is for the PSAP call taker to be able to re-establish communication with the caller, that can be done without bricking the UA. =B3PD-6 All Media and signaling streams flowing between the caller and call taker must be maintained to the extent needed for rapid reconnection. Rationale: Media and signaling resources must be available as soon as the user re-answers.=B2 This rationale and the requirement don=B9t match. Rapid reconnection does no= t require the original session to be maintained. -Marc- --B_3306396038_734984 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable draft-rosen-ecrit-premature-disconnect-rqmts-00.txt I have objection with:

“PD-5  When PD-1 is enforced, the caller must not be able to pla= ce another call until the PSAP allows the call to be released.
     Rationale:  Priority must be given to th= e PSAP until such time the call taker determines the call can be terminated.= ”

I strongly disagree with this requirement.  Joe Citizen could very wel= l have a more important call to establish than continuing his conversation w= ith the PSAP.  If the intent is for the PSAP call taker to be able to r= e-establish communication with the caller, that can be done without bricking= the UA.

“PD-6  All Media and signaling streams flowing between the calle= r and call taker must be maintained to the extent needed for rapid reconnect= ion.
     Rationale:  Media and signaling resource= s must be available as soon as the user re-answers.”

This rationale and the requirement don’t match.  Rapid reconnect= ion does not require the original session to be maintained.

-Marc- --B_3306396038_734984-- --===============1841162252== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1841162252==-- From ecrit-bounces@ietf.org Thu Oct 9 08:26:57 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C4E73A6A63; Thu, 9 Oct 2008 08:26:57 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B793A6A63 for ; Thu, 9 Oct 2008 08:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YU-SXwD8ommv for ; Thu, 9 Oct 2008 08:26:51 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 94BBA3A69B9 for ; Thu, 9 Oct 2008 08:26:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,383,1220227200"; d="scan'208,217";a="23747426" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Oct 2008 15:27:35 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m99FRZcR011666; Thu, 9 Oct 2008 11:27:35 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m99FRZod007785; Thu, 9 Oct 2008 15:27:35 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 11:27:35 -0400 Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 11:27:34 -0400 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 09 Oct 2008 11:27:33 -0400 From: Marc Linsner To: "'ECRIT'" , Brian Rosen Message-ID: Thread-Topic: Abandoned Call - draft-rosen-ecrit-premature-disconnect-rqmts-00.txt Thread-Index: AckqI4y61B8+Q0s5Gka6sWx4MlkYHQ== Mime-version: 1.0 X-OriginalArrivalTime: 09 Oct 2008 15:27:34.0528 (UTC) FILETIME=[8DA34800:01C92A23] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1361; t=1223566055; x=1224430055; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Abandoned=20Call=20-=20draft-rosen-ecrit-premat ure-disconnect-rqmts-00.txt |Sender:=20 |To:=20=22'ECRIT'=22=20,=20Brian=20Rosen=20 ; bh=oMIbQlFTPaFQUJWsanOT/Fj6aKOv9pME9Oeo1Um1yGg=; b=sK8n+6ZSPmJYE3TX1s59YfzQC+5JtALx6wQD/HYLgZHQRz0eGG2bRWhT6g GTC3PWDwfl3Ij6MMB+sxAxmXX/OZtrtzNEOfmPSVFjjmb0/1g29YReqDKGNO uvUOGsrvMs; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Ecrit] Abandoned Call - draft-rosen-ecrit-premature-disconnect-rqmts-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1772078490==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1772078490== Content-type: multipart/alternative; boundary="B_3306396454_697079" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3306396454_697079 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Please further clarify your definition of =8Cabandoned call=B9. The way I read the document, I=B9m assuming that a call has been established, media resources are up, but humans are not yet communicating. This would b= e the case if the caller is placed in a call center application queue waiting for the next available agent. Thanks, -Marc- --B_3306396454_697079 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Abandoned Call - draft-rosen-ecrit-premature-disconnect-rqmts-00.txt= Please further clarify your definition of ‘abandoned call’.
The way I read the document, I’m assuming that a call has been establ= ished, media resources are up, but humans are not yet communicating.  T= his would be the case if the caller is placed in a call center application q= ueue waiting for the next available agent.

Thanks,

-Marc- --B_3306396454_697079-- --===============1772078490== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1772078490==-- From ecrit-bounces@ietf.org Fri Oct 10 07:17:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4D63A6A73; Fri, 10 Oct 2008 07:17:45 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AB8A3A6A73 for ; Fri, 10 Oct 2008 07:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.958 X-Spam-Level: X-Spam-Status: No, score=-3.958 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llOyvgHDgiwq for ; Fri, 10 Oct 2008 07:17:43 -0700 (PDT) Received: from anchor-internal-1.mail.demon.net (anchor-internal-1.mail.demon.net [195.173.56.100]) by core3.amsl.com (Postfix) with ESMTP id B91513A6949 for ; Fri, 10 Oct 2008 07:17:42 -0700 (PDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id m9AEIJGR011800Fri, 10 Oct 2008 14:18:19 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1KoIoq-000IEW-00; Fri, 10 Oct 2008 15:18:16 +0100 Date: Fri, 10 Oct 2008 15:18:16 +0100 From: "Clive D.W. Feather" To: Marc Linsner Message-ID: <20081010141816.GA68725@finch-staff-1.thus.net> References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Cc: 'ECRIT' Subject: Re: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Marc Linsner said: > =B3PD-5 When PD-1 is enforced, the caller must not be able to place anot= her > call until the PSAP allows the call to be released. > Rationale: Priority must be given to the PSAP until such time the c= all > taker determines the call can be terminated.=B2 > = > I strongly disagree with this requirement. Joe Citizen could very well h= ave > a more important call to establish than continuing his conversation with = the > PSAP. In particular, you see an accident happen, stop, and phone the emergency services. While it's still ringing, someone says that they've already reported it and people are on their way. You might as well hang up rather than waste the operator's time. -- = Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS - a Cable and Wireless business _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 10 14:49:34 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E67AF3A67B3; Fri, 10 Oct 2008 14:49:34 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F260A3A6967 for ; Fri, 10 Oct 2008 14:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm-Zo0oXIsCj for ; Fri, 10 Oct 2008 14:49:33 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id EB9FB3A6901 for ; Fri, 10 Oct 2008 14:49:32 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m9ALoE4n027634 for ; Fri, 10 Oct 2008 16:50:14 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.10]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 16:50:14 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 10 Oct 2008 16:50:13 -0500 Message-ID: <0AB57A5DEF898646A069F23604A2635301D3D9FE@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] Thread-Index: AcklisjKTGRDf5ZpQkeHyRw84SHr/wFkvInA References: From: "Barclay, Deborah L \(Deb\)" To: X-OriginalArrivalTime: 10 Oct 2008 21:50:14.0056 (UTC) FILETIME=[2CFEFA80:01C92B22] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Milan, John-Luc, For the example provided below, the service-urn would be replaced as a result of determining the call is routed to a CS PSAP. The service-urn is preserved until the routing function determines the appropriate emergency center and only replaces the service-urn because it had to be converted to a digits. If different service-urns require different destinations, that would have been accounted for. The single sos parameter should be sufficient for proper emergency call handling and the service-urn is available and sufficient for correct routing. Since opinions were being sought, my opinion is to keep the sos parameter/marker simple for efficient emergency call handling purposes. Thank you, Deb Barclay > ------------------------------ > > Message: 2 > Date: Fri, 3 Oct 2008 14:45:08 +0100 > From: "Milan Patel" > Subject: Re: [Ecrit] [Fwd: I-D > Action:draft-patel-ecrit-sos-parameter-00.txt] > To: "John-Luc Bakker" , "ECRIT" > > Message-ID: > > <0913B6CD18F370498CD65864CF254E9006BFCF94@zharhxm1.corp.nortel.com> > Content-Type: text/plain; charset="us-ascii" > > Hi John-Luc, > > Currently the draft only specifies that the "sos" parameter > only conveys information that the request/response is related > to an emergency session. But I do find your use case valid. > I'd like to know what others think, but can propose the > extension in version-01 if there is wider support. > > Best regards, > Milan > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of John-Luc Bakker > Sent: 03 October 2008 14:32 > To: ECRIT > Subject: Re: [Ecrit] [Fwd: I-D > Action:draft-patel-ecrit-sos-parameter-00.txt] > > Milan, > > The proposed new URI parameter is opaque. It marks the call > as an emergency call but fails to convey the emergency call > type even if an emergency call type could be deduced from the > original request. > Particularly if the Emergency Service URN in the Request-URI > is replaced by a network entity, as you suggest, not loosing > the emergency call type information seems useful. In some > deployments, emergency calls are routed to PSAPs that support > the requested emergency types. > > Kind regards, > > John-Luc > > On Mon, Sep 15, 2008 at 3:24 AM, Hannes Tschofenig > wrote: > > Please take a look at this document. Milan would like to hear some > comments! > > > > Ciao > > Hannes > > > > -------- Original Message -------- > > Subject: I-D Action:draft-patel-ecrit-sos-parameter-00.txt > > Date: Fri, 12 Sep 2008 09:45:01 -0700 (PDT) > > From: Internet-Drafts@ietf.org > > Reply-To: internet-drafts@ietf.org > > To: i-d-announce@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : SOS Uniform Resource Identifier (URI) > parameter for marking of Session Initiation Protocol (SIP) > requests related to emergency services > > Author(s) : M. Patel > > Filename : draft-patel-ecrit-sos-parameter-00.txt > > Pages : 9 > > Date : 2008-09-12 > > > > This memo describes requirements and protocol conventions for a new > > SIP (Session Initiation Protocol) URI parameter intended > for marking > > SIP requests and responses related to emergency services. This > > proposal addresses issues that exist in the current 3rd Generation > > Partnership Project IP Multimedia Subsystem (IMS) Emergency > services > > solution, but is not precluded from being used by other SIP-based > > emergency services solutions. It is not intended as a > replacement for > > the service URN. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-parameter-00.t xt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 12 02:04:39 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214F43A6931; Sun, 12 Oct 2008 02:04:39 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 591CC3A6927 for ; Sun, 12 Oct 2008 02:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.28 X-Spam-Level: X-Spam-Status: No, score=-3.28 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGrU9N60+MAo for ; Sun, 12 Oct 2008 02:04:36 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 2A1E83A6934 for ; Sun, 12 Oct 2008 02:04:35 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9C95Pqo016214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 12 Oct 2008 11:05:25 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9C95OK6029752; Sun, 12 Oct 2008 11:05:24 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 11:05:23 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 11:05:23 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 12 Oct 2008 12:00:39 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Design Team Status Update Thread-Index: AcksSP+0/klUyEpPRHK/ir0/XhBc0Q== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: , , "ECRIT" X-OriginalArrivalTime: 12 Oct 2008 09:05:23.0040 (UTC) FILETIME=[A8A52600:01C92C49] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081012110525-73813BB0-2E36A4F9/0-0/0-15 X-purgate-size: 1503/0 Subject: [Ecrit] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, so far, we have the following persons on the design team but a few responses are still pending: * Guy Caron (g.caron at bell.ca) * James Polk (jmpolk at cisco.com) * Ted Hardie (hardie at qualcomm.com) * Henning Schulzrinne (hgs at cs.columbia.edu) * Keith Drage (drage at alcatel-lucent.com) * Brian Rosen (Brian.Rosen at neustar.biz) * Theresa Reese (treese at telcordia.com) The design team is lead by the working group chairs: Marc Linsner and Hannes Tschofenig The rules for design teams are described in http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt We thought that we could re-use our IETF ECRIT mailing list for discussions rather than creating a separate list. Let's see how that works out. >From a procedural point of view we would start with reviewing Brian's draft: http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnect-rqmts-00 .txt Marc, for example, recently provided a few review comments: http://www.ietf.org/mail-archive/web/ecrit/current/msg05511.html There are some other review comments from the previous IETF meeting, see http://www.ietf.org/mail-archive/web/ecrit/current/msg05450.html http://www.ietf.org/mail-archive/web/ecrit/current/msg05447.html If necessary, we will schedule phone conference calls. The initial goal is to agree on some of the requirements. At IETF#73 a status update will be given. Then, we will determine the next steps. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 12 02:19:34 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80D673A6960; Sun, 12 Oct 2008 02:19:34 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547063A67ED for ; Sun, 12 Oct 2008 02:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.237 X-Spam-Level: X-Spam-Status: No, score=-5.237 tagged_above=-999 required=5 tests=[AWL=1.362, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtNSqmu27ySj for ; Sun, 12 Oct 2008 02:19:32 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 58D193A6946 for ; Sun, 12 Oct 2008 02:19:31 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9C9KArS015882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 12 Oct 2008 11:20:10 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9C9K9Dw003897; Sun, 12 Oct 2008 11:20:10 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 11:19:56 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 11:19:56 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 12 Oct 2008 12:19:48 +0300 Message-ID: In-Reply-To: <48A9B707.7040501@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary-00.txt Thread-Index: AckBW08PHdfaYR1vQKycWjm+ZLygXQq8FHBQ References: <48A9B707.7040501@gmx.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 12 Oct 2008 09:19:56.0211 (UTC) FILETIME=[B1187830:01C92C4B] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081012112010-40301BB0-D40570B6/0-0/0-15 X-purgate-size: 721/0 Subject: Re: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It would be good if a few more folks could comment on this document by Karl Heinz! >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Hannes Tschofenig >Sent: 18 August, 2008 20:53 >To: 'ECRIT' >Subject: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary-00.txt > >During the IETF#72 ECRIT session I noticed that not many WG >members have read draft-wolf-ecrit-lost-servicelistboundary-00.txt. > >Please take a look at: >http://tools.ietf.org/id/draft-wolf-ecrit-lost-servicelistbound >ary-00.txt > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 12 02:20:34 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9C7F3A6943; Sun, 12 Oct 2008 02:20:34 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACE8D3A6946 for ; Sun, 12 Oct 2008 02:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.317 X-Spam-Level: X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=-0.718, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0YKtF7X7mUd for ; Sun, 12 Oct 2008 02:20:33 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id A02573A695F for ; Sun, 12 Oct 2008 02:20:32 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9C9LGkA027151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 12 Oct 2008 11:21:16 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9C9LFqe004825; Sun, 12 Oct 2008 11:21:16 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 11:20:44 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 11:20:44 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 12 Oct 2008 12:20:38 +0300 Message-ID: In-Reply-To: <48A9B72B.30203@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-rosen-ecrit-ecall-01.txt Thread-Index: AckBW2BkJ4nt7p5KQgqm7eEX3p1seAq8FXyw References: <48A9B72B.30203@gmx.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 12 Oct 2008 09:20:44.0116 (UTC) FILETIME=[CDA63140:01C92C4B] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081012112116-73811BB0-D6CAE3CA/0-0/0-15 X-purgate-size: 726/0 Subject: Re: [Ecrit] draft-rosen-ecrit-ecall-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Please also read this document and provide feedback. This document provides a framework for emergency calls triggered from vehicles. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Hannes Tschofenig >Sent: 18 August, 2008 20:54 >To: 'ECRIT' >Subject: [Ecrit] draft-rosen-ecrit-ecall-01.txt > >During the IETF#72 ECRIT session I noticed that not many WG >members have read draft-rosen-ecrit-ecall-01.txt. > >Please take a look at: >http://tools.ietf.org/id/draft-rosen-ecrit-ecall-01.txt > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 12 02:54:50 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38A93A695B; Sun, 12 Oct 2008 02:54:50 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A8F3A696C for ; Sun, 12 Oct 2008 02:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.347 X-Spam-Level: X-Spam-Status: No, score=-3.347 tagged_above=-999 required=5 tests=[AWL=-0.748, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjjzCatF3Khl for ; Sun, 12 Oct 2008 02:54:49 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 137B83A68D5 for ; Sun, 12 Oct 2008 02:54:46 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9C9tYGK015042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 12 Oct 2008 11:55:36 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9C9tUq8018500 for ; Sun, 12 Oct 2008 11:55:34 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 11:55:32 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 11:55:29 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 12 Oct 2008 12:36:19 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Service Classification Thread-Index: AcksTftnVKzhMPmYQY6kBWHcDIaplg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 12 Oct 2008 09:55:29.0332 (UTC) FILETIME=[A888E740:01C92C50] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081012115534-73811BB0-17D4479D/0-0/0-15 X-purgate-size: 1215/0 Subject: [Ecrit] Service Classification X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, I wanted to figure out how to proceed with the following two documents: http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.txt http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-00.txt The IANA consideration section of RFC 5031 http://www.ietf.org/rfc/rfc5031.txt says: " Services and sub-services are identified by labels managed by IANA, according to the processes outlined in [RFC2434] in a new registry called "Service URN Labels". Thus, creating a new service requires IANA action. The policy for adding top-level service labels is 'Standards Action'. (This document defines the top-level services 'sos' and 'counseling'.) The policy for assigning labels to sub- services may differ for each top-level service designation and MUST be defined by the document describing the top-level service. " Unfortunately, both documents define top-level services. As such, we would have to pick them up as WG item in order to advance them. I don't like that approach too much. So, I would like to hear from the authors on how they think these type of documents should be progressed through the IETF. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 12 04:24:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B433A6915; Sun, 12 Oct 2008 04:24:45 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13B5A3A698D for ; Sun, 12 Oct 2008 04:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.309 X-Spam-Level: X-Spam-Status: No, score=-5.309 tagged_above=-999 required=5 tests=[AWL=1.290, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3lq4uztwvJi for ; Sun, 12 Oct 2008 04:24:43 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id DCB363A67A8 for ; Sun, 12 Oct 2008 04:24:42 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9CBPWb0002037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 12 Oct 2008 13:25:32 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9CBPTx2026299 for ; Sun, 12 Oct 2008 13:25:31 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 13:25:31 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 13:25:30 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 12 Oct 2008 14:12:02 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-mapping-arch: Discuss by Russ Thread-Index: AcksW1piCSWuq89ISy2p/iWNua4i+Q== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 12 Oct 2008 11:25:30.0350 (UTC) FILETIME=[3BCAD8E0:01C92C5D] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081012132532-40305BB0-83B6F722/0-0/0-15 X-purgate-size: 616/0 Subject: [Ecrit] draft-ietf-ecrit-mapping-arch: Discuss by Russ X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org https://datatracker.ietf.org/idtracker/draft-ietf-ecrit-mapping-arch/com ment/78013/ ----------------- Commented by: Russ Housley Comment: Looking at http://www.ietf.org/u/ietfchair/info-exp.html (especially Guideline 3), I wonder why this is not Experimental. ----------------- When reading that document then the document status should be experimental. When considering how people would typically perceive an experimental document then it should be informal. I fear that nobody knows nor has ever read the above-mentioned document. I suggest to leave it informational. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 12 04:24:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E2433A69A7; Sun, 12 Oct 2008 04:24:45 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8D93A67A8 for ; Sun, 12 Oct 2008 04:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.371 X-Spam-Level: X-Spam-Status: No, score=-3.371 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHE3bMRxkhns for ; Sun, 12 Oct 2008 04:24:43 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 7409B3A6915 for ; Sun, 12 Oct 2008 04:24:43 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9CBPWVE007584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 12 Oct 2008 13:25:32 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9CBPQ6c026123 for ; Sun, 12 Oct 2008 13:25:32 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 13:25:31 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 13:25:31 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 12 Oct 2008 14:12:11 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-mapping-arch: Comment by Jari Thread-Index: AcksW197m0OGG72eQ2G95twPab5L/w== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 12 Oct 2008 11:25:31.0210 (UTC) FILETIME=[3C4E12A0:01C92C5D] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081012132532-73818BB0-CE3DE4B9/0-0/0-15 X-purgate-size: 1322/0 Subject: [Ecrit] draft-ietf-ecrit-mapping-arch: Comment by Jari X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org https://datatracker.ietf.org/idtracker/draft-ietf-ecrit-mapping-arch/com ment/78008/ ----------------- Commented by: Jari Arkko Comment: Christian Vogt's review: This document describes an architecture for location based service discovery. The architecture resolves location information into URLs. The document is well written and about ready for publication. One thing that I would have wished as a reader is more clarity on the organization of mapping information at the beginning of the document. The described architecture uses "forest guides" and trees of LoST servers for mapping resolution. It would be helpful for the reader if the document would define forest guides as the top level of a single conceptual hierarchy, which, at lower levels, branches into what is called "trees" in the document. A smaller nit: The reader may wonder why the forest guides in figure 1 are interconnected. It may be worthwhile to explicitly state that these connections symbolize the optional synchronization protocol that may be executed between them. ----------------- I am not sure how to address the first comment. On the second comment, I think it is reasonable to mention the synchronization protocol executed between the FGs with a pointer to the IETF draft. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 12 04:47:10 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3953A67B2; Sun, 12 Oct 2008 04:47:10 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EDAB3A697E for ; Sun, 12 Oct 2008 04:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.336 X-Spam-Level: X-Spam-Status: No, score=-3.336 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJFdtsREB6Ov for ; Sun, 12 Oct 2008 04:47:03 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 5C5423A67B2 for ; Sun, 12 Oct 2008 04:47:03 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9CBPXZX007677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 12 Oct 2008 13:25:33 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9CBPSn2026214 for ; Sun, 12 Oct 2008 13:25:33 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 13:25:33 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 13:25:30 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 12 Oct 2008 14:12:05 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-mapping-arch: Comment by Chris Thread-Index: AcksW1vnRWS8MuXSTPyQM2JfRN1SBg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 12 Oct 2008 11:25:30.0888 (UTC) FILETIME=[3C1CF080:01C92C5D] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081012132533-73810BB0-0012DB06/0-0/0-15 X-purgate-size: 282/0 Subject: [Ecrit] draft-ietf-ecrit-mapping-arch: Comment by Chris X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org https://datatracker.ietf.org/idtracker/draft-ietf-ecrit-mapping-arch/com ment/77972/ ----------------- Commented by: Chris Newman Comment: TLS and XML digital signatures should be informative references. ----------------- Let's add 2 informative references _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 12 04:47:12 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7F03A6994; Sun, 12 Oct 2008 04:47:12 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36B0C3A6974 for ; Sun, 12 Oct 2008 04:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.304 X-Spam-Level: X-Spam-Status: No, score=-3.304 tagged_above=-999 required=5 tests=[AWL=-0.705, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD6-uYP3QiWK for ; Sun, 12 Oct 2008 04:47:04 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 772293A6941 for ; Sun, 12 Oct 2008 04:47:04 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9CBPXIM007702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 12 Oct 2008 13:25:33 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9CBPSn4026214 for ; Sun, 12 Oct 2008 13:25:33 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 13:25:33 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 13:25:31 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 12 Oct 2008 14:12:14 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-mapping-arch: Discuss #2 by Cullen Thread-Index: AcksW2Gl5hXicNNxQ6SbittORXsEDw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 12 Oct 2008 11:25:31.0763 (UTC) FILETIME=[3CA27430:01C92C5D] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081012132533-73813BB0-BBAC364A/0-0/0-15 X-purgate-size: 628/0 Subject: [Ecrit] draft-ietf-ecrit-mapping-arch: Discuss #2 by Cullen X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org https://datatracker.ietf.org/idtracker/draft-ietf-ecrit-mapping-arch/com ment/78860/ ----------------- Commented by: Cullen Jennings Comment: My understanding is the queries supported here need to match the queries possible in LOST. If this is incorrect, please let me know. Right now this document does not allow the Polygon, Circle, Ellipse, ArcBand that are allowed in Lost. ----------------- This document largely describes LoST protocol deployment. I wouldn't find additional aspects that could get out of sync between LoST and this document (beyond what I commented in my previous mail). _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 12 04:47:12 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3713A69A5; Sun, 12 Oct 2008 04:47:12 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D4E3A6941 for ; Sun, 12 Oct 2008 04:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9s6ufwOQrip for ; Sun, 12 Oct 2008 04:47:06 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 6E7213A6975 for ; Sun, 12 Oct 2008 04:47:05 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9CBPWJO007572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 12 Oct 2008 13:25:32 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9CBPUTV026363 for ; Sun, 12 Oct 2008 13:25:32 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 13:25:31 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 13:25:30 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 12 Oct 2008 14:12:08 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-mapping-arch: Discuss by Cullen Thread-Index: AcksW13w9bg2L5e5TLy0vWowRLHUdw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 12 Oct 2008 11:25:30.0772 (UTC) FILETIME=[3C0B3D40:01C92C5D] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081012132532-73812BB0-0B96B99D/0-0/0-15 X-purgate-size: 1570/0 Subject: [Ecrit] draft-ietf-ecrit-mapping-arch: Discuss by Cullen X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org https://datatracker.ietf.org/idtracker/draft-ietf-ecrit-mapping-arch/com ment/77955/ ----------------- Commented by: Cullen Jennings Comment: These are two pretty easy to fix issues: We need to have this document in sync with LOST about what shapes are allowed in a location. Right now Lost seems to allow Point, Polygon, Circle, Ellipse, ArcBand. Coverage regions are described by sets of polygons enclosing contiguous geographic areas or by descriptors enumerating groups of civic locations. For the former, the LoST server performs a point- in-polygon operation to find the polygon that contains the query point. (More complicated geometric matching algorithms may be added in the future.) The forest guides need to decide which coverage region the query is in. I think the FG need to use the same algorithm that the LOST servers use or it is possible to miss the correct tree. ----------------- I believe that the issue with this comment is the following: LoST allows arbitrary service boundaries to be returned. However, the location of the Target is described via (currently) two location profiles that express location in the shapes listed above. As such, there is no need for alignment between the two but one could clarify this relationship in the document. We had a discussion about the mapping algorithm in the LoST document. The description in Section 12.2 of LoST is relevant in this context. Maybe a pointer to that section would be appropriate. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 12 04:47:48 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30F23A6816; Sun, 12 Oct 2008 04:47:48 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC353A6816 for ; Sun, 12 Oct 2008 04:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWhqeQI2pVGP for ; Sun, 12 Oct 2008 04:47:47 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 9C02A3A67B2 for ; Sun, 12 Oct 2008 04:47:46 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9CBPQxo006965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 12 Oct 2008 13:25:26 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9CBPMKm025920; Sun, 12 Oct 2008 13:25:26 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 13:25:25 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 13:25:22 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 12 Oct 2008 14:11:59 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-mapping-arch Thread-Index: AcksW1h1VtnXnfgjSU++jPTF5fBADA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 12 Oct 2008 11:25:23.0022 (UTC) FILETIME=[376CAEE0:01C92C5D] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081012132526-73811BB0-D3E1E7CE/0-0/0-15 X-purgate-size: 329/0 Subject: [Ecrit] draft-ietf-ecrit-mapping-arch X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I went through the WG drafts and found that draft-ietf-ecrit-mapping-arch is pending a draft update. I went through the tracker to see what feedback has been provided. I will share my impressions with the group in subsequent mails. Henning, can you ship a draft update within the next few days? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 12 05:00:04 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB58E28C12D; Sun, 12 Oct 2008 05:00:04 -0700 (PDT) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 16CE13A698D; Sun, 12 Oct 2008 05:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081012120002.16CE13A698D@core3.amsl.com> Date: Sun, 12 Oct 2008 05:00:02 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-location-hiding-req-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --NextPart 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 : Location Hiding: Problem Statement and Requirements Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-ecrit-location-hiding-req-01.txt Pages : 10 Date : 2008-10-12 The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to end points or VoIP service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). For determining the PSAP Uniform Resource Identifier (URI) the usage of the Location-to- Service Translation (LoST) Protocol is envisioned. This document explores the architectural impact for the IETF emergency services architecture for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. This document provides a problem statement and lists requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-location-hiding-req-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-location-hiding-req-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-12045936.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Sun Oct 12 05:14:54 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DCAC3A69A2; Sun, 12 Oct 2008 05:14:54 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3483A69A2 for ; Sun, 12 Oct 2008 05:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.222 X-Spam-Level: X-Spam-Status: No, score=-3.222 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMFGpaPPSvbO for ; Sun, 12 Oct 2008 05:14:53 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id DBABE3A677D for ; Sun, 12 Oct 2008 05:14:52 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9CCFcg2006723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 12 Oct 2008 14:15:38 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9CCFbbV015949 for ; Sun, 12 Oct 2008 14:15:38 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 14:15:24 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 14:15:22 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 12 Oct 2008 15:08:59 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-location-hiding-req Updated; ready for the IESG Thread-Index: AcksY080rO1BfTaPQF6Bq4a59UIUFQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 12 Oct 2008 12:15:22.0336 (UTC) FILETIME=[3327AE00:01C92C64] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081012141538-7381BBB0-89848569/0-0/0-15 X-purgate-size: 846/0 Subject: [Ecrit] draft-ietf-ecrit-location-hiding-req Updated; ready for the IESG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, I have submitted an updated of draft-ietf-ecrit-location-hiding-req, see http://www.ietf.oerg/internet-drafts/draft-ietf-ecrit-location-hiding-re q-01.txt This version of the document addresses the WGLC feedback from Richard, Martin and Barbara. The WGLC announcements can be found here: http://www.ietf.org/mail-archive/web/ecrit/current/msg05397.html http://www.ietf.org/mail-archive/web/ecrit/current/msg05282.html The comments are here: http://www.ietf.org/mail-archive/web/ecrit/current/msg05284.html http://www.ietf.org/mail-archive/web/ecrit/current/msg05431.html http://www.ietf.org/mail-archive/web/ecrit/current/msg05400.html We will ship the document to the IESG on the 19th October 2008. Please let us know whether you are fine with the draft update. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 12 12:45:06 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D3C3A69B8; Sun, 12 Oct 2008 12:45:06 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3183A69CE for ; Sun, 12 Oct 2008 12:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQ8G+EdZ27Mc for ; Sun, 12 Oct 2008 12:45:00 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 4935A3A69B8 for ; Sun, 12 Oct 2008 12:45:00 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9CJjNX4010012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 12 Oct 2008 21:45:23 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9CJjLo5011050 for ; Sun, 12 Oct 2008 21:45:23 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 21:45:23 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 21:45:22 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 12 Oct 2008 22:44:22 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PROTO Writeup for draft-ietf-ecrit-specifying-holes-00.txt Thread-Index: Acksoux6DUcs/V+HTyWwGbuX2qwTNw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 12 Oct 2008 19:45:22.0543 (UTC) FILETIME=[10884FF0:01C92CA3] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081012214523-73812BB0-370E2242/0-0/0-15 X-purgate-size: 7998/0 Subject: [Ecrit] PROTO Writeup for draft-ietf-ecrit-specifying-holes-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Here is a proposal for the PROTO writeup we are going to submit sometime next week for http://www.ietf.org/internet-drafts/draft-ietf-ecrit-specifying-holes-00 .txt PROTO WRITEUP for draft-ietf-ecrit-specifying-holes-00.txt ========================================================== (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document Shepherd is Hannes Tschofenig. The document is ready for publications and I have reviewed the document personally. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document is an informative clarification on how to describes holes in service boundaries. Carl Reed from the OGC has performed a review of the document. There are no concerns about the depth and the breadth of the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? The document contains XML snippets and an XML instance document. The XML snippets make use of the description provided in http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-1 3.txt and the XML instance document is based on a draft version of the LoST synchronization protocol. As such, the syntaxt might change. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus behind this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) There are no concerns with this document. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document does not contain nits. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has references split into normative and informative references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? An IANA consideration section exists but there are not actions for IANA since this is a requirements document. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains XML snippets taken from http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-1 3.txt and an XML instance document related to a not yet finished XML based protocol (as an example only): http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-00.txt (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. Document Announcement Write-Up for "Specifying Holes in LoST Service Boundaries" (draft-ietf-ecrit-specifying-holes-00.txt) Technical Summary The LoST protocol maps location and service identifiers to Uniform Resource Identifiers (URIs). LoST may additionally return a so-called service boundary, i.e., a region within which all locations map to the same service URI or set of URIs for a given service. The geodetic boundary is a polygon made up of sets of geodetic coordinates specifying an enclosed area. In some circumstances an area enclosed by a polygon, also known as an exterior polygon, may contain exception areas, or holes, that for the same service must yield a different destination to that described by the larger area. This document describes how holes should be specified in service boundaries defined using a GML encoding for the polygons and their internal elements (holes). Working Group Summary There is consensus in the WG to publish this document. Document Quality The document has been reviewed by ECRIT working group members and feedback was provided by Carl Reed from the OGC. Personnel Hannes Tschofenig is the document shepherd for this document. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 12 12:45:10 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00D5328B797; Sun, 12 Oct 2008 12:45:10 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B404228B797 for ; Sun, 12 Oct 2008 12:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.178 X-Spam-Level: X-Spam-Status: No, score=-5.178 tagged_above=-999 required=5 tests=[AWL=1.421, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsFw4iFTOuQj for ; Sun, 12 Oct 2008 12:45:05 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 739953A69CE for ; Sun, 12 Oct 2008 12:45:04 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9CJjRJ9009315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 12 Oct 2008 21:45:27 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9CJjNna011133 for ; Sun, 12 Oct 2008 21:45:27 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 21:45:27 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Oct 2008 21:45:26 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 12 Oct 2008 22:44:25 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PROTO Writeup for draft-ietf-ecrit-location-hiding-req-01.txt Thread-Index: Acksou7Bwe7wLS7URQaM6QHhug3goA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 12 Oct 2008 19:45:26.0840 (UTC) FILETIME=[1317FB80:01C92CA3] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081012214527-40300BB0-09E73B2E/0-0/0-15 X-purgate-size: 7734/0 Subject: [Ecrit] PROTO Writeup for draft-ietf-ecrit-location-hiding-req-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Here is a proposal for the PROTO writeup we are going to submit next Sunday for http://www.ietf.org/internet-drafts/draft-ietf-ecrit-location-hiding-req -01.txt PROTO WRITEUP for draft-ietf-ecrit-location-hiding-req-01.txt ============================================================= (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document Shepherd is Marc Linsner. The document is ready for publications and I have reviewed the document personally. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document received a lot of reviews within the group. It was created after long and controversial discussions around feedback obtained from network operators about deploying the IETF emergency services architecture. There are no concerns about the depth and the breadth of the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? There are no concerns with the document. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus behind this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) The topic of location hiding is controversal and lack of excitement surfaced in the ECRIT and the GEOPRIV working group. Key working group members have expressed a lot of concerns but seem to be fine with the resulting requirements document. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document does not contain nits. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has references split into normative and informative references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? An IANA consideration section exists but there are not actions for IANA since this is a requirements document. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document does not contain formal languages. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. Document Announcement Write-Up for "Location Hiding: Problem Statement and Requirements" (draft-ietf-ecrit-location-hiding-req-01.txt) Technical Summary The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to end points or VoIP service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). For determining the PSAP Uniform Resource Identifier (URI) the usage of the Location-to- Service Translation (LoST) Protocol is envisioned. This document provides a problem statement and lists requirements for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. Working Group Summary There is consensus in the WG to publish this document. Document Quality The document has been reviewed by ECRIT working group members and feedback was provided by participants from various emergency services workshops. Personnel Marc Linsner is the document shepherd for this document. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 12 22:30:02 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5999B3A6A94; Sun, 12 Oct 2008 22:30:02 -0700 (PDT) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2C1303A6A60; Sun, 12 Oct 2008 22:30:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081013053001.2C1303A6A60@core3.amsl.com> Date: Sun, 12 Oct 2008 22:30:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-specifying-holes-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --NextPart 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 : Specifying Holes in LoST Service Boundaries Author(s) : J. Winterbottom, M. Thomson Filename : draft-ietf-ecrit-specifying-holes-01.txt Pages : 18 Date : 2008-10-12 This document describes how holes can be specified in geodetic service boundaries. One means of implementing a search solution in a service database, such as one might provide with a LoST server, is described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-specifying-holes-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-specifying-holes-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-12222128.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Sun Oct 12 22:36:16 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB663A6A78; Sun, 12 Oct 2008 22:36:16 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41DBA3A6A60 for ; Sun, 12 Oct 2008 22:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wx-u3aeya+6Z for ; Sun, 12 Oct 2008 22:36:13 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id C7D9C3A657C for ; Sun, 12 Oct 2008 22:36:12 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9D5b4MH015424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 13 Oct 2008 07:37:04 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9D5b0w4012201 for ; Mon, 13 Oct 2008 07:37:04 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Oct 2008 07:37:01 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Oct 2008 07:37:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 08:37:02 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PROTO Writeup for draft-ietf-ecrit-specifying-holes-00.txt Thread-Index: Acksoux6DUcs/V+HTyWwGbuX2qwTNwAUrkhA References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 13 Oct 2008 05:37:00.0905 (UTC) FILETIME=[B7347D90:01C92CF5] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081013073704-73814BB0-312B5B32/0-0/0-15 X-purgate-size: 16661/0 Subject: Re: [Ecrit] PROTO Writeup for draft-ietf-ecrit-specifying-holes-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --- an update based on the recent draft submission. PROTO WRITEUP for draft-ietf-ecrit-specifying-holes-01.txt ========================================================== (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document Shepherd is Hannes Tschofenig. The document is ready for publications and I have reviewed the document personally. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document is an informative clarification on how to describes holes in service boundaries. Carl Reed from the OGC has performed a review of the document. There are no concerns about the depth and the breadth of the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? The document contains XML snippets and an XML instance document. The XML snippets make use of the description provided in http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-1 3.txt and the XML instance document is based on a draft version of the LoST synchronization protocol. The text related to the example indicates that it just illustrative purposes. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus behind this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) There are no concerns with this document. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document does not contain nits. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has references split into normative and informative references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? An IANA consideration section exists but there are not actions for IANA since this is a requirements document. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains XML snippets taken from http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-1 3.txt and an XML instance document related to a not yet finished XML based protocol: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-00.txt The text around the example indicates that it may not validate. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. Document Announcement Write-Up for "Specifying Holes in LoST Service Boundaries" (draft-ietf-ecrit-specifying-holes-01.txt) Technical Summary The LoST protocol maps location and service identifiers to Uniform Resource Identifiers (URIs). LoST may additionally return a so-called service boundary, i.e., a region within which all locations map to the same service URI or set of URIs for a given service. The geodetic boundary is a polygon made up of sets of geodetic coordinates specifying an enclosed area. In some circumstances an area enclosed by a polygon, also known as an exterior polygon, may contain exception areas, or holes, that for the same service must yield a different destination to that described by the larger area. This document describes how holes should be specified in service boundaries defined using a GML encoding for the polygons and their internal elements (holes). Working Group Summary There is consensus in the WG to publish this document. Document Quality The document has been reviewed by ECRIT working group members and feedback was provided by Carl Reed from the OGC. Personnel Hannes Tschofenig is the document shepherd for this document. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Tschofenig, Hannes (NSN - FI/Espoo) >Sent: 12 October, 2008 22:44 >To: ECRIT >Subject: [Ecrit] PROTO Writeup for >draft-ietf-ecrit-specifying-holes-00.txt > >Here is a proposal for the PROTO writeup we are going to >submit sometime next week for >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-specifying >-holes-00 >.txt > > >PROTO WRITEUP for draft-ietf-ecrit-specifying-holes-00.txt >========================================================== > > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? > > Document Shepherd is Hannes Tschofenig. > The document is ready for publications and I have reviewed the > document personally. > > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? > > This document is an informative clarification on how to > describes holes in service boundaries. > > Carl Reed from the OGC has performed a review of the > document. > > There are no concerns about the depth and the breadth >of the reviews. > > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization, or XML? > > The document contains XML snippets and an XML instance document. > The XML snippets make use of the description provided in > >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo- >profile-1 >3.txt > and the XML instance document is based on a draft >version of the > LoST synchronization protocol. As such, the syntaxt >might change. > > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the >document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to >this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. > > There are no concerns. > > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? > > There is consensus behind this document. > > (1.f) Has anyone threatened an appeal or otherwise >indicated extreme > discontent? If so, please summarize the areas of conflict in > separate email messages to the Responsible Area >Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) > > There are no concerns with this document. > > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/.) Boilerplate checks are > not enough; this check needs to be thorough. Has >the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type, and URI type reviews? If the document > does not already indicate its intended status at the top of > the first page, please indicate the intended status here. > > The document does not contain nits. > > (1.h) Has the document split its references into normative and > informative? Are there normative references to >documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative >references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. > > The document has references split into normative and > informative references. > > (1.i) Has the Document Shepherd verified that the document's IANA > Considerations section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process, has the Document > Shepherd conferred with the Responsible Area Director so that > the IESG can appoint the needed Expert during IESG >Evaluation? > > An IANA consideration section exists but there are not actions for > IANA since this is a requirements document. > > > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? > > The document contains XML snippets taken from > >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo- >profile-1 >3.txt > and an XML instance document related to a not yet finished >XML based > protocol (as an example only): > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-00.txt > > > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. > > >Document Announcement Write-Up for "Specifying Holes in LoST >Service Boundaries" >(draft-ietf-ecrit-specifying-holes-00.txt) > > Technical Summary > > The LoST protocol maps location and service identifiers to Uniform > Resource Identifiers (URIs). LoST may additionally return > a so-called service boundary, i.e., a region within which >all locations > map to the same service URI or set of URIs for a given service. > > The geodetic boundary is a polygon made up of sets of > geodetic coordinates specifying an enclosed area. In some > circumstances an area enclosed by a polygon, also known as an > exterior polygon, may contain exception areas, or holes, >that for the > same service must yield a different destination to that described by > the larger area. > > This document describes how holes should be specified in >service boundaries > defined using a GML encoding for the polygons and their >internal elements (holes). > > > Working Group Summary > > There is consensus in the WG to publish this document. > > Document Quality > > The document has been reviewed by ECRIT working group members > and feedback was provided by Carl Reed from the OGC. > > Personnel > > Hannes Tschofenig is the document shepherd for this document. >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 13 10:48:38 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20283A6AE0; Mon, 13 Oct 2008 10:48:38 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAE5928C118 for ; Mon, 13 Oct 2008 10:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3el0ACS1GxIt for ; Mon, 13 Oct 2008 10:48:28 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 9185E3A67D4 for ; Mon, 13 Oct 2008 10:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1223920163; x=1255456163; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20< C41BFCED3C088E40A8510B57B165C16291805C@FIESEXC007.nsn-int ra.net>|Date:=20Mon,=2013=20Oct=202008=2010:47:31=20-0700 |To:=20"Tschofenig,=20Hannes=20(NSN=20-=20FI/Espoo)"=20,=0D=0A=20=20=20=20=20=20=20=20E CRIT=0D=0A=09|From:=20Ted=20Hardie=20|Subject:=20Re:=20[Ecrit]=20PROTO=20Writ eup=20for=20=0D=0A=20draft-ietf-ecrit-location-hiding-req -01.txt|Content-Type:=20text/plain=3B=20charset=3D"us-asc ii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5403"=3B =20a=3D"10835500"; bh=6CqFCdaQVI/FCMNUFRQdtOylufeLei5C2qNJHy0rEX8=; b=l64g4/JPRGKA38T7ZC3A9iDvfHuy4lZTnmfbqmSUTbXR0yvRYPO/oPBc /4IDOF4QI0g4sUFLi7QQ8NDLfigjrbfufII3jK7Akx/WXgSh9tuUYrFri GqAvpPqAYQ09DeYuyd3mdwqU3JsEcPVUxLdS/Orz4ws/9OzgfCkFwhESD s=; X-IronPort-AV: E=McAfee;i="5300,2777,5403"; a="10835500" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Oct 2008 10:47:36 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9DHlZM3027571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2008 10:47:35 -0700 Received: from nasanexhc01.na.qualcomm.com (nasanexhc01.na.qualcomm.com [172.30.37.21]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9DHlXkN018220 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Oct 2008 10:47:35 -0700 (PDT) Received: from nasanexhub03.na.qualcomm.com (10.46.93.98) by nasanexhc01.na.qualcomm.com (172.30.37.21) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 13 Oct 2008 10:47:34 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 13 Oct 2008 10:47:33 -0700 Received: from [10.227.68.106] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 13 Oct 2008 10:47:33 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: Date: Mon, 13 Oct 2008 10:47:31 -0700 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , ECRIT From: Ted Hardie Subject: Re: [Ecrit] PROTO Writeup for draft-ietf-ecrit-location-hiding-req-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 12:44 PM -0700 10/12/08, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? > > There is consensus behind this document. This does not seem to match 1.f below. I believe that the consensus for this document has a strong rough patch in it: discussion has circled around: Req-A: There MUST be a way an access network can withhold detailed location information from any entity it wishes to, and specifically, the endpoint, and a VSP. over and over again. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarize the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) > > The topic of location hiding is controversal and lack of >excitement > surfaced in the ECRIT and the GEOPRIV working group. Key >working > group members have expressed a lot of concerns but seem to be > fine with the resulting requirements document. What does "lack of excitement mean here"? > > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/.) Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type, and URI type reviews? If the document > does not already indicate its intended status at the top of > the first page, please indicate the intended status here. > > The document does not contain nits. > > > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. > > > The document has references split into normative and > informative references. > > (1.i) Has the Document Shepherd verified that the document's IANA > Considerations section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process, has the Document > Shepherd conferred with the Responsible Area Director so that > the IESG can appoint the needed Expert during IESG Evaluation? > > An IANA consideration section exists but there are not actions for > IANA since this is a requirements document. > > > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? > > The document does not contain formal languages. > > > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. > > >Document Announcement Write-Up for "Location Hiding: Problem Statement >and Requirements" (draft-ietf-ecrit-location-hiding-req-01.txt) > > Technical Summary > > The emergency services architecture developed in the IETF Emergency > Context Resolution with Internet Technology (ECRIT) working group > describes an architecture where location information is provided by > access networks to end points or VoIP service providers in order to > determine the correct dial string and information to route the call > to a Public Safety Answering Point (PSAP). For determining the PSAP > Uniform Resource Identifier (URI) the usage of the Location-to- > Service Translation (LoST) Protocol is envisioned. > > This document provides a problem statement and lists requirements > for situations where the Internet Access Provider (IAP) and/or the > Internet Service Provider (ISP) are only willing to disclose > limited or no location information. > > Working Group Summary > > There is consensus in the WG to publish this document. > > Document Quality > > The document has been reviewed by ECRIT working group members > and feedback was provided by participants from various > emergency services workshops. > > Personnel > > Marc Linsner is the document shepherd for this document. > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 13 10:56:20 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E672928C17A; Mon, 13 Oct 2008 10:56:20 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51B728C167 for ; Mon, 13 Oct 2008 10:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.394 X-Spam-Level: X-Spam-Status: No, score=-105.394 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Qx1flyEsQjy for ; Mon, 13 Oct 2008 10:56:18 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id AD0F63A6ADF for ; Mon, 13 Oct 2008 10:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1223920633; x=1255456633; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20< C41BFCED3C088E40A8510B57B165C162917F85@FIESEXC007.nsn-int ra.net>|Date:=20Mon,=2013=20Oct=202008=2010:55:58=20-0700 |To:=20"Tschofenig,=20Hannes=20(NSN=20-=20FI/Espoo)"=20,=0D=0A=20=20=20=20=20=20=20=20" nena-i2_5@listserv.neustar.biz"=20,=0D=0A=20=20=20=20=20=20=20=20"nena-ltd@lists.c s.columbia.edu"=20,=0D=0A =20=20=20=20=20=20=20=20ECRIT=0D=0A=09 |From:=20Ted=20Hardie=20|Subject:=20 Re:=20[Ecrit]=20Design=20Team=20Status=20Update |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5403"=3B=20 a=3D"10911088"; bh=MlwafDs7mev2kY2SsHEGQL8CBMlQYGQfiAeGlzIPwBs=; b=qOs30Iq/aPueFgqR3t9uPRqpHF7nutm+3kEcm3Opa9WiINLSKt7CgAT/ okSsU6A8/jzMbUp7qy9bqcNYYDJRo65Fia8rfJbArmHkIO2xhcgpg3pT0 9/FssMy4MsuxIxl98bOwnsOgeBaC7Woy3t24hf2WIwBNXkuVGKsYFwCPu k=; X-IronPort-AV: E=McAfee;i="5300,2777,5403"; a="10911088" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Oct 2008 10:56:02 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9DHu2bm011407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2008 10:56:02 -0700 Received: from nasanexhc01.na.qualcomm.com (nasanexhc01.na.qualcomm.com [172.30.37.21]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9DHtxZX016284 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Oct 2008 10:56:00 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhc01.na.qualcomm.com (172.30.37.21) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 13 Oct 2008 10:55:59 -0700 Received: from [10.227.68.106] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 13 Oct 2008 10:55:58 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: Date: Mon, 13 Oct 2008 10:55:58 -0700 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "nena-i2_5@listserv.neustar.biz" , "nena-ltd@lists.cs.columbia.edu" , ECRIT From: Ted Hardie Subject: Re: [Ecrit] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 2:00 AM -0700 10/12/08, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >Hi all, > >so far, we have the following persons on the design team but a few >responses are still pending: > >* Guy Caron (g.caron at bell.ca) >* James Polk (jmpolk at cisco.com) >* Ted Hardie (hardie at qualcomm.com) Apparently, my private message to you didn't get through, so I will say this publicly. I do not support the creation of a design team at this stage. The whole working group should be involved in the discussion of these requirements, at least in my opinion, and the re-use of the ECRIT mailing list for discussion would tend to support anyone who was interested making comments. Why, in that context, are you forming a design team at all? We should also be really clear on what the target is. The desires being expressed would likely result in mechanisms which would be used in some jurisdictions or network contexts, but not all jurisdictions and network contexts. It will not, in other words, result in a "best current practice". At most, it will result in a "for jurisdictions where X is required by regulators or desired by PSAPs, the best available mechanism is Y". Especially because of the initial "this could get folded into the BCP, even at a late stage" discussion, I think this requires pretty clear language now. Ted >* Henning Schulzrinne (hgs at cs.columbia.edu) >* Keith Drage (drage at alcatel-lucent.com) >* Brian Rosen (Brian.Rosen at neustar.biz) >* Theresa Reese (treese at telcordia.com) > >The design team is lead by the working group chairs: Marc Linsner and >Hannes Tschofenig > >The rules for design teams are described in >http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt > >We thought that we could re-use our IETF ECRIT mailing list for >discussions rather than creating a separate list. >Let's see how that works out. > >>From a procedural point of view we would start with reviewing Brian's >draft: >http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnect-rqmts-00 >.txt > >Marc, for example, recently provided a few review comments: >http://www.ietf.org/mail-archive/web/ecrit/current/msg05511.html > >There are some other review comments from the previous IETF meeting, see > >http://www.ietf.org/mail-archive/web/ecrit/current/msg05450.html >http://www.ietf.org/mail-archive/web/ecrit/current/msg05447.html > >If necessary, we will schedule phone conference calls. > >The initial goal is to agree on some of the requirements. > >At IETF#73 a status update will be given. Then, we will determine the >next steps. > >Ciao >Hannes & Marc >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 13 11:12:08 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DBA93A68E3; Mon, 13 Oct 2008 11:12:08 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AFE13A68E3 for ; Mon, 13 Oct 2008 11:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[AWL=1.368, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsjwDVcGtRW0 for ; Mon, 13 Oct 2008 11:12:05 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id CDBFF3A6820 for ; Mon, 13 Oct 2008 11:12:04 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9DICHTC004703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 13 Oct 2008 20:12:17 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9DICEvw005798 for ; Mon, 13 Oct 2008 20:12:17 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Oct 2008 20:11:13 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Oct 2008 20:11:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 21:11:12 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-lost-sync-00.txt Thread-Index: AcktXl/6VmIBb+viS/igfAOzpPRR2g== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 13 Oct 2008 18:11:12.0746 (UTC) FILETIME=[136774A0:01C92D5F] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081013201217-40306BB0-A8A51C19/0-0/0-15 X-purgate-size: 9297/0 Subject: [Ecrit] draft-ietf-ecrit-lost-sync-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, I went through draft-ietf-ecrit-lost-sync-00.txt. I believe that only two interactions are needed, namely * pushMappingsRequest/ pushMappingsResponse * getMappingsRequest / getMappingsResponse I modified the content of these messages slightly and here is the Relax NG schema and also instance documents. I would like to thank Jari Urpalainen for his feedback on the Relax NG schema. -------------- Relax NG Schema ----------------- Location-to-Service Translation (LoST) Synchronization Protocol -------------------------------------- A "minor" thing to add with this schema is that it is not forwards compatible with the LoST Relax NG schema. The reason for this is the fact that we did not define an extension point at the top level LoST Relax NG schema. ------------ Example - 1 -------------------------- Leonia Police Department urn:service:sos.police US NJ Leonia 07605 sip:police@leonianj.example.org 911 New York City Police Department urn:service:sos.police 37.775 -122.4194 37.555 -122.4194 37.555 -122.4264 37.775 -122.4264 37.775 -122.4194 sip:nypd@example.com xmpp:nypd@example.com 911 ----------------------------------- ------------ Example - 2 -------------------------- ----------------------------------- ------------ Example - 3 -------------------------- ----------------------------------- ------------ Example - 4 -------------------------- Leonia Police Department urn:service:sos.police US NJ Leonia 07605 sip:police@leonianj.example.org 911 New York City Police Department urn:service:sos.police 37.775 -122.4194 37.555 -122.4194 37.555 -122.4264 37.775 -122.4264 37.775 -122.4194 sip:nypd@example.com xmpp:nypd@example.com 911 ----------------------------------- Todo: * I need to play a bit with error messages as well. * Write text around the schema and the examples. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 13 12:07:27 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C143A6806; Mon, 13 Oct 2008 12:07:27 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6C3B3A6806 for ; Mon, 13 Oct 2008 12:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=-0.673, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik8SM4tybOKP for ; Mon, 13 Oct 2008 12:07:23 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 490733A67F3 for ; Mon, 13 Oct 2008 12:07:23 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9DJ75YH005277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2008 21:07:05 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9DJ72Vt021462; Mon, 13 Oct 2008 21:07:05 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Oct 2008 21:07:03 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Oct 2008 21:07:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 22:07:00 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Design Team Status Update Thread-Index: AcktXPg44ZFU8wWQQvi+e4tU3uakgAACRaqw References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Ted Hardie" , , , "ECRIT" X-OriginalArrivalTime: 13 Oct 2008 19:07:03.0035 (UTC) FILETIME=[E054FCB0:01C92D66] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081013210705-73811BB0-83376C2E/0-0/0-15 X-purgate-size: 3871/0 Subject: Re: [Ecrit] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Ted, >At 2:00 AM -0700 10/12/08, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>Hi all, >> >>so far, we have the following persons on the design team but a few >>responses are still pending: >> >>* Guy Caron (g.caron at bell.ca) >>* James Polk (jmpolk at cisco.com) >>* Ted Hardie (hardie at qualcomm.com) > >Apparently, my private message to you didn't get through, so I >will say this publicly. I indeed did not see your message. > I do not support the creation of a >design team at this stage. The whole working group should be >involved in the discussion of these requirements, at least in >my opinion, and the re-use of the ECRIT mailing list for >discussion would tend to support anyone who was interested >making comments. >Why, in that context, are you forming a design team at all? I want to make quick progress. The design team interestingly enough gives me the possibility todo so (from my experience). Additionally, I can schedule phone conferences on a very short notice. Also a very powerful mechanism to make sure that we agree on things (or to determine on what we disagree). > >We should also be really clear on what the target is. The >desires being expressed would likely result in mechanisms >which would be used in some jurisdictions or network contexts, >but not all jurisdictions and network contexts. It will not, >in other words, result in a "best current practice". At most, >it will result in a "for jurisdictions where X is required by >regulators or desired by PSAPs, the best available mechanism >is Y". Especially because of the initial "this could get >folded into the BCP, even at a late stage" >discussion, I think this requires pretty clear language now. Regarding the document type: I am not sure BCP is the right document type for the "Phone BCP document" depending on your view of what a BCP should contain. My initial target is to figure out whether the requirements make sense. What todo with the outcome later is hard to tell but I also want to make sure that we FINALLY finish the Phone BCP/Framework document since folks are already implementing their emergency services code and they are looking at an unfinished document that gets postponed all the time. Ciao Hannes > > > Ted > > >>* Henning Schulzrinne (hgs at cs.columbia.edu) >>* Keith Drage (drage at alcatel-lucent.com) >>* Brian Rosen (Brian.Rosen at neustar.biz) >>* Theresa Reese (treese at telcordia.com) >> >>The design team is lead by the working group chairs: Marc Linsner and >>Hannes Tschofenig >> >>The rules for design teams are described in >>http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt >> >>We thought that we could re-use our IETF ECRIT mailing list for >>discussions rather than creating a separate list. >>Let's see how that works out. >> >>>From a procedural point of view we would start with reviewing Brian's >>draft: >>http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnec >t-rqmts-0 >>0 >>.txt >> >>Marc, for example, recently provided a few review comments: >>http://www.ietf.org/mail-archive/web/ecrit/current/msg05511.html >> >>There are some other review comments from the previous IETF meeting, >>see >> >>http://www.ietf.org/mail-archive/web/ecrit/current/msg05450.html >>http://www.ietf.org/mail-archive/web/ecrit/current/msg05447.html >> >>If necessary, we will schedule phone conference calls. >> >>The initial goal is to agree on some of the requirements. >> >>At IETF#73 a status update will be given. Then, we will determine the >>next steps. >> >>Ciao >>Hannes & Marc >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 13 12:14:55 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D9CC3A6AF4; Mon, 13 Oct 2008 12:14:55 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755F93A68AA for ; Mon, 13 Oct 2008 12:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bh2O7X6+5PK for ; Mon, 13 Oct 2008 12:14:52 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 5C5483A6B10 for ; Mon, 13 Oct 2008 12:14:52 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9DJFRZK016025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2008 21:15:27 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9DJFPoj016398; Mon, 13 Oct 2008 21:15:25 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Oct 2008 21:15:22 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Oct 2008 21:15:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 22:15:19 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PROTO Writeup for draft-ietf-ecrit-location-hiding-req-01.txt Thread-Index: AcktW864kd7mKUiFQbWBwAgHjG+fmAACyozQ References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Ted Hardie" , "ECRIT" X-OriginalArrivalTime: 13 Oct 2008 19:15:22.0132 (UTC) FILETIME=[09D12540:01C92D68] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081013211527-73811BB0-53554380/0-0/0-15 X-purgate-size: 1759/0 Subject: Re: [Ecrit] PROTO Writeup for draft-ietf-ecrit-location-hiding-req-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Ted, Thanks for your quick feedback: >At 12:44 PM -0700 10/12/08, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> >> (1.e) How solid is the WG consensus behind this document? Does it >> represent the strong concurrence of a few individuals, with >> others being silent, or does the WG as a whole >understand and >> agree with it? >> >> There is consensus behind this document. > >This does not seem to match 1.f below. I believe that the >consensus for this document has a strong rough patch in it: >discussion has circled around: > > Req-A: There MUST be a way an access network can withhold detailed > location information from any entity it wishes to, and > specifically, the endpoint, and a VSP. > >over and over again. Do you want me to say it in this way? > > >> (1.f) Has anyone threatened an appeal or otherwise >indicated extreme >> discontent? If so, please summarize the areas of >conflict in >> separate email messages to the Responsible Area >Director. (It >> should be in a separate email because this questionnaire is >> entered into the ID Tracker.) >> >> The topic of location hiding is controversal and lack of >>excitement >> surfaced in the ECRIT and the GEOPRIV working group. Key >>working >> group members have expressed a lot of concerns but >seem to be >> fine with the resulting requirements document. > > >What does "lack of excitement mean here"? When I wrote this I already thought that someone would be complaining but I liked the phrase. How would you rephrase this paragraph? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 13 17:44:02 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A8D33A6A4A; Mon, 13 Oct 2008 17:44:02 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BAA128C152 for ; Mon, 13 Oct 2008 17:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwHvJzszBebX for ; Mon, 13 Oct 2008 17:44:00 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 6329B3A6A3E for ; Mon, 13 Oct 2008 17:43:59 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m9E0igcP024473; Mon, 13 Oct 2008 19:44:42 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 19:44:41 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 02:44:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 02:44:38 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180023E961A@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Design Team Status Update Thread-Index: AcktXSpdxMqbYmk7QGWWVIcI06DIDAAOJljQ References: From: "DRAGE, Keith \(Keith\)" To: "Ted Hardie" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , , , "ECRIT" X-OriginalArrivalTime: 14 Oct 2008 00:44:40.0193 (UTC) FILETIME=[0A89FF10:01C92D96] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [Ecrit] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I was happy for the design team to do a round of tidying up the requirements and making sure that they were understandable and precise and motivated - which they are not currently not in my view. I agree that once that has been done, the WG has to decide whether those requirements (or some of them) have consensus for further work - before any specification work starts based on those requirements. Regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Ted Hardie > Sent: Monday, October 13, 2008 6:56 PM > To: Tschofenig, Hannes (NSN - FI/Espoo); > nena-i2_5@listserv.neustar.biz; nena-ltd@lists.cs.columbia.edu; ECRIT > Subject: Re: [Ecrit] Design Team Status Update > > At 2:00 AM -0700 10/12/08, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >Hi all, > > > >so far, we have the following persons on the design team but a few > >responses are still pending: > > > >* Guy Caron (g.caron at bell.ca) > >* James Polk (jmpolk at cisco.com) > >* Ted Hardie (hardie at qualcomm.com) > > Apparently, my private message to you didn't get through, so > I will say this publicly. I do not support the creation of a > design team at this stage. The whole working group should be > involved in the discussion of these requirements, at least in > my opinion, and the re-use of the ECRIT mailing list for > discussion would tend to support anyone who was interested > making comments. > Why, in that context, are you forming a design team at all? > > We should also be really clear on what the target is. The > desires being expressed would likely result in mechanisms > which would be used in some jurisdictions or network > contexts, but not all jurisdictions and network contexts. It > will not, in other words, result in a "best current > practice". At most, it will result in a "for jurisdictions > where X is required by regulators or desired by PSAPs, the > best available mechanism is Y". Especially because of the > initial "this could get folded into the BCP, even at a late stage" > discussion, I think this requires pretty clear language now. > > > Ted > > > >* Henning Schulzrinne (hgs at cs.columbia.edu) > >* Keith Drage (drage at alcatel-lucent.com) > >* Brian Rosen (Brian.Rosen at neustar.biz) > >* Theresa Reese (treese at telcordia.com) > > > >The design team is lead by the working group chairs: Marc > Linsner and > >Hannes Tschofenig > > > >The rules for design teams are described in > >http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt > > > >We thought that we could re-use our IETF ECRIT mailing list for > >discussions rather than creating a separate list. > >Let's see how that works out. > > > >>From a procedural point of view we would start with > reviewing Brian's > >draft: > >http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconne > ct-rqmts-0 > >0 > >.txt > > > >Marc, for example, recently provided a few review comments: > >http://www.ietf.org/mail-archive/web/ecrit/current/msg05511.html > > > >There are some other review comments from the previous IETF meeting, > >see > > > >http://www.ietf.org/mail-archive/web/ecrit/current/msg05450.html > >http://www.ietf.org/mail-archive/web/ecrit/current/msg05447.html > > > >If necessary, we will schedule phone conference calls. > > > >The initial goal is to agree on some of the requirements. > > > >At IETF#73 a status update will be given. Then, we will > determine the > >next steps. > > > >Ciao > >Hannes & Marc > >_______________________________________________ > >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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 13 18:25:27 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFED028C15A; Mon, 13 Oct 2008 18:25:27 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD1028C1A1 for ; Mon, 13 Oct 2008 18:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3M-8h6AP5I6 for ; Mon, 13 Oct 2008 18:25:14 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B30F43A6A4A for ; Mon, 13 Oct 2008 18:25:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,406,1220227200"; d="scan'208";a="94818595" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 14 Oct 2008 01:26:05 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9E1Q5E7016358; Mon, 13 Oct 2008 18:26:05 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m9E1Q5Tv018355; Tue, 14 Oct 2008 01:26:05 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 18:26:04 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.114.154]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 18:26:04 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Oct 2008 20:26:22 -0500 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Ted Hardie" , , , "ECRIT" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 14 Oct 2008 01:26:04.0320 (UTC) FILETIME=[D331B200:01C92D9B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7463; t=1223947565; x=1224811565; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Design=20Team=20Status=20Upda te |Sender:=20; bh=0H98OIKBDnvYRXkpxzUdwLH44XacDcmfHx8cqBJZaxg=; b=gGfiZZhq1UCzGWEfkDH0TrVu4cyIP5tRZtycWnvJdvz5MlfF6ly0ARavMg zYx8g1jLyEg5JCk5MPSe5o+O/dCByLw3eDF6wANICd7n9RUxe6cf8hyL0Q+a 2cGMVDY4gou1GpzxvDfLTgqzMdfvgPxkzn6C5Fn8Er67zaeKovZsU=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 02:07 PM 10/13/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >Hi Ted, > > > >At 2:00 AM -0700 10/12/08, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >>Hi all, > >> > >>so far, we have the following persons on the design team but a few > >>responses are still pending: > >> > >>* Guy Caron (g.caron at bell.ca) > >>* James Polk (jmpolk at cisco.com) > >>* Ted Hardie (hardie at qualcomm.com) > > > >Apparently, my private message to you didn't get through, so I > >will say this publicly. > >I indeed did not see your message. > > > > I do not support the creation of a > >design team at this stage. The whole working group should be > >involved in the discussion of these requirements, at least in > >my opinion, and the re-use of the ECRIT mailing list for > >discussion would tend to support anyone who was interested > >making comments. > >Why, in that context, are you forming a design team at all? > >I want to make quick progress. If time is a factor, or goal, then putting whatever comes from this design team into a post WGLC doc shouldn't also be a goal. This topic is not properly defined, thus it is not known how long it will be until it is in good/mature form to put into an RFC. Therefore I don't believe this should go into the PhoneBCP doc at all; especially if you really want the PhoneBCP to be done. >The design team interestingly enough >gives me the possibility todo so (from my experience). I'd be curious if you have examples of when a design team has finished work as fast as you want, when the point of the design team is to finish one very small aspect of a larger effort? Seems to me that design teams are targeted mostly at topics that will become the main point of a complete doc... >Additionally, I can schedule phone conferences on a very short notice. You can, but given that it is now just 2 weeks until -00 cutoff, some of us might have the flexibility to have these calls are a moment's notice. >Also a very powerful mechanism to make sure that we agree on things (or >to determine on what we disagree). As an observation - I believe you have more people disagreeing that agreeing (on this topic) at this moment in time. Ultimately, you want to overcome implementer's universal mode of disconnecting (or removing) state awareness once a UA has sent a BYE when this is not proper SIP procedures. SIP procedures are to wait for the response before releasing the state of the call. If proper procedures were followed, none of this would be an issue, because the BYE would merely need to be refused with a 488 (Not Acceptable Here) to address this. Any solution is going to look redundant within SIP rules, which is in itself creating a broken solution. > > > >We should also be really clear on what the target is. we NEED to be clear if there is a target that is acceptable here, first IMO. >The > >desires being expressed would likely result in mechanisms > >which would be used in some jurisdictions or network contexts, > >but not all jurisdictions and network contexts. It will not, > >in other words, result in a "best current practice". At most, > >it will result in a "for jurisdictions where X is required by > >regulators or desired by PSAPs, the best available mechanism > >is Y". Especially because of the initial "this could get > >folded into the BCP, even at a late stage" > >discussion, I think this requires pretty clear language now. > >Regarding the document type: I am not sure BCP is the right document >type for the "Phone BCP document" depending on your view of what a BCP >should contain. > >My initial target is to figure out whether the requirements make sense. ... yet you don't seem to want to take the time to have this process work itself out, but instead want to rush this whole thing along... which I also question (like Ted does). >What todo with the outcome later is hard to tell but I also want to make >sure that we FINALLY finish the Phone BCP/Framework document Finally finishing the Phone BCP/Framework documents means writing them in a way that follows existing SIP protocol procedures (which refusing the BYE mandates we specify, and nothing further). That reality of implementers not waiting for the response to the BYEs doesn't mean we state anything different, or invent anything different. We just emphasize that this function within SIP needs to be implemented as RFC 3261 states it should be. I cannot believe either the Phone BCP or Framework documents will get by the RAI AD review without merely stating what already exists within SIP, much less by the IESG - the fact that implementers are ignoring 3261 functions - and this one is a basic one... >since folks >are already implementing their emergency services code and they are >looking at an unfinished document that gets postponed all the time. These folks then should be implementing what 3261 mandates first and foremost, then implementing what is in both the Phone BCP/Framework documents to achieve good implementations of emergency services. Anything else flies of the face of what the IETF is all about (IMO)... James BTW - Hannes, having this design team discussion on the ECRIT mail list means there really isn't a design team, since anyone that's on the ECRIT mailing list can respond, therefore any discussion is not limited to the number of folks on the design team... I'm wondering why there needs to be a design team in the first place - oh yeah, Ted already said that. In that case, I second Ted's concerns about this ;-) >Ciao >Hannes > > > > > > > Ted > > > > > >>* Henning Schulzrinne (hgs at cs.columbia.edu) > >>* Keith Drage (drage at alcatel-lucent.com) > >>* Brian Rosen (Brian.Rosen at neustar.biz) > >>* Theresa Reese (treese at telcordia.com) > >> > >>The design team is lead by the working group chairs: Marc Linsner and > >>Hannes Tschofenig > >> > >>The rules for design teams are described in > >>http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt > >> > >>We thought that we could re-use our IETF ECRIT mailing list for > >>discussions rather than creating a separate list. > >>Let's see how that works out. > >> > >>>From a procedural point of view we would start with reviewing Brian's > >>draft: > >>http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnec > >t-rqmts-0 > >>0 > >>.txt > >> > >>Marc, for example, recently provided a few review comments: > >>http://www.ietf.org/mail-archive/web/ecrit/current/msg05511.html > >> > >>There are some other review comments from the previous IETF meeting, > >>see > >> > >>http://www.ietf.org/mail-archive/web/ecrit/current/msg05450.html > >>http://www.ietf.org/mail-archive/web/ecrit/current/msg05447.html > >> > >>If necessary, we will schedule phone conference calls. > >> > >>The initial goal is to agree on some of the requirements. > >> > >>At IETF#73 a status update will be given. Then, we will determine the > >>next steps. > >> > >>Ciao > >>Hannes & Marc > >>_______________________________________________ > >>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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 13 21:20:07 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2EFD3A69A8; Mon, 13 Oct 2008 21:20:07 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FAD63A69A8 for ; Mon, 13 Oct 2008 21:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftCAwe4Vh-Op for ; Mon, 13 Oct 2008 21:20:05 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 54AC13A67E7 for ; Mon, 13 Oct 2008 21:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1223958061; x=1255494061; h=message-id:in-reply-to:references:x-mailer: x-message-flag:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20|References:=20=0D=0A=20=0D=0A=20=0D=0A=20 |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|X-message-flag: =20Warning:=20Outlook=20in=20use.=20=20Upgrade=20to=20Eud ora:=20|Date:=20Mon,=2013=20Oct=20 2008=2021:18:27=20-0700|To:=20"James=20M.=20Polk"=20,=0D=0A=20=20=20=20=20=20=20=20"Tschofenig, =20Hannes=20(NSN=20-=20FI/Espoo)"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20ext=20Ted=20Ha rdie=20,=20,=0D=0A=20=20=20=20=20=20=20=20,=20ECRIT=0D=0A=09|From:=20R andall=20Gellens=20|Subject:=20Re:=20 [NENA-ltd]=20[Ecrit]=20Design=20Team=20Status=20Update |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,54 04"=3B=20a=3D"10853186"; bh=XXOPc38xUAE1LqKQBqGeNSVoP7DwZc1C14/kAZHKZlc=; b=Lfa/2fLfNoA7wQk8A2elLVNJkVCFIKNy9piiOMWhxEfVCGG5FrfTcF8e Ge70V9nw9kWKRa1tvUu3BmrvVR3FxEghz7099eiOJyWQQau8K2KeJM/zO BJXqWKf18TnpVl0+PfUjFzT1C1Gh69hhdx4M5CdnC/m2deruPuEibJhx7 Q=; X-IronPort-AV: E=McAfee;i="5300,2777,5404"; a="10853186" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Oct 2008 21:20:10 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9E4KAEv029017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2008 21:20:10 -0700 Received: from nasanexhc01.na.qualcomm.com (nasanexhc01.na.qualcomm.com [172.30.37.21]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9E4K5WR010597 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Oct 2008 21:20:05 -0700 Received: from nasanexhub03.na.qualcomm.com (10.46.93.98) by nasanexhc01.na.qualcomm.com (172.30.37.21) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 13 Oct 2008 21:20:05 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 13 Oct 2008 21:20:04 -0700 Received: from [192.168.1.13] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 13 Oct 2008 21:20:03 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 13 Oct 2008 21:18:27 -0700 To: "James M. Polk" , "Tschofenig, Hannes (NSN - FI/Espoo)" , ext Ted Hardie , , , ECRIT From: Randall Gellens MIME-Version: 1.0 X-Random-Sig-Tag: 1.0b28 Subject: Re: [Ecrit] [NENA-ltd] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 8:26 PM -0500 10/13/08, James M. Polk wrote: > Finally finishing the Phone BCP/Framework documents means writing > them in a way that follows existing SIP protocol procedures (which > refusing the BYE mandates we specify, and nothing further). > > That reality of implementers not waiting for the response to the BYEs > doesn't mean we state anything different, or invent anything > different. We just emphasize that this function within SIP needs to > be implemented as RFC 3261 states it should be. > > I cannot believe either the Phone BCP or Framework documents will get > by the RAI AD review without merely stating what already exists > within SIP, much less by the IESG - the fact that implementers are > ignoring 3261 functions - and this one is a basic one... Can a BCP change a widespread situation where implementers ignore what the spec says? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- In the United States the majority undertakes to supply a multitude of ready-made opinions for the use of individuals, who are thus relieved from the necessity of forming opinions of their own --Alexis de Tocqueville _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 13 22:48:39 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 460833A6BE5; Mon, 13 Oct 2008 22:48:39 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC8128C0F3 for ; Mon, 13 Oct 2008 22:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.234 X-Spam-Level: X-Spam-Status: No, score=-3.234 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0K8KT9xE1FMU for ; Mon, 13 Oct 2008 22:48:36 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 03C053A6BDE for ; Mon, 13 Oct 2008 22:48:35 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9E5mpsS024920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Oct 2008 07:48:51 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9E5moIh006760; Tue, 14 Oct 2008 07:48:50 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 07:48:33 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 07:48:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 08:48:31 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Design Team Status Update Thread-Index: Acktm9iywhdjIBSpTiC+KhUcwLEpxwAHmbfw References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext James M. Polk" , "ext Ted Hardie" , , , "ECRIT" X-OriginalArrivalTime: 14 Oct 2008 05:48:32.0771 (UTC) FILETIME=[7E009D30:01C92DC0] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081014074851-73813BB0-D42950C4/0-0/0-15 X-purgate-size: 10359/0 Subject: Re: [Ecrit] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi James, >If time is a factor, or goal, then putting whatever comes from >this design team into a post WGLC doc shouldn't also be a goal. It is probably a bit early to say whether we can put it into the document or not. That heavily depends on what the outcome of it is. Hard to tell right now. Remember that the entire discussion started with a sentence in the Phone BCP document that triggered a discussion in NENA. Here is the relevant paragraph and the sentence: 12. Call termination ED-68 UACs with an active emergency call (i.e. SIP Dialog) MUST NOT generate a BYE request (or equivalent for other non-SIP signaling). The PSAP must be the only entity that can terminate a call. If the user "hangs up" an emergency call, the device should alert the user, and if the user responds by attempting to pick up the call, the device MUST reconnect the caller to the PSAP. > >This topic is not properly defined, thus it is not known how >long it will be until it is in good/mature form to put into an >RFC. Therefore I don't believe this should go into the >PhoneBCP doc at all; especially if you really want the >PhoneBCP to be done. It is true that it is somewhat hard to estimate the time it takes and I explicitly mentioned the option of not putting the eventual outcome into phone BCP. Currently, "a solution" is already in the phone BCP document, as mentioned above. > >>The design team interestingly enough >>gives me the possibility todo so (from my experience). > >I'd be curious if you have examples of when a design team has >finished work as fast as you want, when the point of the >design team is to finish one very small aspect of a larger effort? Well. The GEOPRIV design teams are obviously not super good examples. However, I was quite happy about a recent design team I started on Diameter extensibility (in DIME). We had a difficult problem to tackle. The DT ran for a few months; we had a number of phone conferences and we got it done. It obviously depends a lot on the members of the design team... > >Seems to me that design teams are targeted mostly at topics >that will become the main point of a complete doc... In the example I mentioned above the outcome was a short description on a Wiki: http://trac.tools.ietf.org/wg/dime/trac/wiki/DiameterExtensibility The text was then folded into another document. > >>Additionally, I can schedule phone conferences on a very short notice. > >You can, but given that it is now just 2 weeks until -00 >cutoff, some of us might have the flexibility to have these >calls are a moment's notice. We don't need to get a document published for the submission deadline. I am already happy if we can put a presentation together for the next IETF meeting. Marc and I naively requested only a short slot in the believe that our work would largely be done already.... > >>Also a very powerful mechanism to make sure that we agree on >things (or >>to determine on what we disagree). > >As an observation - I believe you have more people disagreeing >that agreeing (on this topic) at this moment in time. It depends on the group of people you talk to. NENA members are, unfortunately, a bit shy when it comes to post mails to the ECRIT list and hence they are often not heard. But, we are working on this. In any case, I got the impression that we don't have a common understanding. Hence, we have to clarify the problem statement and flesh out the requirements a bit better. > >Ultimately, you want to overcome implementer's universal mode >of disconnecting (or removing) state awareness once a UA has >sent a BYE when this is not proper SIP procedures. SIP >procedures are to wait for the response before releasing the >state of the call. If proper procedures were followed, none >of this would be an issue, because the BYE would merely need >to be refused with a 488 (Not Acceptable Here) to address this. Too early for solution discussions. > >Any solution is going to look redundant within SIP rules, >which is in itself creating a broken solution. > > >> > >> >We should also be really clear on what the target is. > >we NEED to be clear if there is a target that is acceptable >here, first IMO. That's why I suggested to disuss the requirements first. > >>The >> >desires being expressed would likely result in mechanisms >> >which would be used in some jurisdictions or network contexts, >> >but not all jurisdictions and network contexts. It will not, >> >in other words, result in a "best current practice". At most, >> >it will result in a "for jurisdictions where X is required by >> >regulators or desired by PSAPs, the best available mechanism >> >is Y". Especially because of the initial "this could get >> >folded into the BCP, even at a late stage" >> >discussion, I think this requires pretty clear language now. >> >>Regarding the document type: I am not sure BCP is the right document >>type for the "Phone BCP document" depending on your view of what a BCP >>should contain. >> >>My initial target is to figure out whether the requirements >make sense. > >... yet you don't seem to want to take the time to have this process >work itself out, but instead want to rush this whole thing along... >which I also question (like Ted does). I am not sure what you mean by "have this process work itself out". Regarding "I want to rush": Clearly, I want to finish the WG deliverables. I wouldn't call this "a rush" given that they should have been finished a long time ago. I also want to close the open issues. If you look on the mailing list then you will notice that there is silence after the Dublin IETF meeting (as it usually happens after IETF meetings) since everyone is busy with other stuff etc. Wakeing folks up took a bit longer this time. Posting the announcement of a design team formation has helped a lot to get your attention. > >>What todo with the outcome later is hard to tell but I also >want to make >>sure that we FINALLY finish the Phone BCP/Framework document > >Finally finishing the Phone BCP/Framework documents means writing >them in a way that follows existing SIP protocol procedures (which >refusing the BYE mandates we specify, and nothing further). Correct. > >That reality of implementers not waiting for the response to the BYEs >doesn't mean we state anything different, or invent anything >different. We just emphasize that this function within SIP needs to >be implemented as RFC 3261 states it should be. > >I cannot believe either the Phone BCP or Framework documents will get >by the RAI AD review without merely stating what already exists >within SIP, much less by the IESG - the fact that implementers are >ignoring 3261 functions - and this one is a basic one... > >>since folks >>are already implementing their emergency services code and they are >>looking at an unfinished document that gets postponed all the time. > >These folks then should be implementing what 3261 mandates first and >foremost, then implementing what is in both the Phone BCP/Framework >documents to achieve good implementations of emergency >services. Anything else flies of the face of what the IETF is all >about (IMO)... Thanks for sharing your view. So, if you look at the current Phone BCP: * Do you think that the current text is fine? * If you look at Brian's requirements draft do you understand all the requirements? If not, which onces do you not understand? > >James > >BTW - Hannes, having this design team discussion on the ECRIT mail >list means there really isn't a design team, since anyone that's on >the ECRIT mailing list can respond, therefore any discussion is not >limited to the number of folks on the design team... I'm wondering >why there needs to be a design team in the first place - oh yeah, Ted >already said that. In that case, I second Ted's concerns >about this ;-) The mailing list thing was just an idea. Maybe we should setup a separate mailing list --- not a big issue either. I am still collecting a few folks for the design team ... Ciao Hannes > >>Ciao >>Hannes >> >> > >> > >> > Ted >> > >> > >> >>* Henning Schulzrinne (hgs at cs.columbia.edu) >> >>* Keith Drage (drage at alcatel-lucent.com) >> >>* Brian Rosen (Brian.Rosen at neustar.biz) >> >>* Theresa Reese (treese at telcordia.com) >> >> >> >>The design team is lead by the working group chairs: Marc >Linsner and >> >>Hannes Tschofenig >> >> >> >>The rules for design teams are described in >> >>http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt >> >> >> >>We thought that we could re-use our IETF ECRIT mailing list for >> >>discussions rather than creating a separate list. >> >>Let's see how that works out. >> >> >> >>>From a procedural point of view we would start with >reviewing Brian's >> >>draft: >> >>http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnec >> >t-rqmts-0 >> >>0 >> >>.txt >> >> >> >>Marc, for example, recently provided a few review comments: >> >>http://www.ietf.org/mail-archive/web/ecrit/current/msg05511.html >> >> >> >>There are some other review comments from the previous >IETF meeting, >> >>see >> >> >> >>http://www.ietf.org/mail-archive/web/ecrit/current/msg05450.html >> >>http://www.ietf.org/mail-archive/web/ecrit/current/msg05447.html >> >> >> >>If necessary, we will schedule phone conference calls. >> >> >> >>The initial goal is to agree on some of the requirements. >> >> >> >>At IETF#73 a status update will be given. Then, we will >determine the >> >>next steps. >> >> >> >>Ciao >> >>Hannes & Marc >> >>_______________________________________________ >> >>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 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 13 23:13:28 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B363A6BE5; Mon, 13 Oct 2008 23:13:28 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB85B3A6BDA for ; Mon, 13 Oct 2008 23:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O75xWcDXG0Yw for ; Mon, 13 Oct 2008 23:13:25 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 996023A6BE5 for ; Mon, 13 Oct 2008 23:13:25 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9E6DX0l005791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Oct 2008 08:13:33 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9E6DVXI010944 for ; Tue, 14 Oct 2008 08:13:33 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 08:13:28 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 08:13:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 09:13:27 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT WG Rechartering Thread-Index: Acktw/kVlLQxiY3lTfSfqPNWoZdlxA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 14 Oct 2008 06:13:28.0820 (UTC) FILETIME=[F9B79340:01C92DC3] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081014081333-73810BB0-7D5DC193/0-0/0-15 X-purgate-size: 4607/0 Subject: [Ecrit] ECRIT WG Rechartering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Here is a first proposal for the ECRIT WG rechartering based on the discussions we had around IETF#72. For the moment, I have put 3 additional documents onto the charter: http://tools.ietf.org/id/draft-polk-ecrit-local-emergency-rph-namespace- 03.txt http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc-00.txt http://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00.txt Regarding the following two documents http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.txt http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-00.txt I am waiting for additional feedback from the draft authors on how they perceive these documents should be progressed through the IETF, see my mail here: http://www.ietf.org/mail-archive/web/ecrit/current/msg05518.html Please take a look at it and give me feedback till the 21st October 2008. ------------------------------------------------------------------------ --------------------------- Emergency Context Resolution with Internet Technologies (ecrit) Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (commonly one that is short and easily memorized) as a call for emergency services. These numbers (e.g. 911, 112) relate to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained context of service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires both an association of the physical location of the originator with an appropriate emergency service center and call routing to deliver the call to the center. Calls placed using Internet technologies do not use the same systems to achieve those goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting them more challenging. There are, however, Internet technologies available to describe location and to manage call routing. This working group will describe when these may be appropriate and how they may be used. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. While this group anticipates a close working relationship with groups such as NENA and ETSI EMTEL, any solution presented must be useful regardless of jurisdiction, and it must be possible to use without a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types may be independent. The group will work on the maintainance of the Location-to-Service Translation (LoST) protocol, on (emergency services and non-emergency services related)extensions to LoST to the as well as on necessary extension related to emergency call routing. This working group cares about privacy and security concerns, and will address them within its documents. Goals and Milestones: Done An Informational RFC containing terminology definitions and the requirements Done An Informational document describing the threats and security considerations Done A Standards Track RFC describing how to identify a session set-up request is to an emergency response center Done A Standards Track RFC describing how to route an emergency call based on location information Done An Informational document describing the Mapping Protocol Architecture Dec 2008 An Informational document describing the ECRIT Framework Dec 2008 A BCP document describing the emergency call support for devices Oct 2008 An Informational document providing a problem statement and requirements for location hiding Oct 2008 An Informational document specifying how to express holes in LoST service boundaries Dec 2008 An Informational document describing how to synchronize LoST servers Jan 2009 A Standards Track RFC registering a SIP Resource Priority Header Namespace for Local Emergency Communications Feb 2009 An Informational document describing how imprecise location is used for emergency context resolution Feb 2009 A Standards Track RFC containing Location-to-Service Translation Protocol (LoST) Extensions _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 13 23:15:27 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D47328C120; Mon, 13 Oct 2008 23:15:27 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4B4728C120 for ; Mon, 13 Oct 2008 23:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdLGajXrv4ku for ; Mon, 13 Oct 2008 23:15:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E4EBD28C113 for ; Mon, 13 Oct 2008 23:15:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,407,1220227200"; d="scan'208";a="90511155" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 14 Oct 2008 06:16:03 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m9E6G2BP009080; Mon, 13 Oct 2008 23:16:02 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9E6G2SG012709; Tue, 14 Oct 2008 06:16:02 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 23:16:02 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.114.154]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 23:16:02 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Oct 2008 01:16:20 -0500 To: Randall Gellens , "Tschofenig, Hannes (NSN - FI/Espoo)" , ext Ted Hardie , , , ECRIT From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 14 Oct 2008 06:16:02.0340 (UTC) FILETIME=[5538DE40:01C92DC4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2742; t=1223964963; x=1224828963; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[NENA-ltd]=20[Ecrit]=20Design=20Team=20 Status=20Update |Sender:=20; bh=lZOZQ0VgaNCVYsFZzjnuhX7cay9k7j0AdKDwzPnz1g8=; b=E2dpr5+IQTcZey3/RI8eMsgFVidFyDCLnDIayOOusCGKKXSMZQJvJyWWT8 B4uuNnzq0lMbt7/XquUI/B6XR3IsXKrKa4q5+Yj1PQT+4vRZ3c2GMsB6LCzY EtZ36cZRwo; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Ecrit] [NENA-ltd] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 11:18 PM 10/13/2008, Randall Gellens wrote: >At 8:26 PM -0500 10/13/08, James M. Polk wrote: > >> Finally finishing the Phone BCP/Framework documents means writing >> them in a way that follows existing SIP protocol procedures (which >> refusing the BYE mandates we specify, and nothing further). >> >> That reality of implementers not waiting for the response to the BYEs >> doesn't mean we state anything different, or invent anything >> different. We just emphasize that this function within SIP needs to >> be implemented as RFC 3261 states it should be. >> >> I cannot believe either the Phone BCP or Framework documents will get >> by the RAI AD review without merely stating what already exists >> within SIP, much less by the IESG - the fact that implementers are >> ignoring 3261 functions - and this one is a basic one... > >Can a BCP change a widespread situation where implementers ignore >what the spec says? no, but what is the alternative, to specify that this time "we really, really mean it" (i.e., do this thing instead)? How exactly isn't the IESG going to evaluate that as: SIP implementers are lazy, we shouldn't use another RFC to specify another mechanism they might ignore like they did the first one? The IESG is going to ask why do anything if nothing is followed... I'm asking the same question. Why do some of us think *this time* this new mechanism (say, lets pick on one proposal of a Supported/Require negotiation that is against everything the current model SIP is built upon)? For those who aren't keeping track - Require is used in SIP requests, with a specific response mechanism (including when to error it) - which cannot be employed if the first instance of the Require header is present in a SIP response, which blows up the whole idea of erroring a Require option-tag. Before it is said that the Supported option-tag had the initial offering of support for the feature/option-tag, why do we think this will be used when something as simple as maintaining state until the final response is received within a transaction? that's a reach, and a false sense of security (that a feature exists or not)... if it isn't implemented this way, it'll probably brick the phone of course, this is only my opinion, I could be wrong James >-- >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly-selected tag: --------------- >In the United States the majority undertakes to supply a multitude of >ready-made opinions for the use of individuals, who are thus relieved >from the necessity of forming opinions of their own > --Alexis de Tocqueville _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 13 23:21:50 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4948C28C19A; Mon, 13 Oct 2008 23:21:50 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5149128C19A for ; Mon, 13 Oct 2008 23:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z8QuUq9A1y5 for ; Mon, 13 Oct 2008 23:21:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8CAD728C15B for ; Mon, 13 Oct 2008 23:21:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,407,1220227200"; d="scan'208";a="174609187" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 14 Oct 2008 06:22:44 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m9E6MiKu018169; Mon, 13 Oct 2008 23:22:44 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m9E6MiO3017901; Tue, 14 Oct 2008 06:22:44 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 23:22:43 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.114.154]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 23:22:43 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Oct 2008 01:23:01 -0500 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Ted Hardie" , , , "ECRIT" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 14 Oct 2008 06:22:43.0408 (UTC) FILETIME=[4446FD00:01C92DC5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=713; t=1223965364; x=1224829364; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20Design=20Team=20Status=20Upda te |Sender:=20; bh=OWb7NHVEfoV6uhlvxdzypIqzjjjSqnilVtr5wOy8My0=; b=t2N2ySzsDr/jvLsKmGSA3h5y7ENO2vp1uoqcavCSYMa1fs1SDhLSDe5Ipv udtNmcrd7Nd3MAI4IqtEBzXat0Mx4fqk8wVuB24An8/agSOfZVKSUdIwKdHI 3J57FSFVPD; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Ecrit] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 12:48 AM 10/14/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >Ultimately, you want to overcome implementer's universal mode > >of disconnecting (or removing) state awareness once a UA has > >sent a BYE when this is not proper SIP procedures. SIP > >procedures are to wait for the response before releasing the > >state of the call. If proper procedures were followed, none > >of this would be an issue, because the BYE would merely need > >to be refused with a 488 (Not Acceptable Here) to address this. > >Too early for solution discussions. ah, but this one is specified in RFC 3261 - which (way) predates ECRIT therefore this "solution" exists already. This is not a new one James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 13 23:28:18 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B0D28C1A3; Mon, 13 Oct 2008 23:28:18 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D535428C1A3 for ; Mon, 13 Oct 2008 23:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-oGXVjU6aoG for ; Mon, 13 Oct 2008 23:28:16 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id B722428C19A for ; Mon, 13 Oct 2008 23:28:15 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9E6SVpv029894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Oct 2008 08:28:31 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9E6SQHi001919; Tue, 14 Oct 2008 08:28:30 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 08:28:29 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 08:28:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 09:27:44 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Design Team Status Update Thread-Index: AcktxUiK4G9EOUsRRUqSKc0fU0SUVAAABokw References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext James M. Polk" , "ext Ted Hardie" , , , "ECRIT" X-OriginalArrivalTime: 14 Oct 2008 06:28:28.0641 (UTC) FILETIME=[120D5D10:01C92DC6] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081014082831-40304BB0-41FB28AA/0-0/0-15 X-purgate-size: 1657/0 Subject: Re: [Ecrit] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It would be great if we can fulfill the requirements using existing mechanisms. BUT I hear some folks saying that they haven't understood all the requirements. See, for example, the recent mails from Marc: http://www.ietf.org/mail-archive/web/ecrit/current/msg05511.html http://www.ietf.org/mail-archive/web/ecrit/current/msg05512.html As such, I thought it makes sort of sense to make sure that we understand the context first. Have you understood all requirements listed in http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnect-rqmts-00 .txt >-----Original Message----- >From: ext James M. Polk [mailto:jmpolk@cisco.com] >Sent: 14 October, 2008 09:23 >To: Tschofenig, Hannes (NSN - FI/Espoo); ext Ted Hardie; >nena-i2_5@listserv.neustar.biz; nena-ltd@lists.cs.columbia.edu; ECRIT >Subject: RE: [Ecrit] Design Team Status Update > >At 12:48 AM 10/14/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> >Ultimately, you want to overcome implementer's universal mode of >> >disconnecting (or removing) state awareness once a UA has >sent a BYE >> >when this is not proper SIP procedures. SIP procedures are to wait >> >for the response before releasing the state of the call. If proper >> >procedures were followed, none of this would be an issue, >because the >> >BYE would merely need to be refused with a 488 (Not >Acceptable Here) >> >to address this. >> >>Too early for solution discussions. > >ah, but this one is specified in RFC 3261 - which (way) predates ECRIT > >therefore this "solution" exists already. This is not a new one > >James > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 13 23:38:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9214A28C12E; Mon, 13 Oct 2008 23:38:25 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8427C3A6BE3 for ; Mon, 13 Oct 2008 23:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oS93kFehS20g for ; Mon, 13 Oct 2008 23:38:20 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8B92F3A676A for ; Mon, 13 Oct 2008 23:38:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,407,1220227200"; d="scan'208";a="174618223" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 14 Oct 2008 06:38:34 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9E6cY9n015222; Mon, 13 Oct 2008 23:38:34 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m9E6cYa9029358; Tue, 14 Oct 2008 06:38:34 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 23:38:33 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.114.154]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 23:38:33 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Oct 2008 01:38:51 -0500 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Ted Hardie" , , , "ECRIT" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 14 Oct 2008 06:38:33.0305 (UTC) FILETIME=[7A75C490:01C92DC7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=302; t=1223966314; x=1224830314; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20Design=20Team=20Status=20Upda te |Sender:=20; bh=B+wwq3msCl7SxVlwQhnOgq9PhZpxIPRaglRljksgQAQ=; b=FebGiRkXyqSRUt+hdUK2kBnLXQWDpSndJRmKTPIAszoXuWQurQvSlDi6kq RPXi5UPfkrIfKTDJj1fAI3uxQSSsAdDpxueZSa6+DSESLGxtn311I+YcAWQD xErIpc/w7yWLke6E1c6zg5rQ0pbIJzXzo/n2oCqcTYotBp3f+aEj8=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 12:48 AM 10/14/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >So, if you look at the current Phone BCP: you mean the ID I'm the only other coauthor of (with Brian)? >* Do you think that the current text is fine? I'm not ecstatic with all of the text, but I am generally happy with it. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 13 23:54:04 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70FE28C157; Mon, 13 Oct 2008 23:54:04 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32993A6BEC for ; Mon, 13 Oct 2008 23:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.236 X-Spam-Level: X-Spam-Status: No, score=-5.236 tagged_above=-999 required=5 tests=[AWL=1.363, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAOeVKfK2e74 for ; Mon, 13 Oct 2008 23:54:02 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id AB1653A67F7 for ; Mon, 13 Oct 2008 23:54:01 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9E6sZxS028397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Oct 2008 08:54:35 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9E6sYdH018428; Tue, 14 Oct 2008 08:54:35 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 08:54:33 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 08:54:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 09:54:30 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Design Team Status Update Thread-Index: Acktx34L+K2GQid2T16X87w+4dLKKgAAiKow References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext James M. Polk" , "ext Ted Hardie" , , , "ECRIT" X-OriginalArrivalTime: 14 Oct 2008 06:54:32.0944 (UTC) FILETIME=[B6730F00:01C92DC9] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081014085435-40300BB0-95F05656/0-0/0-15 X-purgate-size: 372/0 Subject: Re: [Ecrit] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >At 12:48 AM 10/14/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>So, if you look at the current Phone BCP: > >you mean the ID I'm the only other coauthor of (with Brian)? Yup. That I-D. > >>* Do you think that the current text is fine? > >I'm not ecstatic with all of the text, but I am generally >happy with it. OK. Good to hear that _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 03:48:40 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FF283A6BA4; Tue, 14 Oct 2008 03:48:40 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962313A6BB8 for ; Tue, 14 Oct 2008 03:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94Gcf+9JUu0G for ; Tue, 14 Oct 2008 03:48:36 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 2D7943A6BA4 for ; Tue, 14 Oct 2008 03:48:33 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9EAHIZF029914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Oct 2008 12:17:18 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9EAHDiw010810 for ; Tue, 14 Oct 2008 12:17:18 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 12:17:00 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 12:17:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 13:16:59 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-lost-sync-00.txt: Text Proposal Thread-Index: Ackt5f4x1oXE0MHBRKy9U0XIsvxctQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 14 Oct 2008 10:17:00.0086 (UTC) FILETIME=[FEB5D560:01C92DE5] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081014121718-73814BB0-0BBE0951/0-0/0-15 X-purgate-size: 16532/0 Subject: [Ecrit] draft-ietf-ecrit-lost-sync-00.txt: Text Proposal X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I crafted an initial proposal for the text in the draft. ---------------- 3. Distributing Mappings via and When a LoST node obtains new information that is of interest to its peers, it pushes the new mappings to its peers. This information might arrive through non-LoST means, such as a manual addition to the local mappings database, or through another LoST node, via a request or a described later. Each peer keeps track of which peer it has exchanged which mapping elements with. Mapping elements are identified, as described in Section 5.1 of RFC 5222, by the 'source', 'sourceID' and 'lastUpdated' parameters. A mapping is considered the same if these three attributes match. Nodes never push the same information to the same peer twice. To delete a mapping, the content of the mapping is left empty. The node can delete the mapping from its internal mapping database, but has to remember which peers it has distributed this update to. Processing a message may lead to a successful response in the form of a or in an message to be returned. Only the following errors defined in RFC 5222 are re-used: - badRequest - internalError - serverTimeout Neither the nor the messages are utilized by this specification. The semantic of these errors is described in Section 13.1 of RFC 5222. If the set of nodes that are synchronizing their data does not form a tree, it is possible that the same information arrives through several other nodes. This is unavoidable, but generally only imposes a modest overhead. (It would be possible to create a spanning tree in the same fashion as IP multicast, but the complexity does not seem warranted, giving the relatively low volume of data.) A newly received mapping M' replaces an existing one M* if the following conditions hold: (1) M'.source equals M*.source (case insensitive comparison) (2) M'.sourceID' equals M*.sourceID (case insensitive comparison) (3) M'.lastUpdated greater than M*.lastUpdated Consider the following example shown in Figure 1. Image a LoST node that obtained two new mappings identified as follows: * source="authoritative.example" sourceId="7e3f40b098c711dbb6060800200c9a66" lastUpdated="2008-11-26T01:00:00Z" * source="authoritative.example" sourceId="7e3f40b098c711dbb606011111111111" lastUpdated="2008-11-01T01:00:00Z" These two mappings have to be added to the peer's mapping database. Additionally, it determines that the following mapping has to be deleted: * source="nj.us.example" sourceId="123" lastUpdated="2008-11-01T01:00:00Z" Figure 1 shows the corresponding message: Leonia Police Department urn:service:sos.police US NJ Leonia 07605 sip:police@leonianj.example.org 911 New York City Police Department urn:service:sos.police 37.775 -122.4194 37.555 -122.4194 37.555 -122.4264 37.775 -122.4264 37.775 -122.4194 sip:nypd@example.com xmpp:nypd@example.com 911 Figure 1: pushMappingsRequest Example In response the peer performs the necessary operation and updates its mapping database. In particular, it will check whether the fields are understood and contain values that are understood. In our case a positive response is returned as shown in Figure 2: Figure 2: pushMappingsResponse Example 4. Requesting Mappings via and Instead of pushing mappings to another LoST node a LoST client can get list of mappings identified by elements. When a server does not return a mapping as requested then there may be two reasons for this: 1) the mapping is not available at that server 2) the client has the current mapping and hence it does not need to be resent. A LoST node wanting to synchronize its mapping store with another node issues a , containing an enumeration of the current mapping sources, source identifiers and lastUpdated in the elements. The recipient of the request compares that list to its own list of mappings. It then returns an unordered set of mappings that are more recent than the ones identified in the . The querier can limit the scope of the returned mappings returned by using the 'source', 'sourceId', and 'lastUpdated' attributes. If the 'source' attribute is specified, only mappings with that particular source attribute are considered. Similarly, the 'sourceId' attribute restricts mappings to those matching the attribute. If 'sourceId' is specified, the 'source' attribute also needs to be provided, since the 'sourceId' attribute is only defined for a particular source. Similarly, if 'lastUpdated' is specified, 'source' and 'sourceId' need to be specified as well. In other words, a querier cannot ask for all mappings last updated today regardless of source, for example. While the 'source' and the 'sourceId' attributes are checked for (case insensitive) equality the value in the 'lastUpdated' attribute is compared with the matching mappings and if a fresher mapping exists then it is returned. elements that do not match any of the locally available mappings in the database are silently ignored. Processing a message may lead to a successful response in the form of a or in an message to be returned. Only the following errors defined in RFC 5222 are re-used: - badRequest - internalError - serverTimeout Neither the nor the messages are utilized by this specification. The following example illustrates the usage of the and messages. Figure 3 shows a LoST node requesting a specific mapping for source="authoritative.bar.example" and sourceId="7e3f40b098c711dbb6060800200c9a66" that is fresher than "2006-11-01T01:00:00Z". Additionally, all mappings that match source="authoritative.foo.example" are requested. Figure 3: Example The response is shown in Figure 4. A more recent mapping was available with the identification of source="authoritative.bar.example" and sourceId="7e3f40b098c711dbb6060800200c9a66". Only one mapping that matched source="authoritative.foo.example" was found and returned. Leonia Police Department urn:service:sos.police US NJ Leonia 07605 sip:police@leonianj2.example.org 911 New York City Police Department urn:service:sos.police 37.775 -122.4194 37.555 -122.4194 37.555 -122.4264 37.775 -122.4264 37.775 -122.4194 sip:nypd@example.com xmpp:nypd@example.com 911 Figure 4: Example 5. Relax NG Schema Location-to-Service Translation (LoST) Synchronization Protocol 6. Security Considerations The LoST security considerations are discussed in [2]. The operations described in this document involve mutually-trusting LoST nodes. These nodes need to authenticate each other. Nodes implementing LoST MUST implement mutual authentication based on certificates . 7. IANA Considerations No content type registration is needed for this specification. The application/lost+xml MIME type is used. 7.1. LoST Sync Relax NG Schema Registration URI: urn:ietf:params:xml:ns:lost-sync1 Registrant Contact: IETF ECRIT Working Group, Henning Schulzrinne (hgs@cs.columbia.edu). Relax NG Schema: The Relax NG schema to be registered is contained in Section 5. Its first line is and its last line is 7.2. LoST Synchronization Namespace Registration URI: urn:ietf:params:xml:ns:lost-sync1 Registrant Contact: IETF ECRIT Working Group, Henning Schulzrinne (hgs@cs.columbia.edu). XML: BEGIN LoST Synchronization Namespace

Namespace for LoST server synchronization

urn:ietf:params:xml:ns:lost-sync1

See RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.].

END _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 04:49:34 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA513A6B8B; Tue, 14 Oct 2008 04:49:34 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D80328C124 for ; Tue, 14 Oct 2008 04:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.254 X-Spam-Level: X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[AWL=1.345, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpZzGHnkSIL6 for ; Tue, 14 Oct 2008 04:49:32 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 157313A6826 for ; Tue, 14 Oct 2008 04:49:31 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9EBnWru004004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Oct 2008 13:49:32 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9EBnVMV003464 for ; Tue, 14 Oct 2008 13:49:32 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:49:32 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:49:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 14:49:20 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-phonebcp-05.txt: References Thread-Index: Ackt8uTr6YDMGZabRi2s3PDw32tqGQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 14 Oct 2008 11:49:27.0939 (UTC) FILETIME=[E97D0530:01C92DF2] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081014134932-4030BBB0-F74C60F3/0-0/0-15 X-purgate-size: 972/0 Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: References X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I wonder why the following references need to be normative: [I-D.barnes-geopriv-lo-sec] There shouldn't really be a normative dependency on this document. [I-D.ietf-sipping-config-framework] This is just a MAY and I don't even think it is necessary at all to mention it in the document given that there are so many ways to configure devices. [RFC5077] Regarding RFC 5077: You write: The use of [RFC5077] is RECOMMENDED to minimize the time to establish TLS sessions. Well. RFC 5077 makes things go faster without establishing state on the server. As such, I would also write " The use of [RFC5077] is RECOMMENDED to minimize the time to establish TLS sessions without keeping server-side state. " I would move the reference into the informative part as it is not really a normative dependency. A few references need to get updated: [I-D.ietf-ecrit-dhc-lost-discovery] [I-D.ietf-ecrit-lost] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 04:49:38 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E8128C18D; Tue, 14 Oct 2008 04:49:38 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E82BC28C179 for ; Tue, 14 Oct 2008 04:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwzaZFO9giop for ; Tue, 14 Oct 2008 04:49:36 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id C667428C15C for ; Tue, 14 Oct 2008 04:49:35 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9EBnaVs023242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Oct 2008 13:49:36 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9EBnWoB002505 for ; Tue, 14 Oct 2008 13:49:36 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:49:29 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:49:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 14:49:23 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call Thread-Index: Ackt8ubHOAdjXzPzQLmHqGE2+O5wIQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 14 Oct 2008 11:49:29.0366 (UTC) FILETIME=[EA56C360:01C92DF2] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081014134936-7381FBB0-C73B4917/0-0/0-15 X-purgate-size: 2100/0 Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If the service provider always knows the location of the device, then the service provider could recognize them. SP-2 Proxy servers SHOULD recognize emergency dial strings if for some reason the endpoint does not recognize them. This cannot be relied upon by the device if the service provider cannot always determine the location of the device. Looking at these 2 SHOULDs I can imagine cases where neither one of them recognizes them. Wouldn't it be better to have a MUST with the 2nd requirement? I would delete the 2nd sentence since in that case it would be very difficult to route the call and to find the right PSAP as well. Comparing with the following requirement I recognize a mismatch: ED-19/INT-10/SP-13 Where proxies provide location on behalf of endpoints, the service provider MUST ensure that either the end device is provided with the local dial strings for its current location (where the end device recognizes dial strings), or the service provider proxy MUST detect the appropriate local dial strings at the time of the call. ED-5/SP-4 Local dial strings MUST be recognized. "MUST" be recognized by whom? See requirements above. ED-6/SP-5 Devices MUST be able to be configured with the home country from which the home dial string(s) can be determined. Shouldn't this read like " Devices MUST be have mechanisms to learn the user's home emergency numbers. " ED-9 Endpoints SHOULD be able to have home dial strings provisioned by configuration. I guess ED-9 should say something like "Endpoints SHOULD be able to have home dial strings dynamically provisioned." To refer to the case that manual configuration may also be used in order to meet the previous requirements. ED-11/SP-9 All emergency services specified in [RFC5031] MUST be recognized. Should say something like: " All emergency services URNs specified in .... MUST be recognized. " _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 04:49:40 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2CE28C1A3; Tue, 14 Oct 2008 04:49:40 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E54F28C1A1 for ; Tue, 14 Oct 2008 04:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yfl42khv6GrZ for ; Tue, 14 Oct 2008 04:49:38 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id A3F5B28C179 for ; Tue, 14 Oct 2008 04:49:37 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9EBnaKs023246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Oct 2008 13:49:36 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9EBnWoD002505 for ; Tue, 14 Oct 2008 13:49:36 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:49:30 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:49:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 14:49:25 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-phonebcp-05.txt: Media Thread-Index: Ackt8ugQefYJ96oQSE2zsXvdG5crSg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 14 Oct 2008 11:49:29.0913 (UTC) FILETIME=[EAAA3A90:01C92DF2] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081014134936-73816BB0-BCC91912/0-0/0-15 X-purgate-size: 172/0 Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Media X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Looking at Section 14 about media I was wondering whether the usage of SRTP wouldn't make sense. For key management I would go for SDES. What do you think? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 04:49:58 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CADAC28C0CF; Tue, 14 Oct 2008 04:49:58 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3265F28C0CF for ; Tue, 14 Oct 2008 04:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.255 X-Spam-Level: X-Spam-Status: No, score=-5.255 tagged_above=-999 required=5 tests=[AWL=1.344, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFaG1NNlHg1z for ; Tue, 14 Oct 2008 04:49:57 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 2B1D63A692B for ; Tue, 14 Oct 2008 04:49:56 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9EBo7N8006163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Oct 2008 13:50:07 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9EBo4DF003647 for ; Tue, 14 Oct 2008 13:50:07 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:50:07 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:50:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 14:50:02 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-phonebcp-05.txt: User Interface Requirements Thread-Index: Ackt8v4cEuENj9IIRdejr3WUkJ7UOg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 14 Oct 2008 11:50:06.0662 (UTC) FILETIME=[0091AE60:01C92DF3] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081014135007-40305BB0-C7AD9A37/0-0/0-15 X-purgate-size: 627/0 Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: User Interface Requirements X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org ED-10 Devices SHOULD NOT have one button emergency calling initiation. This requirement sounds nice when you provide some background on why that this is a bad idea. I wonder whether someone could provide some references to these studies as they do exist. However, this is not really an issue an IETF document worries about specifically not with regard to RFC 2119 language. I would not object to have it mentioned somewhere in the document saying: "Note: The following studies indicate that designing a user interface with a single button for emergency call is a bad idea because of ....". _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 05:31:07 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F80E3A6826; Tue, 14 Oct 2008 05:31:07 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A70FC3A6826 for ; Tue, 14 Oct 2008 05:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.286 X-Spam-Level: X-Spam-Status: No, score=-5.286 tagged_above=-999 required=5 tests=[AWL=1.313, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvzDQfBbzUWT for ; Tue, 14 Oct 2008 05:31:04 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 78FB23A67EA for ; Tue, 14 Oct 2008 05:31:04 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9EBnWiL003997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Oct 2008 13:49:32 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9EBnVMT003464 for ; Tue, 14 Oct 2008 13:49:32 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:49:31 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:49:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 14:49:17 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-phonebcp-05.txt: Which devices and services should support emergency calls Thread-Index: Ackt8uNyGncjF1p3QL6MPh/0uW5Drg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 14 Oct 2008 11:49:27.0517 (UTC) FILETIME=[E93CA0D0:01C92DF2] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081014134932-40300BB0-ACD21AD9/0-0/0-15 X-purgate-size: 3380/0 Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Which devices and services should support emergency calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org ED-1 A device or application SHOULD support emergency calling if a user could reasonably expect to be able to place a call for help with the device. SP-1 If a device or application expects to be able to place a call for help, the service provider that supports it MUST facilitate emergency calling. ED-2 Devices that create media sessions and exchange audio, video and/or text, and have the capability to establish sessions to a wide variety of addresses, and communicate over private IP networks or the Internet, SHOULD support emergency calls. This is nice text and nice requirements. Still, I believe it would improve the credibility of the document if we acknowledge the fact that we aren't regulating the deployment. Maybe we can soften these requirements a bit and write something like. " As end users are typically not aware of the details of the technology they are using we below list the following high-level goals for the implementation and deployment of emergency services functionality: ED-1 / SP-1 It is RECOMMENDED that a device or application supports emergency calling if a user could reasonably expect to be able to place a call for help with the device. It is therefore RECOMMENDED that devices that create media sessions and exchange audio, video and/or text, and have the capability to establish sessions to a wide variety of communication end points, and deliver data over private IP networks or the Internet ,to support emergency calls. " The same is true for requirements listed below. In the past I suggested to soften them a bit and to add references about current regulation. One, however, has to acknowledge that these numbers are not applicable to all juristictions. 6.2.2. Access network "wire database" location information It is RECOMMENDED that interior location be provided when spaces exceed approximately 650 square meters. 6.2.3. End-system measured location information ED-16/INT-7 Devices MAY support end-system measured location. Uncertainty of less than 100 m with 95% confidence SHOULD be available for dispatch. ED-17/INT-8/AN-8 Devices that support endpoint measuring of location MUST have at least a coarse location capability (typically <1km accuracy when not location hiding) for routing of calls. The location mechanism MAY be a service provided by the access network. 6.2.4. Network-measured location information AN-9 Access networks MAY provide network-measured location determination. Wireless access network which do not support network measured location MUST require that all devices connected to the network have end-system measured location. Uncertainty of less than 100 m with 95% confidence SHOULD be available for dispatch. AN-10 Access networks that provide network measured location MUST have at least a coarse location (typically <1km when not location hiding) capability at all times for routing of calls. AN-11 Access networks with range of <10 meters (e.g. personnal area networks such as Bluetooth MUST provide a location to mobile devices connected to them. The location provided SHOULD be that of the access point location unless a more accurate mechanism is provided. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 05:47:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ABAA28C1A9; Tue, 14 Oct 2008 05:47:14 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27A0328C1A9 for ; Tue, 14 Oct 2008 05:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrJWkiTaCETq for ; Tue, 14 Oct 2008 05:47:12 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 548E33A6B27 for ; Tue, 14 Oct 2008 05:47:12 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KpjIp-0004XY-M9; Tue, 14 Oct 2008 07:47:07 -0500 From: "Brian Rosen" To: "'James M. Polk'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext Ted Hardie'" , , , "'ECRIT'" References: In-Reply-To: Date: Tue, 14 Oct 2008 08:47:06 -0400 Message-ID: <04d501c92dfa$f92ab790$eb8026b0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcktxT9EwYAGd2nVRU+U3UcuXB4e3gANXFJQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You are ignoring the observation that refusing a BYE means all proxies in the path have to be aware that this is possible. That is much more of change than we can probably expect. Not sending a BYE doesn't have that problem. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: Tuesday, October 14, 2008 2:23 AM To: Tschofenig, Hannes (NSN - FI/Espoo); ext Ted Hardie; nena-i2_5@listserv.neustar.biz; nena-ltd@lists.cs.columbia.edu; ECRIT Subject: Re: [Ecrit] Design Team Status Update At 12:48 AM 10/14/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >Ultimately, you want to overcome implementer's universal mode > >of disconnecting (or removing) state awareness once a UA has > >sent a BYE when this is not proper SIP procedures. SIP > >procedures are to wait for the response before releasing the > >state of the call. If proper procedures were followed, none > >of this would be an issue, because the BYE would merely need > >to be refused with a 488 (Not Acceptable Here) to address this. > >Too early for solution discussions. ah, but this one is specified in RFC 3261 - which (way) predates ECRIT therefore this "solution" exists already. This is not a new one James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 05:50:08 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9FC128C1AE; Tue, 14 Oct 2008 05:50:08 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D962528C1AE for ; Tue, 14 Oct 2008 05:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrK-ExpyXw6Q for ; Tue, 14 Oct 2008 05:50:07 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id E24AB28C1A8 for ; Tue, 14 Oct 2008 05:50:06 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KpjMD-0004kS-Um; Tue, 14 Oct 2008 07:50:38 -0500 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: In-Reply-To: Date: Tue, 14 Oct 2008 08:50:37 -0400 Message-ID: <04d601c92dfb$7668a320$6339e960$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ackt8ubHOAdjXzPzQLmHqGE2+O5wIQACEYDw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The problem is that proxies don't have location, and therefore can't recognize them in most cases. Mobile systems with IMS, where the visited network handles emergency calls would be an exception, but a wireline IMS system which allowed nomading would not be able to recognize local emergency dialstrings. That is why SHOULD is appropriate. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Tuesday, October 14, 2008 7:49 AM To: ECRIT Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If the service provider always knows the location of the device, then the service provider could recognize them. SP-2 Proxy servers SHOULD recognize emergency dial strings if for some reason the endpoint does not recognize them. This cannot be relied upon by the device if the service provider cannot always determine the location of the device. Looking at these 2 SHOULDs I can imagine cases where neither one of them recognizes them. Wouldn't it be better to have a MUST with the 2nd requirement? I would delete the 2nd sentence since in that case it would be very difficult to route the call and to find the right PSAP as well. Comparing with the following requirement I recognize a mismatch: ED-19/INT-10/SP-13 Where proxies provide location on behalf of endpoints, the service provider MUST ensure that either the end device is provided with the local dial strings for its current location (where the end device recognizes dial strings), or the service provider proxy MUST detect the appropriate local dial strings at the time of the call. ED-5/SP-4 Local dial strings MUST be recognized. "MUST" be recognized by whom? See requirements above. ED-6/SP-5 Devices MUST be able to be configured with the home country from which the home dial string(s) can be determined. Shouldn't this read like " Devices MUST be have mechanisms to learn the user's home emergency numbers. " ED-9 Endpoints SHOULD be able to have home dial strings provisioned by configuration. I guess ED-9 should say something like "Endpoints SHOULD be able to have home dial strings dynamically provisioned." To refer to the case that manual configuration may also be used in order to meet the previous requirements. ED-11/SP-9 All emergency services specified in [RFC5031] MUST be recognized. Should say something like: " All emergency services URNs specified in .... MUST be recognized. " _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 05:51:09 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E86633A6BA4; Tue, 14 Oct 2008 05:51:09 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5CC3A6BA6 for ; Tue, 14 Oct 2008 05:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNB3y-RUzwEM for ; Tue, 14 Oct 2008 05:51:04 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 4402B3A67EA for ; Tue, 14 Oct 2008 05:51:04 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KpjN6-0004mX-VC; Tue, 14 Oct 2008 07:51:33 -0500 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: In-Reply-To: Date: Tue, 14 Oct 2008 08:51:32 -0400 Message-ID: <04d701c92dfb$973676e0$c5a364a0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ackt8uTr6YDMGZabRi2s3PDw32tqGQACKiBg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: References X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If there is no objection, I will do this. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Tuesday, October 14, 2008 7:49 AM To: ECRIT Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: References I wonder why the following references need to be normative: [I-D.barnes-geopriv-lo-sec] There shouldn't really be a normative dependency on this document. [I-D.ietf-sipping-config-framework] This is just a MAY and I don't even think it is necessary at all to mention it in the document given that there are so many ways to configure devices. [RFC5077] Regarding RFC 5077: You write: The use of [RFC5077] is RECOMMENDED to minimize the time to establish TLS sessions. Well. RFC 5077 makes things go faster without establishing state on the server. As such, I would also write " The use of [RFC5077] is RECOMMENDED to minimize the time to establish TLS sessions without keeping server-side state. " I would move the reference into the informative part as it is not really a normative dependency. A few references need to get updated: [I-D.ietf-ecrit-dhc-lost-discovery] [I-D.ietf-ecrit-lost] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 05:53:03 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C3F23A6BA4; Tue, 14 Oct 2008 05:53:03 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 610953A6ABA for ; Tue, 14 Oct 2008 05:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+LEs2eIMJDH for ; Tue, 14 Oct 2008 05:52:57 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id A18873A6BA4 for ; Tue, 14 Oct 2008 05:52:57 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KpjOk-0004rk-1G; Tue, 14 Oct 2008 07:53:14 -0500 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: In-Reply-To: Date: Tue, 14 Oct 2008 08:53:13 -0400 Message-ID: <04d801c92dfb$d3765a80$7a630f80$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ackt8ugQefYJ96oQSE2zsXvdG5crSgACLTCA Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Media X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org There are so many things in phonebcp that are not implemented, adding SRTP, and then insisting on SDES is really dooming interoperability. I do think, generally, that encrypting the media is a good thing, but I can't even see "SHOULD". Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Tuesday, October 14, 2008 7:49 AM To: ECRIT Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Media Looking at Section 14 about media I was wondering whether the usage of SRTP wouldn't make sense. For key management I would go for SDES. What do you think? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 05:54:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495EA3A6BB8; Tue, 14 Oct 2008 05:54:25 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63AC13A6BA6 for ; Tue, 14 Oct 2008 05:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+6m8TotT6LD for ; Tue, 14 Oct 2008 05:54:22 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 5EB7A3A6BA4 for ; Tue, 14 Oct 2008 05:54:22 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KpjPv-0004vK-NP; Tue, 14 Oct 2008 07:54:27 -0500 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: In-Reply-To: Date: Tue, 14 Oct 2008 08:54:27 -0400 Message-ID: <04d901c92dfb$ff672200$fe356600$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ackt8v4cEuENj9IIRdejr3WUkJ7UOgACN2Ng Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: User Interface Requirements X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The relevant text is in -framework. I think the requirement really ought to stand. It's a very common error, and it's a pretty well understoond phenomenon. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Tuesday, October 14, 2008 7:50 AM To: ECRIT Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: User Interface Requirements ED-10 Devices SHOULD NOT have one button emergency calling initiation. This requirement sounds nice when you provide some background on why that this is a bad idea. I wonder whether someone could provide some references to these studies as they do exist. However, this is not really an issue an IETF document worries about specifically not with regard to RFC 2119 language. I would not object to have it mentioned somewhere in the document saying: "Note: The following studies indicate that designing a user interface with a single button for emergency call is a bad idea because of ....". _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 05:58:11 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F323A6BB8; Tue, 14 Oct 2008 05:58:11 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9ECD3A6BB8 for ; Tue, 14 Oct 2008 05:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.315 X-Spam-Level: X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[AWL=-0.716, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYjMvjSRI8HK for ; Tue, 14 Oct 2008 05:58:09 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 27BBB3A6ABA for ; Tue, 14 Oct 2008 05:58:08 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9ECw7sc024435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Oct 2008 14:58:07 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9ECw5U5009680; Tue, 14 Oct 2008 14:58:07 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 14:57:50 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 14:57:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 15:57:37 +0300 Message-ID: In-Reply-To: <04d601c92dfb$7668a320$6339e960$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call Thread-Index: Ackt8ubHOAdjXzPzQLmHqGE2+O5wIQACEYDwAAAcXZA= References: <04d601c92dfb$7668a320$6339e960$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Brian Rosen" , "ECRIT" X-OriginalArrivalTime: 14 Oct 2008 12:57:48.0547 (UTC) FILETIME=[75A42530:01C92DFC] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081014145807-73816BB0-BA113419/0-0/0-15 X-purgate-size: 3925/0 Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Brian, I know this challenge. Still, you have to put a must in there to make sure that the call is actually recognized. The architecture is very much build on the idea that either the end host or the VSP (directly or indirectly) get location from somewhere. As we learned at the previous emergency services workshops there are some sort of hacks one can do to bypass this need but they only work when there is a relationship between the VSP and the ISP. Currently, these things are being setup in individual countries and as such the question of recognizing emergency service numbers is essentially solved. Ciao Hannes >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net] >Sent: 14 October, 2008 15:51 >To: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' >Subject: RE: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: >Identifying an emergency call > >The problem is that proxies don't have location, and therefore >can't recognize them in most cases. Mobile systems with IMS, >where the visited network handles emergency calls would be an >exception, but a wireline IMS system which allowed nomading >would not be able to recognize local emergency dialstrings. >That is why SHOULD is appropriate. > >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >Sent: Tuesday, October 14, 2008 7:49 AM >To: ECRIT >Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying >an emergency call > > > ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If > the service provider always knows the location of the device, then > the service provider could recognize them. > > SP-2 Proxy servers SHOULD recognize emergency dial strings if for > some reason the endpoint does not recognize them. This cannot be > relied upon by the device if the service provider cannot always > determine the location of the device. > > >Looking at these 2 SHOULDs I can imagine cases where neither >one of them recognizes them. > >Wouldn't it be better to have a MUST with the 2nd requirement? >I would delete the 2nd sentence since in that case it would be >very difficult to route the call and to find the right PSAP as well. > >Comparing with the following requirement I recognize a mismatch: > > ED-19/INT-10/SP-13 Where proxies provide location on behalf of > endpoints, the service provider MUST ensure that either the end > device is provided with the local dial strings for its current > location (where the end device recognizes dial strings), or the > service provider proxy MUST detect the appropriate local >dial strings > at the time of the call. > > > > ED-5/SP-4 Local dial strings MUST be recognized. > >"MUST" be recognized by whom? See requirements above. > > > ED-6/SP-5 Devices MUST be able to be configured with the >home country > from which the home dial string(s) can be determined. > > >Shouldn't this read like >" >Devices MUST be have mechanisms to learn the user's home >emergency numbers. >" > > > ED-9 Endpoints SHOULD be able to have home dial strings provisioned > by configuration. > >I guess ED-9 should say something like "Endpoints SHOULD be >able to have >home dial strings dynamically provisioned." >To refer to the case that manual configuration may also be >used in order >to meet the previous requirements. > > > ED-11/SP-9 All emergency services specified in [RFC5031] MUST be > recognized. > >Should say something like: >" >All emergency services URNs specified in .... MUST be recognized. >" > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 06:00:38 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE6B03A6BA6; Tue, 14 Oct 2008 06:00:38 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1D5B3A6826 for ; Tue, 14 Oct 2008 06:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUxH-mjIj-5W for ; Tue, 14 Oct 2008 06:00:33 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id C15D63A6ABA for ; Tue, 14 Oct 2008 06:00:33 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KpjVz-0005Kz-Cr; Tue, 14 Oct 2008 08:00:43 -0500 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: In-Reply-To: Date: Tue, 14 Oct 2008 09:00:42 -0400 Message-ID: <04da01c92dfc$df5d4510$9e17cf30$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ackt8uNyGncjF1p3QL6MPh/0uW5DrgACSktQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Which devices and services should support emergency calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think your reasoning is faulty. I think it IS important to describe when -phonebcp is applicable. We do that in many circumstances in the IETF. This not a deployment requirement, it's an implementation requirement. There are no BCP police of course. I also think it is essential to provide guidance (in a BCP, it's not a protocol specification) on location uncertainty. I can add words about local regulation (perhaps, "some jurisdictions have regulations governing this") if you wish. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Tuesday, October 14, 2008 7:49 AM To: ECRIT Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Which devices and services should support emergency calls ED-1 A device or application SHOULD support emergency calling if a user could reasonably expect to be able to place a call for help with the device. SP-1 If a device or application expects to be able to place a call for help, the service provider that supports it MUST facilitate emergency calling. ED-2 Devices that create media sessions and exchange audio, video and/or text, and have the capability to establish sessions to a wide variety of addresses, and communicate over private IP networks or the Internet, SHOULD support emergency calls. This is nice text and nice requirements. Still, I believe it would improve the credibility of the document if we acknowledge the fact that we aren't regulating the deployment. Maybe we can soften these requirements a bit and write something like. " As end users are typically not aware of the details of the technology they are using we below list the following high-level goals for the implementation and deployment of emergency services functionality: ED-1 / SP-1 It is RECOMMENDED that a device or application supports emergency calling if a user could reasonably expect to be able to place a call for help with the device. It is therefore RECOMMENDED that devices that create media sessions and exchange audio, video and/or text, and have the capability to establish sessions to a wide variety of communication end points, and deliver data over private IP networks or the Internet ,to support emergency calls. " The same is true for requirements listed below. In the past I suggested to soften them a bit and to add references about current regulation. One, however, has to acknowledge that these numbers are not applicable to all juristictions. 6.2.2. Access network "wire database" location information It is RECOMMENDED that interior location be provided when spaces exceed approximately 650 square meters. 6.2.3. End-system measured location information ED-16/INT-7 Devices MAY support end-system measured location. Uncertainty of less than 100 m with 95% confidence SHOULD be available for dispatch. ED-17/INT-8/AN-8 Devices that support endpoint measuring of location MUST have at least a coarse location capability (typically <1km accuracy when not location hiding) for routing of calls. The location mechanism MAY be a service provided by the access network. 6.2.4. Network-measured location information AN-9 Access networks MAY provide network-measured location determination. Wireless access network which do not support network measured location MUST require that all devices connected to the network have end-system measured location. Uncertainty of less than 100 m with 95% confidence SHOULD be available for dispatch. AN-10 Access networks that provide network measured location MUST have at least a coarse location (typically <1km when not location hiding) capability at all times for routing of calls. AN-11 Access networks with range of <10 meters (e.g. personnal area networks such as Bluetooth MUST provide a location to mobile devices connected to them. The location provided SHOULD be that of the access point location unless a more accurate mechanism is provided. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 06:06:49 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51CA628C1AD; Tue, 14 Oct 2008 06:06:49 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C49628C1AD for ; Tue, 14 Oct 2008 06:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWZwZikuTd3I for ; Tue, 14 Oct 2008 06:06:42 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 73D423A69C0 for ; Tue, 14 Oct 2008 06:06:42 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Kpjbs-0005g0-LU; Tue, 14 Oct 2008 08:06:48 -0500 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: <04d601c92dfb$7668a320$6339e960$@net> In-Reply-To: Date: Tue, 14 Oct 2008 09:06:48 -0400 Message-ID: <04de01c92dfd$b93cb8b0$2bb62a10$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ackt8ubHOAdjXzPzQLmHqGE2+O5wIQACEYDwAAAcXZAAAFbnIA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes If it's not possible in most circumstances to have proxies recognize emergency dial strings, then it's not possible to make it a requirement that they do so. The fact is that the endpoint must do it. That is the actual requirement. The proxy text is a backstop; it's not required, it's not usually even possible, but it's nice to have. If anything, you could be arguing we should delete the proxy requirement, or at least reword it to cover the case of a guarantee that the visited network handles emergency calls. In fact, since most emergency calls are made from visited networks where the local emergency dial strings are the same as home dial strings, it will actually work most of the time in most networks. That's my argument for keeping it. Ergo, SHOULD Brian -----Original Message----- From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] Sent: Tuesday, October 14, 2008 8:58 AM To: ext Brian Rosen; ECRIT Subject: RE: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call Hi Brian, I know this challenge. Still, you have to put a must in there to make sure that the call is actually recognized. The architecture is very much build on the idea that either the end host or the VSP (directly or indirectly) get location from somewhere. As we learned at the previous emergency services workshops there are some sort of hacks one can do to bypass this need but they only work when there is a relationship between the VSP and the ISP. Currently, these things are being setup in individual countries and as such the question of recognizing emergency service numbers is essentially solved. Ciao Hannes >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net] >Sent: 14 October, 2008 15:51 >To: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' >Subject: RE: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: >Identifying an emergency call > >The problem is that proxies don't have location, and therefore >can't recognize them in most cases. Mobile systems with IMS, >where the visited network handles emergency calls would be an >exception, but a wireline IMS system which allowed nomading >would not be able to recognize local emergency dialstrings. >That is why SHOULD is appropriate. > >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >Sent: Tuesday, October 14, 2008 7:49 AM >To: ECRIT >Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying >an emergency call > > > ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If > the service provider always knows the location of the device, then > the service provider could recognize them. > > SP-2 Proxy servers SHOULD recognize emergency dial strings if for > some reason the endpoint does not recognize them. This cannot be > relied upon by the device if the service provider cannot always > determine the location of the device. > > >Looking at these 2 SHOULDs I can imagine cases where neither >one of them recognizes them. > >Wouldn't it be better to have a MUST with the 2nd requirement? >I would delete the 2nd sentence since in that case it would be >very difficult to route the call and to find the right PSAP as well. > >Comparing with the following requirement I recognize a mismatch: > > ED-19/INT-10/SP-13 Where proxies provide location on behalf of > endpoints, the service provider MUST ensure that either the end > device is provided with the local dial strings for its current > location (where the end device recognizes dial strings), or the > service provider proxy MUST detect the appropriate local >dial strings > at the time of the call. > > > > ED-5/SP-4 Local dial strings MUST be recognized. > >"MUST" be recognized by whom? See requirements above. > > > ED-6/SP-5 Devices MUST be able to be configured with the >home country > from which the home dial string(s) can be determined. > > >Shouldn't this read like >" >Devices MUST be have mechanisms to learn the user's home >emergency numbers. >" > > > ED-9 Endpoints SHOULD be able to have home dial strings provisioned > by configuration. > >I guess ED-9 should say something like "Endpoints SHOULD be >able to have >home dial strings dynamically provisioned." >To refer to the case that manual configuration may also be >used in order >to meet the previous requirements. > > > ED-11/SP-9 All emergency services specified in [RFC5031] MUST be > recognized. > >Should say something like: >" >All emergency services URNs specified in .... MUST be recognized. >" > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 06:25:47 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894903A6B03; Tue, 14 Oct 2008 06:25:47 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03A003A69C0 for ; Tue, 14 Oct 2008 06:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UuytFQGT9m0 for ; Tue, 14 Oct 2008 06:25:42 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 827B03A6B03 for ; Tue, 14 Oct 2008 06:25:41 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9EDPR3a028565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Oct 2008 15:25:27 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9EDPLa2029601; Tue, 14 Oct 2008 15:25:21 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 15:12:30 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 15:12:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 16:12:28 +0300 Message-ID: In-Reply-To: <04da01c92dfc$df5d4510$9e17cf30$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Which devices and services should support emergency calls Thread-Index: Ackt8uNyGncjF1p3QL6MPh/0uW5DrgACSktQAACTORA= References: <04da01c92dfc$df5d4510$9e17cf30$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Brian Rosen" , "ECRIT" X-OriginalArrivalTime: 14 Oct 2008 13:12:28.0202 (UTC) FILETIME=[81F4D8A0:01C92DFE] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081014152527-7381DBB0-28FF5E3A/0-0/0-15 X-purgate-size: 5149/0 Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Which devices and services should support emergency calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This does not sound like text that hints to when Phone BCP is applicable. Additionally, this "applicability" might change when regulators change their mind There are many different policies in different countries. The good thing: Most of these location determination requirements is outside the scope of our work anyway >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net] >Sent: 14 October, 2008 16:01 >To: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' >Subject: RE: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Which >devices and services should support emergency calls > >I think your reasoning is faulty. I think it IS important to >describe when -phonebcp is applicable. We do that in many >circumstances in the IETF. This not a deployment requirement, >it's an implementation requirement. There are no BCP police of course. > >I also think it is essential to provide guidance (in a BCP, >it's not a protocol specification) on location uncertainty. I >can add words about local regulation (perhaps, "some >jurisdictions have regulations governing >this") if you wish. > >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >Sent: Tuesday, October 14, 2008 7:49 AM >To: ECRIT >Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Which >devices and services should support emergency calls > > > ED-1 A device or application SHOULD support emergency calling if a > user could reasonably expect to be able to place a call for >help with > the device. > > SP-1 If a device or application expects to be able to place a call > for help, the service provider that supports it MUST facilitate > emergency calling. > > ED-2 Devices that create media sessions and exchange audio, video > and/or text, and have the capability to establish sessions to a wide > variety of addresses, and communicate over private IP >networks or the > Internet, SHOULD support emergency calls. > >This is nice text and nice requirements. >Still, I believe it would improve the credibility of the >document if we acknowledge the fact that we aren't regulating >the deployment. > >Maybe we can soften these requirements a bit and write something like. > >" >As end users are typically not aware of the details of the >technology they are using we below list the following >high-level goals for the implementation and deployment of >emergency services functionality: > > ED-1 / SP-1 It is RECOMMENDED that a device or application >supports emergency calling if a > user could reasonably expect to be able to place a call for >help with the device. > It is therefore RECOMMENDED that devices that create media >sessions and exchange > audio, video and/or text, and have the capability to >establish sessions to a wide > variety of communication end points, and deliver data over >private IP networks or the > Internet ,to support emergency calls. >" > > >The same is true for requirements listed below. In the past I >suggested to soften them a bit and to add references about >current regulation. >One, however, has to acknowledge that these numbers are not >applicable to all juristictions. > > >6.2.2. Access network "wire database" location information > > It is RECOMMENDED > that interior location be provided when spaces exceed approximately > 650 square meters. > >6.2.3. End-system measured location information > > ED-16/INT-7 Devices MAY support end-system measured location. > Uncertainty of less than 100 m with 95% confidence SHOULD be > available for dispatch. > > ED-17/INT-8/AN-8 Devices that support endpoint measuring of location > MUST have at least a coarse location capability (typically <1km > accuracy when not location hiding) for routing of calls. The > location mechanism MAY be a service provided by the access network. > >6.2.4. Network-measured location information > > AN-9 Access networks MAY provide network-measured location > determination. Wireless access network which do not support network > measured location MUST require that all devices connected to the > network have end-system measured location. Uncertainty of less than > 100 m with 95% confidence SHOULD be available for dispatch. > > AN-10 Access networks that provide network measured location MUST > have at least a coarse location (typically <1km when not location > hiding) capability at all times for routing of calls. > > AN-11 Access networks with range of <10 meters (e.g. personnal area > networks such as Bluetooth MUST provide a location to mobile devices > connected to them. The location provided SHOULD be that of the > access point location unless a more accurate mechanism is provided. > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 07:06:41 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33A2928C17C; Tue, 14 Oct 2008 07:06:41 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0A128C11A for ; Tue, 14 Oct 2008 07:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-qcVXPAjlK4 for ; Tue, 14 Oct 2008 07:06:33 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id BED2828C17C for ; Tue, 14 Oct 2008 07:06:33 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KpkXr1XyT-0007PA; Tue, 14 Oct 2008 10:06:44 -0400 Message-ID: <0FDEE96E8FF64F70BAA4FE5FB5E64442@china.huawei.com> From: "Spencer Dawkins" To: "ECRIT" References: Date: Tue, 14 Oct 2008 09:06:34 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+0jJWAClw3phrs7r4bTG3QPbxPFufe7/8OIJu 1txUp/q8RAs7cmrBhy0Krt9gHgtDtZCA92V2yYSZc455oawKvY YjKsvYEzT0oDWaX6yhksimO75Ik/nXAv7B5qOLKxPY= Subject: Re: [Ecrit] ECRIT WG Rechartering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi, Hannes, Could you say anything about the future of authority-to-citizen emergency services work mentioned during the "potential charter" discussion in Dublin? Thanks, Spencer > Here is a first proposal for the ECRIT WG rechartering based on the > discussions we had around IETF#72. > For the moment, I have put 3 additional documents onto the charter: > http://tools.ietf.org/id/draft-polk-ecrit-local-emergency-rph-namespace- > 03.txt > http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc-00.txt > http://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00.txt > > Regarding the following two documents > http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.txt > http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-00.txt > I am waiting for additional feedback from the draft authors on how they > perceive these documents should be progressed through the IETF, see my > mail here: > http://www.ietf.org/mail-archive/web/ecrit/current/msg05518.html > > Please take a look at it and give me feedback till the 21st October > 2008. > > ------------------------------------------------------------------------ > --------------------------- > > Emergency Context Resolution with Internet Technologies (ecrit) > > Description of Working Group: > > In a number of areas, the public switched telephone network (PSTN) has > been configured to recognize an explicitly specified number (commonly > one that is short and easily memorized) as a call for emergency > services. These numbers (e.g. 911, 112) relate to an emergency > service context and depend on a broad, regional configuration of > service contact methods and a geographically-constrained context of > service delivery. These calls are intended to be delivered to special > call centers equipped to manage emergency response. Successful > delivery of an emergency service call within those systems requires > both an association of the physical location of the originator with an > appropriate emergency service center and call routing to deliver the > call to the center. > > Calls placed using Internet technologies do not use the same systems > to achieve those goals, and the common use of overlay networks and > tunnels (either as VPNs or for mobility) makes meeting them more > challenging. There are, however, Internet technologies available to > describe location and to manage call routing. This working group will > describe when these may be appropriate and how they may be used. This > group is considering emergency services calls which might be made by > any user of the Internet, as opposed to government or military > services that may impose very different authentication and routing > requirements. > > While this group anticipates a close working relationship with groups > such as NENA and ETSI EMTEL, any solution presented must be useful > regardless of jurisdiction, and it must be possible to use without a > single, central authority. Further, it must be possible for multiple > delegations within a jurisdiction to be handled independently, as call > routing for specific emergency types may be independent. > > The group will work on the maintainance of the > Location-to-Service Translation (LoST) protocol, on (emergency services > and non-emergency services related)extensions to LoST to the as well as > on necessary extension related to emergency call routing. > > This working group cares about privacy and security concerns, and will > address them within its documents. > > Goals and Milestones: > > Done An Informational RFC containing terminology definitions > and the requirements > Done An Informational document describing the threats and > security considerations > Done A Standards Track RFC describing how to identify a > session set-up request is to an emergency response center > Done A Standards Track RFC describing how to route an > emergency call based on location information > Done An Informational document describing the Mapping > Protocol Architecture > Dec 2008 An Informational document describing the ECRIT Framework > Dec 2008 A BCP document describing the emergency call support for > devices > Oct 2008 An Informational document providing a problem statement > and requirements for location hiding > Oct 2008 An Informational document specifying how to express > holes in LoST service boundaries > Dec 2008 An Informational document describing how to synchronize > LoST servers > Jan 2009 A Standards Track RFC registering a SIP Resource > Priority Header Namespace for Local Emergency Communications > Feb 2009 An Informational document describing how imprecise > location is used for emergency context resolution > Feb 2009 A Standards Track RFC containing Location-to-Service > Translation Protocol (LoST) Extensions > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 08:27:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF2CD3A681D; Tue, 14 Oct 2008 08:27:25 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 411EA3A6C03 for ; Tue, 14 Oct 2008 08:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emJoij6nC5Ny for ; Tue, 14 Oct 2008 08:27:23 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 1F4F63A6C09 for ; Tue, 14 Oct 2008 08:27:23 -0700 (PDT) Received: from dyn-209-2-231-113.dyn.columbia.edu (dyn-209-2-231-113.dyn.columbia.edu [209.2.231.113]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9EFRAp6005551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Oct 2008 11:27:10 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <04d501c92dfa$f92ab790$eb8026b0$@net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 14 Oct 2008 11:27:09 -0400 References: <04d501c92dfa$f92ab790$eb8026b0$@net> X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: 'ECRIT' , nena-i2_5@listserv.neustar.biz, "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , nena-ltd@lists.cs.columbia.edu Subject: Re: [Ecrit] [NENA-ltd] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Note that proxies, at least if you follow the SIP definition, aren't handling BYEs at all. I assume you are talking about B2BUAs, right? On Oct 14, 2008, at 8:47 AM, Brian Rosen wrote: > You are ignoring the observation that refusing a BYE means all > proxies in > the path have to be aware that this is possible. That is much more of > change than we can probably expect. > > Not sending a BYE doesn't have that problem. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of > James M. Polk > Sent: Tuesday, October 14, 2008 2:23 AM > To: Tschofenig, Hannes (NSN - FI/Espoo); ext Ted Hardie; > nena-i2_5@listserv.neustar.biz; nena-ltd@lists.cs.columbia.edu; ECRIT > Subject: Re: [Ecrit] Design Team Status Update > > At 12:48 AM 10/14/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>> Ultimately, you want to overcome implementer's universal mode >>> of disconnecting (or removing) state awareness once a UA has >>> sent a BYE when this is not proper SIP procedures. SIP >>> procedures are to wait for the response before releasing the >>> state of the call. If proper procedures were followed, none >>> of this would be an issue, because the BYE would merely need >>> to be refused with a 488 (Not Acceptable Here) to address this. >> >> Too early for solution discussions. > > ah, but this one is specified in RFC 3261 - which (way) predates ECRIT > > therefore this "solution" exists already. This is not a new one > > James > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Nena-ltd mailing list > Nena-ltd@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/nena-ltd _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 08:34:59 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47E0528C1CF; Tue, 14 Oct 2008 08:34:59 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18F6728C1CF for ; Tue, 14 Oct 2008 08:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2AYnfTxV5Ty for ; Tue, 14 Oct 2008 08:34:57 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id ECDB93A6BF1 for ; Tue, 14 Oct 2008 08:34:56 -0700 (PDT) Received: from dhcp89.cs.columbia.edu (dhcp89.cs.columbia.edu [128.59.22.30]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9EFZOLX008120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Oct 2008 11:35:24 -0400 (EDT) Message-Id: <76D44EF2-93E3-4469-AEE7-6C3F7C0CECFA@cs.columbia.edu> From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <04d601c92dfb$7668a320$6339e960$@net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 14 Oct 2008 11:35:23 -0400 References: <04d601c92dfb$7668a320$6339e960$@net> X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , 'ECRIT' Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org In general, we SHOULD always qualify the SHOULD with the condition of when the obligation cannot be met. ED-3 kind of does this, but the causal connection is not obvious. Thus, we want something "If a proxy knows the caller's location, it MUST recognize the local emergency dial string. If not, ?" We need to then decide whether the ? should be - proxy can guess at the location and recognize based on a guess - recognize certain numbers always (e.g., those numbers where most of its customers reside) - never recognize anything (and it could be all of the above). This provides much more useful guidance to implementors than a SHOULD. Henning On Oct 14, 2008, at 8:50 AM, Brian Rosen wrote: > The problem is that proxies don't have location, and therefore can't > recognize them in most cases. Mobile systems with IMS, where the > visited > network handles emergency calls would be an exception, but a > wireline IMS > system which allowed nomading would not be able to recognize local > emergency > dialstrings. That is why SHOULD is appropriate. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of > Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Tuesday, October 14, 2008 7:49 AM > To: ECRIT > Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an > emergency > call > > > ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If > the service provider always knows the location of the device, then > the service provider could recognize them. > > SP-2 Proxy servers SHOULD recognize emergency dial strings if for > some reason the endpoint does not recognize them. This cannot be > relied upon by the device if the service provider cannot always > determine the location of the device. > > > Looking at these 2 SHOULDs I can imagine cases where neither one of > them > recognizes them. > > Wouldn't it be better to have a MUST with the 2nd requirement? I would > delete the 2nd sentence since in that case it would be very > difficult to > route the call and to find the right PSAP as well. > > Comparing with the following requirement I recognize a mismatch: > > ED-19/INT-10/SP-13 Where proxies provide location on behalf of > endpoints, the service provider MUST ensure that either the end > device is provided with the local dial strings for its current > location (where the end device recognizes dial strings), or the > service provider proxy MUST detect the appropriate local dial > strings > at the time of the call. > > > > ED-5/SP-4 Local dial strings MUST be recognized. > > "MUST" be recognized by whom? See requirements above. > > > ED-6/SP-5 Devices MUST be able to be configured with the home > country > from which the home dial string(s) can be determined. > > > Shouldn't this read like > " > Devices MUST be have mechanisms to learn the user's home emergency > numbers. > " > > > ED-9 Endpoints SHOULD be able to have home dial strings provisioned > by configuration. > > I guess ED-9 should say something like "Endpoints SHOULD be able to > have > home dial strings dynamically provisioned." > To refer to the case that manual configuration may also be used in > order > to meet the previous requirements. > > > ED-11/SP-9 All emergency services specified in [RFC5031] MUST be > recognized. > > Should say something like: > " > All emergency services URNs specified in .... MUST be recognized. > " > > _______________________________________________ > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 08:38:09 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793503A6A7B; Tue, 14 Oct 2008 08:38:09 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D335E3A659A for ; Tue, 14 Oct 2008 08:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqol2WyVq0Ky for ; Tue, 14 Oct 2008 08:38:03 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 6FE853A67A3 for ; Tue, 14 Oct 2008 08:38:03 -0700 (PDT) Received: from dhcp89.cs.columbia.edu (dhcp89.cs.columbia.edu [128.59.22.30]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9EFc9Td020414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Oct 2008 11:38:10 -0400 (EDT) Message-Id: <39786451-A62D-4B0B-B924-FB6E6D9EC412@cs.columbia.edu> From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <04d801c92dfb$d3765a80$7a630f80$@net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 14 Oct 2008 11:38:09 -0400 References: <04d801c92dfb$d3765a80$7a630f80$@net> X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , 'ECRIT' Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Media X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org SIPConnect has versions, so maybe we should either punt on these for now or we could make some of these aspirational. In other words, if you are spec'ing a new system, you should ask your vendor about this, but it may be on the product roadmap rather than something we expect today. This still tells the industry where we want to go, without raising the bar unreasonably for today's products. Henning On Oct 14, 2008, at 8:53 AM, Brian Rosen wrote: > There are so many things in phonebcp that are not implemented, > adding SRTP, > and then insisting on SDES is really dooming interoperability. I do > think, > generally, that encrypting the media is a good thing, but I can't > even see > "SHOULD". > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of > Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Tuesday, October 14, 2008 7:49 AM > To: ECRIT > Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Media > > Looking at Section 14 about media I was wondering whether the usage of > SRTP wouldn't make sense. > For key management I would go for SDES. > > What do you think? > > > _______________________________________________ > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 08:41:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DD1C3A6BCC; Tue, 14 Oct 2008 08:41:32 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799833A6BAD for ; Tue, 14 Oct 2008 08:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEGEE7QKA5u5 for ; Tue, 14 Oct 2008 08:41:27 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 765E43A68F7 for ; Tue, 14 Oct 2008 08:41:27 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Kpm1l-0006y0-Un; Tue, 14 Oct 2008 10:41:42 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" References: <04d601c92dfb$7668a320$6339e960$@net> <76D44EF2-93E3-4469-AEE7-6C3F7C0CECFA@cs.columbia.edu> In-Reply-To: <76D44EF2-93E3-4469-AEE7-6C3F7C0CECFA@cs.columbia.edu> Date: Tue, 14 Oct 2008 11:41:40 -0400 Message-ID: <009f01c92e13$5d568f60$1803ae20$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckuEne+0TWQcUBuQyafdlWE/GOkNwAAKziQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , 'ECRIT' Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yes, you are correct. I'd suggest a) and b) in your list. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Tuesday, October 14, 2008 11:35 AM To: Brian Rosen Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call In general, we SHOULD always qualify the SHOULD with the condition of when the obligation cannot be met. ED-3 kind of does this, but the causal connection is not obvious. Thus, we want something "If a proxy knows the caller's location, it MUST recognize the local emergency dial string. If not, ?" We need to then decide whether the ? should be - proxy can guess at the location and recognize based on a guess - recognize certain numbers always (e.g., those numbers where most of its customers reside) - never recognize anything (and it could be all of the above). This provides much more useful guidance to implementors than a SHOULD. Henning On Oct 14, 2008, at 8:50 AM, Brian Rosen wrote: > The problem is that proxies don't have location, and therefore can't > recognize them in most cases. Mobile systems with IMS, where the > visited > network handles emergency calls would be an exception, but a > wireline IMS > system which allowed nomading would not be able to recognize local > emergency > dialstrings. That is why SHOULD is appropriate. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of > Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Tuesday, October 14, 2008 7:49 AM > To: ECRIT > Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an > emergency > call > > > ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If > the service provider always knows the location of the device, then > the service provider could recognize them. > > SP-2 Proxy servers SHOULD recognize emergency dial strings if for > some reason the endpoint does not recognize them. This cannot be > relied upon by the device if the service provider cannot always > determine the location of the device. > > > Looking at these 2 SHOULDs I can imagine cases where neither one of > them > recognizes them. > > Wouldn't it be better to have a MUST with the 2nd requirement? I would > delete the 2nd sentence since in that case it would be very > difficult to > route the call and to find the right PSAP as well. > > Comparing with the following requirement I recognize a mismatch: > > ED-19/INT-10/SP-13 Where proxies provide location on behalf of > endpoints, the service provider MUST ensure that either the end > device is provided with the local dial strings for its current > location (where the end device recognizes dial strings), or the > service provider proxy MUST detect the appropriate local dial > strings > at the time of the call. > > > > ED-5/SP-4 Local dial strings MUST be recognized. > > "MUST" be recognized by whom? See requirements above. > > > ED-6/SP-5 Devices MUST be able to be configured with the home > country > from which the home dial string(s) can be determined. > > > Shouldn't this read like > " > Devices MUST be have mechanisms to learn the user's home emergency > numbers. > " > > > ED-9 Endpoints SHOULD be able to have home dial strings provisioned > by configuration. > > I guess ED-9 should say something like "Endpoints SHOULD be able to > have > home dial strings dynamically provisioned." > To refer to the case that manual configuration may also be used in > order > to meet the previous requirements. > > > ED-11/SP-9 All emergency services specified in [RFC5031] MUST be > recognized. > > Should say something like: > " > All emergency services URNs specified in .... MUST be recognized. > " > > _______________________________________________ > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 08:53:07 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760BE3A699E; Tue, 14 Oct 2008 08:53:07 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CD793A6A7B for ; Tue, 14 Oct 2008 08:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Xc+-td0329j for ; Tue, 14 Oct 2008 08:53:04 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id A11C73A6862 for ; Tue, 14 Oct 2008 08:53:03 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9EFr1Dx002862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Oct 2008 11:53:02 -0400 (EDT) Message-Id: <518751F4-319E-44F9-ACF1-BA944EF91028@cs.columbia.edu> From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <009f01c92e13$5d568f60$1803ae20$@net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 14 Oct 2008 11:53:04 -0400 References: <04d601c92dfb$7668a320$6339e960$@net> <76D44EF2-93E3-4469-AEE7-6C3F7C0CECFA@cs.columbia.edu> <009f01c92e13$5d568f60$1803ae20$@net> X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , 'ECRIT' Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org (a) and (b) can probably be combined into one case, as they essentially involve guessing. Something like --- If a proxy can reasonably guess the location of the caller, it MAY use that location to recognize applicable emergency numbers. For example, a proxy may base this estimate on the fact that most of the VSPs customers reside in a small set of countries. --- (Since we can't dictate what reasonable is, anything stronger than a MAY doesn't really help.) On Oct 14, 2008, at 11:41 AM, Brian Rosen wrote: > Yes, you are correct. > > I'd suggest a) and b) in your list. > > Brian > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, October 14, 2008 11:35 AM > To: Brian Rosen > Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' > Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an > emergency call > > In general, we SHOULD always qualify the SHOULD with the condition of > when the obligation cannot be met. ED-3 kind of does this, but the > causal connection is not obvious. Thus, we want something > > "If a proxy knows the caller's location, it MUST recognize the local > emergency dial string. If not, ?" > > We need to then decide whether the ? should be > > - proxy can guess at the location and recognize based on a guess > - recognize certain numbers always (e.g., those numbers where most of > its customers reside) > - never recognize anything > > (and it could be all of the above). > > This provides much more useful guidance to implementors than a SHOULD. > > Henning > > On Oct 14, 2008, at 8:50 AM, Brian Rosen wrote: > >> The problem is that proxies don't have location, and therefore can't >> recognize them in most cases. Mobile systems with IMS, where the >> visited >> network handles emergency calls would be an exception, but a >> wireline IMS >> system which allowed nomading would not be able to recognize local >> emergency >> dialstrings. That is why SHOULD is appropriate. >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf Of >> Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Tuesday, October 14, 2008 7:49 AM >> To: ECRIT >> Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an >> emergency >> call >> >> >> ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If >> the service provider always knows the location of the device, then >> the service provider could recognize them. >> >> SP-2 Proxy servers SHOULD recognize emergency dial strings if for >> some reason the endpoint does not recognize them. This cannot be >> relied upon by the device if the service provider cannot always >> determine the location of the device. >> >> >> Looking at these 2 SHOULDs I can imagine cases where neither one of >> them >> recognizes them. >> >> Wouldn't it be better to have a MUST with the 2nd requirement? I >> would >> delete the 2nd sentence since in that case it would be very >> difficult to >> route the call and to find the right PSAP as well. >> >> Comparing with the following requirement I recognize a mismatch: >> >> ED-19/INT-10/SP-13 Where proxies provide location on behalf of >> endpoints, the service provider MUST ensure that either the end >> device is provided with the local dial strings for its current >> location (where the end device recognizes dial strings), or the >> service provider proxy MUST detect the appropriate local dial >> strings >> at the time of the call. >> >> >> >> ED-5/SP-4 Local dial strings MUST be recognized. >> >> "MUST" be recognized by whom? See requirements above. >> >> >> ED-6/SP-5 Devices MUST be able to be configured with the home >> country >> from which the home dial string(s) can be determined. >> >> >> Shouldn't this read like >> " >> Devices MUST be have mechanisms to learn the user's home emergency >> numbers. >> " >> >> >> ED-9 Endpoints SHOULD be able to have home dial strings provisioned >> by configuration. >> >> I guess ED-9 should say something like "Endpoints SHOULD be able to >> have >> home dial strings dynamically provisioned." >> To refer to the case that manual configuration may also be used in >> order >> to meet the previous requirements. >> >> >> ED-11/SP-9 All emergency services specified in [RFC5031] MUST be >> recognized. >> >> Should say something like: >> " >> All emergency services URNs specified in .... MUST be recognized. >> " >> >> _______________________________________________ >> 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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 09:05:22 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FFB73A6B01; Tue, 14 Oct 2008 09:05:22 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8103A6830 for ; Tue, 14 Oct 2008 09:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhEuD0qyDtGK for ; Tue, 14 Oct 2008 09:05:21 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 1D2BC3A6B01 for ; Tue, 14 Oct 2008 09:05:21 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KpmPC-0008Uq-7K; Tue, 14 Oct 2008 11:06:03 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" References: <04d601c92dfb$7668a320$6339e960$@net> <76D44EF2-93E3-4469-AEE7-6C3F7C0CECFA@cs.columbia.edu> <009f01c92e13$5d568f60$1803ae20$@net> <518751F4-319E-44F9-ACF1-BA944EF91028@cs.columbia.edu> In-Reply-To: <518751F4-319E-44F9-ACF1-BA944EF91028@cs.columbia.edu> Date: Tue, 14 Oct 2008 12:05:57 -0400 Message-ID: <00bf01c92e16$c5c46330$514d2990$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckuFO70CU7jnOJqSPmxc/XNCo+/9wAAccUA Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , 'ECRIT' Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Works for me -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Tuesday, October 14, 2008 11:53 AM To: Brian Rosen Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call (a) and (b) can probably be combined into one case, as they essentially involve guessing. Something like --- If a proxy can reasonably guess the location of the caller, it MAY use that location to recognize applicable emergency numbers. For example, a proxy may base this estimate on the fact that most of the VSPs customers reside in a small set of countries. --- (Since we can't dictate what reasonable is, anything stronger than a MAY doesn't really help.) On Oct 14, 2008, at 11:41 AM, Brian Rosen wrote: > Yes, you are correct. > > I'd suggest a) and b) in your list. > > Brian > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, October 14, 2008 11:35 AM > To: Brian Rosen > Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' > Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an > emergency call > > In general, we SHOULD always qualify the SHOULD with the condition of > when the obligation cannot be met. ED-3 kind of does this, but the > causal connection is not obvious. Thus, we want something > > "If a proxy knows the caller's location, it MUST recognize the local > emergency dial string. If not, ?" > > We need to then decide whether the ? should be > > - proxy can guess at the location and recognize based on a guess > - recognize certain numbers always (e.g., those numbers where most of > its customers reside) > - never recognize anything > > (and it could be all of the above). > > This provides much more useful guidance to implementors than a SHOULD. > > Henning > > On Oct 14, 2008, at 8:50 AM, Brian Rosen wrote: > >> The problem is that proxies don't have location, and therefore can't >> recognize them in most cases. Mobile systems with IMS, where the >> visited >> network handles emergency calls would be an exception, but a >> wireline IMS >> system which allowed nomading would not be able to recognize local >> emergency >> dialstrings. That is why SHOULD is appropriate. >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf Of >> Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Tuesday, October 14, 2008 7:49 AM >> To: ECRIT >> Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an >> emergency >> call >> >> >> ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If >> the service provider always knows the location of the device, then >> the service provider could recognize them. >> >> SP-2 Proxy servers SHOULD recognize emergency dial strings if for >> some reason the endpoint does not recognize them. This cannot be >> relied upon by the device if the service provider cannot always >> determine the location of the device. >> >> >> Looking at these 2 SHOULDs I can imagine cases where neither one of >> them >> recognizes them. >> >> Wouldn't it be better to have a MUST with the 2nd requirement? I >> would >> delete the 2nd sentence since in that case it would be very >> difficult to >> route the call and to find the right PSAP as well. >> >> Comparing with the following requirement I recognize a mismatch: >> >> ED-19/INT-10/SP-13 Where proxies provide location on behalf of >> endpoints, the service provider MUST ensure that either the end >> device is provided with the local dial strings for its current >> location (where the end device recognizes dial strings), or the >> service provider proxy MUST detect the appropriate local dial >> strings >> at the time of the call. >> >> >> >> ED-5/SP-4 Local dial strings MUST be recognized. >> >> "MUST" be recognized by whom? See requirements above. >> >> >> ED-6/SP-5 Devices MUST be able to be configured with the home >> country >> from which the home dial string(s) can be determined. >> >> >> Shouldn't this read like >> " >> Devices MUST be have mechanisms to learn the user's home emergency >> numbers. >> " >> >> >> ED-9 Endpoints SHOULD be able to have home dial strings provisioned >> by configuration. >> >> I guess ED-9 should say something like "Endpoints SHOULD be able to >> have >> home dial strings dynamically provisioned." >> To refer to the case that manual configuration may also be used in >> order >> to meet the previous requirements. >> >> >> ED-11/SP-9 All emergency services specified in [RFC5031] MUST be >> recognized. >> >> Should say something like: >> " >> All emergency services URNs specified in .... MUST be recognized. >> " >> >> _______________________________________________ >> 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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 09:12:09 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E02AA3A6BDD; Tue, 14 Oct 2008 09:12:09 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D713A6BDD for ; Tue, 14 Oct 2008 09:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRBQy7EsNezw for ; Tue, 14 Oct 2008 09:12:08 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.113]) by core3.amsl.com (Postfix) with ESMTP id 6F0E73A6B3F for ; Tue, 14 Oct 2008 09:12:07 -0700 (PDT) Received: (qmail 28948 invoked from network); 14 Oct 2008 16:12:33 -0000 Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 14 Oct 2008 16:12:33 -0000 Received: (qmail 9635 invoked from network); 14 Oct 2008 16:12:27 -0000 Received: from h16n1fls34o265.telia.com (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[213.64.232.16]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with SMTP for ; 14 Oct 2008 16:12:27 -0000 From: "Gunnar Hellstrom" To: "'Brian Rosen'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: <04d801c92dfb$d3765a80$7a630f80$@net> Date: Tue, 14 Oct 2008 18:12:34 +0200 Message-ID: <008601c92e17$ab6e5530$2fd1bc53@GunnarH> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ackt8ugQefYJ96oQSE2zsXvdG5crSgACLTCAAAWWgTA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <04d801c92dfb$d3765a80$7a630f80$@net> Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Media X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Interoperability with emergency services is a powerful harmonizing factor. There is an apparent need to harmonize media security. By the reference to RFC 4504 in section 9, we already have a vague recommendation to implement SRTP, so I suggest to continue on that track and have a SHOULD for SRTP in ecrit-phonebcp and a MUST in ecrit-framework. I am less in phase with how the current key management discussion is, but recommend to make a decision even there for a SHOULD for one specific mechanism. It is much more important to decide on one harmonised recommendation than to discuss which mecanism is the perfect one. This is what RFC 4504 says: --------------------------------------------- 4.3. Privacy Media Encryption Secure RTP (SRTP) [62] MAY be used for the encryption of media such as audio, text, and video, after the keying information has been passed by SIP signaling. Instant messaging MAY be protected end-to-end using S/MIME. ---------------------------------------------- / Gunnar -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, October 14, 2008 2:53 PM To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Media There are so many things in phonebcp that are not implemented, adding SRTP, and then insisting on SDES is really dooming interoperability. I do think, generally, that encrypting the media is a good thing, but I can't even see "SHOULD". Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Tuesday, October 14, 2008 7:49 AM To: ECRIT Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Media Looking at Section 14 about media I was wondering whether the usage of SRTP wouldn't make sense. For key management I would go for SDES. What do you think? _______________________________________________ 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 __________ NOD32 3520 (20081014) Information __________ Detta meddelande dr genomsvkt av NOD32 Antivirus. http://www.nod32.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 10:03:16 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45BEC3A6900; Tue, 14 Oct 2008 10:03:16 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 551E53A6B3E for ; Tue, 14 Oct 2008 10:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPoa1NIl+iYV for ; Tue, 14 Oct 2008 10:03:13 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E3D6D3A6900 for ; Tue, 14 Oct 2008 10:03:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,410,1220227200"; d="scan'208";a="24250081" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Oct 2008 17:02:54 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9EH2sgn008922; Tue, 14 Oct 2008 13:02:54 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9EH2sRa007215; Tue, 14 Oct 2008 17:02:54 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 13:02:54 -0400 Received: from [10.116.195.117] ([10.116.195.117]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 13:02:34 -0400 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Tue, 14 Oct 2008 13:02:31 -0400 From: Marc Linsner To: Brian Rosen , , , "'ECRIT'" Message-ID: Thread-Topic: [NENA-ltd] [Ecrit] Design Team Status Update Thread-Index: AcktxT9EwYAGd2nVRU+U3UcuXB4e3gANXFJQAAj9ITA= In-Reply-To: <04d501c92dfa$f92ab790$eb8026b0$@net> Mime-version: 1.0 X-OriginalArrivalTime: 14 Oct 2008 17:02:34.0456 (UTC) FILETIME=[A7200580:01C92E1E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1834; t=1224003774; x=1224867774; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[NENA-ltd]=20[Ecrit]=20Design=20Team=20 Status=20Update |Sender:=20 |To:=20Brian=20Rosen=20,=20,=0A=20=20=20=20=20=20=20=20,=20=22'ECRIT'=22=20; bh=7bs+MZzXrd8sIEelpN7mVccGxKJQuq7FNdW365RdL0o=; b=f57ITT4fmuc87VO9IW0azUPBG7linQ7K78TRqsjm+lN8YAaebaOM+y/avY tzfZzaCdmmEWM6pytMk0tnFWDZ1qv4HkWgNqw7BXFqctDyP1OCLjiKXBD6Ze qh1j8utv0I; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Ecrit] [NENA-ltd] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, So creating more mechanism that is ignored by implementers is better? -Marc- On 10/14/08 8:47 AM, "Brian Rosen" wrote: > You are ignoring the observation that refusing a BYE means all proxies in > the path have to be aware that this is possible. That is much more of > change than we can probably expect. > > Not sending a BYE doesn't have that problem. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Tuesday, October 14, 2008 2:23 AM > To: Tschofenig, Hannes (NSN - FI/Espoo); ext Ted Hardie; > nena-i2_5@listserv.neustar.biz; nena-ltd@lists.cs.columbia.edu; ECRIT > Subject: Re: [Ecrit] Design Team Status Update > > At 12:48 AM 10/14/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>> Ultimately, you want to overcome implementer's universal mode >>> of disconnecting (or removing) state awareness once a UA has >>> sent a BYE when this is not proper SIP procedures. SIP >>> procedures are to wait for the response before releasing the >>> state of the call. If proper procedures were followed, none >>> of this would be an issue, because the BYE would merely need >>> to be refused with a 488 (Not Acceptable Here) to address this. >> >> Too early for solution discussions. > > ah, but this one is specified in RFC 3261 - which (way) predates ECRIT > > therefore this "solution" exists already. This is not a new one > > James > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Nena-ltd mailing list > Nena-ltd@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/nena-ltd _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 10:13:01 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EFE528C103; Tue, 14 Oct 2008 10:13:01 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8592C28C103 for ; Tue, 14 Oct 2008 10:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKZiY2lEwnAR for ; Tue, 14 Oct 2008 10:12:56 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 1A12928C0E5 for ; Tue, 14 Oct 2008 10:12:56 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KpnRv-0004eX-5s; Tue, 14 Oct 2008 12:12:48 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , , , "'ECRIT'" References: <04d501c92dfa$f92ab790$eb8026b0$@net> In-Reply-To: Date: Tue, 14 Oct 2008 13:12:44 -0400 Message-ID: <00e401c92e20$1577e560$4067b020$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcktxT9EwYAGd2nVRU+U3UcuXB4e3gANXFJQAAj9ITAAADDL8A== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] [NENA-ltd] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org We have a shot at getting phone vendors to pay attention. The more parts I have to get upgraded, and the more difficult the upgrades, the less likely. I talked with several sip experts about the "cancel the bye" idea. While feasible, it's a major stack change. Doing something like enabling a feature because it's in Required is a heck of a lot easier. Getting just phones to do something as opposed to phones + B2BUAs and other middleboxes is a lot easier Also, you the failure mechanisms for the middleboxes is bad. If they don't understand the "cancel the BYE", then they tear down the connections as soon as they see the BYE. But they don't take the tag away in Supported - so the PSAP and the phone think it's gonna work, but it actually breaks. Yuck. Brian -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Tuesday, October 14, 2008 1:03 PM To: Brian Rosen; nena-i2_5@listserv.neustar.biz; nena-ltd@lists.cs.columbia.edu; 'ECRIT' Subject: Re: [NENA-ltd] [Ecrit] Design Team Status Update Brian, So creating more mechanism that is ignored by implementers is better? -Marc- On 10/14/08 8:47 AM, "Brian Rosen" wrote: > You are ignoring the observation that refusing a BYE means all proxies in > the path have to be aware that this is possible. That is much more of > change than we can probably expect. > > Not sending a BYE doesn't have that problem. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Tuesday, October 14, 2008 2:23 AM > To: Tschofenig, Hannes (NSN - FI/Espoo); ext Ted Hardie; > nena-i2_5@listserv.neustar.biz; nena-ltd@lists.cs.columbia.edu; ECRIT > Subject: Re: [Ecrit] Design Team Status Update > > At 12:48 AM 10/14/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>> Ultimately, you want to overcome implementer's universal mode >>> of disconnecting (or removing) state awareness once a UA has >>> sent a BYE when this is not proper SIP procedures. SIP >>> procedures are to wait for the response before releasing the >>> state of the call. If proper procedures were followed, none >>> of this would be an issue, because the BYE would merely need >>> to be refused with a 488 (Not Acceptable Here) to address this. >> >> Too early for solution discussions. > > ah, but this one is specified in RFC 3261 - which (way) predates ECRIT > > therefore this "solution" exists already. This is not a new one > > James > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Nena-ltd mailing list > Nena-ltd@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/nena-ltd _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 10:29:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1385F3A677E; Tue, 14 Oct 2008 10:29:25 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC04A3A677E for ; Tue, 14 Oct 2008 10:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.405 X-Spam-Level: X-Spam-Status: No, score=-6.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7Xq18b85nnc for ; Tue, 14 Oct 2008 10:29:22 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6E4273A659A for ; Tue, 14 Oct 2008 10:29:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,410,1220227200"; d="scan'208";a="24254388" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Oct 2008 17:29:09 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9EHT927027288; Tue, 14 Oct 2008 13:29:09 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9EHT9f1016932; Tue, 14 Oct 2008 17:29:09 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 13:29:09 -0400 Received: from [10.116.195.117] ([10.116.195.117]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 13:28:16 -0400 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Tue, 14 Oct 2008 13:28:13 -0400 From: Marc Linsner To: Brian Rosen , , , "'ECRIT'" Message-ID: Thread-Topic: [NENA-ltd] [Ecrit] Design Team Status Update Thread-Index: AcktxT9EwYAGd2nVRU+U3UcuXB4e3gANXFJQAAj9ITAAADDL8AAAtPuq In-Reply-To: <00e401c92e20$1577e560$4067b020$@net> Mime-version: 1.0 X-OriginalArrivalTime: 14 Oct 2008 17:28:16.0503 (UTC) FILETIME=[3E41B870:01C92E22] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3283; t=1224005349; x=1224869349; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[NENA-ltd]=20[Ecrit]=20Design=20Team=20 Status=20Update |Sender:=20 |To:=20Brian=20Rosen=20,=20,=0A=20=20=20=20=20=20=20=20,=20=22'ECRIT'=22=20; bh=28dJxqMIG0L/pglnk+01kfGG9tXYS3QARa5vdWA0Ue4=; b=hl8rzLdxRaRaN3zFVpEe40SIAm6QT6Ixc0X4H629aInC6fLYDAQLenRHBN 3v7+fiQ2Sdysaa57cn3+dh4tF2l1el/TjR2EjuzlfMO7krsF+3p1XW4bh2rq UIOiADbXYB; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Ecrit] [NENA-ltd] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, On 10/14/08 1:12 PM, "Brian Rosen" wrote: > We have a shot at getting phone vendors to pay attention. The more parts I > have to get upgraded, and the more difficult the upgrades, the less likely. > I talked with several sip experts about the "cancel the bye" idea. While > feasible, it's a major stack change. > > Doing something like enabling a feature because it's in Required is a heck > of a lot easier. > > Getting just phones to do something as opposed to phones + B2BUAs and other > middleboxes is a lot easier Please explain why a B2BUA would not be involved in your 'existing Supported/Required option negotiation mechanism'. Please expand what middleboxes your are talking about. -Marc- > > Also, you the failure mechanisms for the middleboxes is bad. If they don't > understand the "cancel the BYE", then they tear down the connections as soon > as they see the BYE. But they don't take the tag away in Supported - so the > PSAP and the phone think it's gonna work, but it actually breaks. Yuck. > > Brian > > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Tuesday, October 14, 2008 1:03 PM > To: Brian Rosen; nena-i2_5@listserv.neustar.biz; > nena-ltd@lists.cs.columbia.edu; 'ECRIT' > Subject: Re: [NENA-ltd] [Ecrit] Design Team Status Update > > Brian, > > So creating more mechanism that is ignored by implementers is better? > > -Marc- > > > > On 10/14/08 8:47 AM, "Brian Rosen" wrote: > >> You are ignoring the observation that refusing a BYE means all proxies in >> the path have to be aware that this is possible. That is much more of >> change than we can probably expect. >> >> Not sending a BYE doesn't have that problem. >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> James M. Polk >> Sent: Tuesday, October 14, 2008 2:23 AM >> To: Tschofenig, Hannes (NSN - FI/Espoo); ext Ted Hardie; >> nena-i2_5@listserv.neustar.biz; nena-ltd@lists.cs.columbia.edu; ECRIT >> Subject: Re: [Ecrit] Design Team Status Update >> >> At 12:48 AM 10/14/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>> Ultimately, you want to overcome implementer's universal mode >>>> of disconnecting (or removing) state awareness once a UA has >>>> sent a BYE when this is not proper SIP procedures. SIP >>>> procedures are to wait for the response before releasing the >>>> state of the call. If proper procedures were followed, none >>>> of this would be an issue, because the BYE would merely need >>>> to be refused with a 488 (Not Acceptable Here) to address this. >>> >>> Too early for solution discussions. >> >> ah, but this one is specified in RFC 3261 - which (way) predates ECRIT >> >> therefore this "solution" exists already. This is not a new one >> >> James >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Nena-ltd mailing list >> Nena-ltd@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/nena-ltd > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 10:33:09 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 788BE3A6849; Tue, 14 Oct 2008 10:33:09 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90493A6849 for ; Tue, 14 Oct 2008 10:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMBHDtt7SSOR for ; Tue, 14 Oct 2008 10:33:06 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 43CE03A67E9 for ; Tue, 14 Oct 2008 10:33:06 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9EHXUI5002458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Oct 2008 19:33:33 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9EHXPjo012378; Tue, 14 Oct 2008 19:33:30 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 19:33:25 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 19:33:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 20:33:25 +0300 Message-ID: In-Reply-To: <0FDEE96E8FF64F70BAA4FE5FB5E64442@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT WG Rechartering Thread-Index: AckuBjmTnAPszjJlSJmGvxWZVUN58wAG64uQ References: <0FDEE96E8FF64F70BAA4FE5FB5E64442@china.huawei.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Spencer Dawkins" , "ECRIT" X-OriginalArrivalTime: 14 Oct 2008 17:33:25.0652 (UTC) FILETIME=[F6861D40:01C92E22] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081014193330-73812BB0-BF0A3D14/0-0/0-15 X-purgate-size: 6913/0 Subject: Re: [Ecrit] ECRIT WG Rechartering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Good question, Spencer. Here is the story: During the IETF#72 ECRIT meeting we said that we would request a longer slot for ECRIT and then use one part of the meeting to discuss the next steps regarding the authority-to-citizen given that we got good feedback from a previous adhoc meeting (I guess that was in the Chicago IETF). Brian and Steve were nominated to organize this early warning session. Anyway, when I wanted to request a longer slot for ECRIT but Cullen suggested to schedule a separate (official) BOF instead. As such, Marc and I changed our request to a small slot for ECRIT and Brian and Steve started their work on the charter proposal for the BOF. For some reason they haven't sent the text to the list yet and I might not even have the latest version. The BOF is listed on the scheduled BOF page (see http://trac.tools.ietf.org/bof/trac/wiki) and I was hoping to see some mails from Brian/Steve sometime soon. Since the BOF did not take place yet there is obviously no decision on whether that work should be done in the IETF at all and in what group (if at all). Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Spencer Dawkins >Sent: 14 October, 2008 17:07 >To: ECRIT >Subject: Re: [Ecrit] ECRIT WG Rechartering > >Hi, Hannes, > >Could you say anything about the future of >authority-to-citizen emergency services work mentioned during >the "potential charter" discussion in Dublin? > >Thanks, > >Spencer > > >> Here is a first proposal for the ECRIT WG rechartering based on the >> discussions we had around IETF#72. >> For the moment, I have put 3 additional documents onto the charter: >> >http://tools.ietf.org/id/draft-polk-ecrit-local-emergency-rph-namespac >> e- >> 03.txt >> http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc-00.txt >> http://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00.txt >> >> Regarding the following two documents >> >http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.t >> xt http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-00.txt >> I am waiting for additional feedback from the draft authors on how >> they perceive these documents should be progressed through the IETF, >> see my mail here: >> http://www.ietf.org/mail-archive/web/ecrit/current/msg05518.html >> >> Please take a look at it and give me feedback till the 21st October >> 2008. >> >> >---------------------------------------------------------------------- >> -- >> --------------------------- >> >> Emergency Context Resolution with Internet Technologies (ecrit) >> >> Description of Working Group: >> >> In a number of areas, the public switched telephone network >(PSTN) has >> been configured to recognize an explicitly specified number >(commonly >> one that is short and easily memorized) as a call for emergency >> services. These numbers (e.g. 911, 112) relate to an emergency >> service context and depend on a broad, regional configuration of >> service contact methods and a geographically-constrained context of >> service delivery. These calls are intended to be delivered >to special >> call centers equipped to manage emergency response. Successful >> delivery of an emergency service call within those systems requires >> both an association of the physical location of the >originator with an >> appropriate emergency service center and call routing to deliver the >> call to the center. >> >> Calls placed using Internet technologies do not use the same systems >> to achieve those goals, and the common use of overlay networks and >> tunnels (either as VPNs or for mobility) makes meeting them more >> challenging. There are, however, Internet technologies available to >> describe location and to manage call routing. This working >group will >> describe when these may be appropriate and how they may be >used. This >> group is considering emergency services calls which might be made by >> any user of the Internet, as opposed to government or military >> services that may impose very different authentication and routing >> requirements. >> >> While this group anticipates a close working relationship >with groups >> such as NENA and ETSI EMTEL, any solution presented must be useful >> regardless of jurisdiction, and it must be possible to use without a >> single, central authority. Further, it must be possible for >multiple >> delegations within a jurisdiction to be handled >independently, as call >> routing for specific emergency types may be independent. >> >> The group will work on the maintainance of the Location-to-Service >> Translation (LoST) protocol, on (emergency services and >non-emergency >> services related)extensions to LoST to the as well as on necessary >> extension related to emergency call routing. >> >> This working group cares about privacy and security >concerns, and will >> address them within its documents. >> >> Goals and Milestones: >> >> Done An Informational RFC containing terminology definitions >> and the requirements >> Done An Informational document describing the threats and >> security considerations >> Done A Standards Track RFC describing how to identify a >> session set-up request is to an emergency response center >> Done A Standards Track RFC describing how to route an >> emergency call based on location information >> Done An Informational document describing the Mapping >> Protocol Architecture >> Dec 2008 An Informational document describing the >ECRIT Framework >> Dec 2008 A BCP document describing the emergency call >support for >> devices >> Oct 2008 An Informational document providing a >problem statement >> and requirements for location hiding >> Oct 2008 An Informational document specifying how to express >> holes in LoST service boundaries >> Dec 2008 An Informational document describing how to >synchronize >> LoST servers >> Jan 2009 A Standards Track RFC registering a SIP Resource >> Priority Header Namespace for Local Emergency Communications >> Feb 2009 An Informational document describing how imprecise >> location is used for emergency context resolution >> Feb 2009 A Standards Track RFC containing Location-to-Service >> Translation Protocol (LoST) Extensions >> _______________________________________________ >> 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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 10:55:54 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B2F928C133; Tue, 14 Oct 2008 10:55:54 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D260D28C133 for ; Tue, 14 Oct 2008 10:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.073 X-Spam-Level: X-Spam-Status: No, score=-106.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU1tV9wMf2NS for ; Tue, 14 Oct 2008 10:55:48 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id 6EA1528C0E5 for ; Tue, 14 Oct 2008 10:55:48 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-8.tower-203.messagelabs.com!1224006955!24141631!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 28096 invoked from network); 14 Oct 2008 17:55:55 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-8.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 14 Oct 2008 17:55:55 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m9EHuNaM002620; Tue, 14 Oct 2008 13:56:23 -0400 Received: from 01GAF5142010622.AD.BLS.COM ([139.76.131.83]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with SMTP id m9EHuF70002480; Tue, 14 Oct 2008 13:56:15 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 14 Oct 2008 13:56:15 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 14 Oct 2008 13:56:15 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 13:56:12 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0B373F18@crexc41p> In-Reply-To: <00bf01c92e16$c5c46330$514d2990$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying anemergency call thread-index: AckuFO70CU7jnOJqSPmxc/XNCo+/9wAAccUAAAOU1yA= References: <04d601c92dfb$7668a320$6339e960$@net><76D44EF2-93E3-4469-AEE7-6C3F7C0CECFA@cs.columbia.edu><009f01c92e13$5d568f60$1803ae20$@net><518751F4-319E-44F9-ACF1-BA944EF91028@cs.columbia.edu> <00bf01c92e16$c5c46330$514d2990$@net> From: "Stark, Barbara" To: "Brian Rosen" , "Henning Schulzrinne" X-OriginalArrivalTime: 14 Oct 2008 17:56:15.0157 (UTC) FILETIME=[26CFFE50:01C92E26] Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ECRIT Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying anemergency call X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org So long as we understand and accept that the most likely form of "guessing" will be to simply recognize the "home" emergency dial strings associated with that caller. Which is what we have today, so it isn't a problem. Feel free to say "MUST", for that, if you like. I think the comment about "a small set of countries" could be misinterpreted. If those countries all use different dial strings, the VSP is likely not to try to recognize all strings from all of the countries, but to only recognize the strings of the country that caller is associated with (billing location, or perhaps even a static emergency location). Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, October 14, 2008 12:06 PM To: 'Henning Schulzrinne' Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying anemergency call Works for me -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Tuesday, October 14, 2008 11:53 AM To: Brian Rosen Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call (a) and (b) can probably be combined into one case, as they essentially involve guessing. Something like --- If a proxy can reasonably guess the location of the caller, it MAY use that location to recognize applicable emergency numbers. For example, a proxy may base this estimate on the fact that most of the VSPs customers reside in a small set of countries. --- (Since we can't dictate what reasonable is, anything stronger than a MAY doesn't really help.) On Oct 14, 2008, at 11:41 AM, Brian Rosen wrote: > Yes, you are correct. > > I'd suggest a) and b) in your list. > > Brian > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, October 14, 2008 11:35 AM > To: Brian Rosen > Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' > Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an > emergency call > > In general, we SHOULD always qualify the SHOULD with the condition of > when the obligation cannot be met. ED-3 kind of does this, but the > causal connection is not obvious. Thus, we want something > > "If a proxy knows the caller's location, it MUST recognize the local > emergency dial string. If not, ?" > > We need to then decide whether the ? should be > > - proxy can guess at the location and recognize based on a guess > - recognize certain numbers always (e.g., those numbers where most of > its customers reside) > - never recognize anything > > (and it could be all of the above). > > This provides much more useful guidance to implementors than a SHOULD. > > Henning > > On Oct 14, 2008, at 8:50 AM, Brian Rosen wrote: > >> The problem is that proxies don't have location, and therefore can't >> recognize them in most cases. Mobile systems with IMS, where the >> visited >> network handles emergency calls would be an exception, but a >> wireline IMS >> system which allowed nomading would not be able to recognize local >> emergency >> dialstrings. That is why SHOULD is appropriate. >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf Of >> Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Tuesday, October 14, 2008 7:49 AM >> To: ECRIT >> Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an >> emergency >> call >> >> >> ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If >> the service provider always knows the location of the device, then >> the service provider could recognize them. >> >> SP-2 Proxy servers SHOULD recognize emergency dial strings if for >> some reason the endpoint does not recognize them. This cannot be >> relied upon by the device if the service provider cannot always >> determine the location of the device. >> >> >> Looking at these 2 SHOULDs I can imagine cases where neither one of >> them >> recognizes them. >> >> Wouldn't it be better to have a MUST with the 2nd requirement? I >> would >> delete the 2nd sentence since in that case it would be very >> difficult to >> route the call and to find the right PSAP as well. >> >> Comparing with the following requirement I recognize a mismatch: >> >> ED-19/INT-10/SP-13 Where proxies provide location on behalf of >> endpoints, the service provider MUST ensure that either the end >> device is provided with the local dial strings for its current >> location (where the end device recognizes dial strings), or the >> service provider proxy MUST detect the appropriate local dial >> strings >> at the time of the call. >> >> >> >> ED-5/SP-4 Local dial strings MUST be recognized. >> >> "MUST" be recognized by whom? See requirements above. >> >> >> ED-6/SP-5 Devices MUST be able to be configured with the home >> country >> from which the home dial string(s) can be determined. >> >> >> Shouldn't this read like >> " >> Devices MUST be have mechanisms to learn the user's home emergency >> numbers. >> " >> >> >> ED-9 Endpoints SHOULD be able to have home dial strings provisioned >> by configuration. >> >> I guess ED-9 should say something like "Endpoints SHOULD be able to >> have >> home dial strings dynamically provisioned." >> To refer to the case that manual configuration may also be used in >> order >> to meet the previous requirements. >> >> >> ED-11/SP-9 All emergency services specified in [RFC5031] MUST be >> recognized. >> >> Should say something like: >> " >> All emergency services URNs specified in .... MUST be recognized. >> " >> >> _______________________________________________ >> 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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 11:06:27 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 621C63A677E; Tue, 14 Oct 2008 11:06:27 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4243A63EC for ; Tue, 14 Oct 2008 11:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGRXAT81y2Mj for ; Tue, 14 Oct 2008 11:06:25 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EE7553A68C2 for ; Tue, 14 Oct 2008 11:06:24 -0700 (PDT) Received: (qmail invoked by alias); 14 Oct 2008 18:06:38 -0000 Received: from a91-154-101-110.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.101.110] by mail.gmx.net (mp015) with SMTP; 14 Oct 2008 20:06:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19g2Osv5RVgSJYDW0gl4a9K7S7DDf4dr3xYzzaWBB JKKoPPFHHcWY7B From: "Hannes Tschofenig" To: "'Brian Rosen'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'ECRIT'" References: <04d901c92dfb$ff672200$fe356600$@net> Date: Tue, 14 Oct 2008 21:06:40 +0300 Message-ID: <000001c92e27$9d4fba60$04ffa8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ackt8v4cEuENj9IIRdejr3WUkJ7UOgACN2NgAABEGCA= In-Reply-To: <04d901c92dfb$ff672200$fe356600$@net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: UserInterface Requirements X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Found the text in the framework draft. Maybe someone can provide us with a reference to a study. If you like the requirement that much .... >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Brian Rosen >Sent: 14 October, 2008 15:54 >To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: >UserInterface Requirements > >The relevant text is in -framework. I think the requirement >really ought to stand. It's a very common error, and it's a >pretty well understoond phenomenon. > >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >Sent: Tuesday, October 14, 2008 7:50 AM >To: ECRIT >Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: User >Interface Requirements > > > ED-10 Devices SHOULD NOT have one button emergency calling > initiation. > > >This requirement sounds nice when you provide some background >on why that this is a bad idea. I wonder whether someone could >provide some references to these studies as they do exist. > >However, this is not really an issue an IETF document worries >about specifically not with regard to RFC 2119 language. I >would not object to have it mentioned somewhere in the >document saying: "Note: The following studies indicate that >designing a user interface with a single button for emergency >call is a bad idea because of ....". > > > >_______________________________________________ >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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 11:06:40 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0BD03A69CD; Tue, 14 Oct 2008 11:06:40 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 397933A63EC for ; Tue, 14 Oct 2008 11:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBH39NmEc6Mx for ; Tue, 14 Oct 2008 11:06:33 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1EE0C28C1C0 for ; Tue, 14 Oct 2008 11:06:32 -0700 (PDT) Received: (qmail invoked by alias); 14 Oct 2008 18:06:42 -0000 Received: from a91-154-101-110.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.101.110] by mail.gmx.net (mp015) with SMTP; 14 Oct 2008 20:06:42 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19XAnYhuQhXSkk/DGeJnkDaD6d7Klw6lbaLlUfvwU RJLiJY2002+OIJ From: "Hannes Tschofenig" To: "'Brian Rosen'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'ECRIT'" References: <04d801c92dfb$d3765a80$7a630f80$@net> Date: Tue, 14 Oct 2008 21:06:40 +0300 Message-ID: <000101c92e27$9f314ba0$04ffa8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ackt8ugQefYJ96oQSE2zsXvdG5crSgACLTCAAABQEUA= In-Reply-To: <04d801c92dfb$d3765a80$7a630f80$@net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Media X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I see your concerns. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Brian Rosen >Sent: 14 October, 2008 15:53 >To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Media > >There are so many things in phonebcp that are not implemented, >adding SRTP, and then insisting on SDES is really dooming >interoperability. I do think, generally, that encrypting the >media is a good thing, but I can't even see "SHOULD". > >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >Sent: Tuesday, October 14, 2008 7:49 AM >To: ECRIT >Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Media > >Looking at Section 14 about media I was wondering whether the >usage of SRTP wouldn't make sense. >For key management I would go for SDES. > >What do you think? > > >_______________________________________________ >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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 11:20:56 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F3023A68B2; Tue, 14 Oct 2008 11:20:56 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6D613A68B2 for ; Tue, 14 Oct 2008 11:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oD9CUiNxrQVA for ; Tue, 14 Oct 2008 11:20:53 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6D9633A67D6 for ; Tue, 14 Oct 2008 11:20:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,410,1220227200"; d="scan'208";a="95101042" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 14 Oct 2008 18:21:13 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m9EILDVV031527; Tue, 14 Oct 2008 11:21:13 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m9EILDmk027514; Tue, 14 Oct 2008 18:21:13 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 11:21:13 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.91.34]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 11:21:12 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Oct 2008 13:21:30 -0500 To: "Brian Rosen" , "'Marc Linsner'" , , , "'ECRIT'" From: "James M. Polk" In-Reply-To: <00e401c92e20$1577e560$4067b020$@net> References: <04d501c92dfa$f92ab790$eb8026b0$@net> <00e401c92e20$1577e560$4067b020$@net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 14 Oct 2008 18:21:13.0073 (UTC) FILETIME=[A3A3D610:01C92E29] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4019; t=1224008473; x=1224872473; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[NENA-ltd]=20[Ecrit]=20Design=20Team=20 Status=20Update |Sender:=20; bh=UBGOy04W/qPOEgKQdUyiw10OQScyOTQY2yE8m33PEOg=; b=LsGqXiXiTaBwwuoWjz0UAQdtTajIEKcizkLsrEIzjATGzu+usEnAhPmhaL MBACq0UW/Jx1n8cvvyCoP4xVibTNuPNoNBdjF4EsUjkwGF9wLqXxTkY4+ZHX YSwXs8pv3+; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Ecrit] [NENA-ltd] Design Team Status Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian AS Henning said, only dialog stateful proxies are involved in the BYEs, so that will be rare, because most of these Proxies will actually be B2BUAs. Meaning you have to get everyone's B2BUAs to implement this SIP extension to get it to even have a prayer of working on any scale. Since B2BUAs do not look any different than Proxies to a UAC or UAS, you can't detect them, so how exactly is anyone going to deal with the frequent failures of this new mechanism? I think you have the same challenge of getting existing Proxies to be upgraded to support BYE state until response, "for the good of the planet (i.e., to get emergency calling to support this one features that isn't really used by more than 1/3 of the existing emergency systems anyway)"... James At 12:12 PM 10/14/2008, Brian Rosen wrote: >We have a shot at getting phone vendors to pay attention. The more parts I >have to get upgraded, and the more difficult the upgrades, the less likely. >I talked with several sip experts about the "cancel the bye" idea. While >feasible, it's a major stack change. > >Doing something like enabling a feature because it's in Required is a heck >of a lot easier. > >Getting just phones to do something as opposed to phones + B2BUAs and other >middleboxes is a lot easier > >Also, you the failure mechanisms for the middleboxes is bad. If they don't >understand the "cancel the BYE", then they tear down the connections as soon >as they see the BYE. But they don't take the tag away in Supported - so the >PSAP and the phone think it's gonna work, but it actually breaks. Yuck. > >Brian > >-----Original Message----- >From: Marc Linsner [mailto:mlinsner@cisco.com] >Sent: Tuesday, October 14, 2008 1:03 PM >To: Brian Rosen; nena-i2_5@listserv.neustar.biz; >nena-ltd@lists.cs.columbia.edu; 'ECRIT' >Subject: Re: [NENA-ltd] [Ecrit] Design Team Status Update > >Brian, > >So creating more mechanism that is ignored by implementers is better? > >-Marc- > > > >On 10/14/08 8:47 AM, "Brian Rosen" wrote: > > > You are ignoring the observation that refusing a BYE means all proxies in > > the path have to be aware that this is possible. That is much more of > > change than we can probably expect. > > > > Not sending a BYE doesn't have that problem. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > > James M. Polk > > Sent: Tuesday, October 14, 2008 2:23 AM > > To: Tschofenig, Hannes (NSN - FI/Espoo); ext Ted Hardie; > > nena-i2_5@listserv.neustar.biz; nena-ltd@lists.cs.columbia.edu; ECRIT > > Subject: Re: [Ecrit] Design Team Status Update > > > > At 12:48 AM 10/14/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >>> Ultimately, you want to overcome implementer's universal mode > >>> of disconnecting (or removing) state awareness once a UA has > >>> sent a BYE when this is not proper SIP procedures. SIP > >>> procedures are to wait for the response before releasing the > >>> state of the call. If proper procedures were followed, none > >>> of this would be an issue, because the BYE would merely need > >>> to be refused with a 488 (Not Acceptable Here) to address this. > >> > >> Too early for solution discussions. > > > > ah, but this one is specified in RFC 3261 - which (way) predates ECRIT > > > > therefore this "solution" exists already. This is not a new one > > > > James > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Nena-ltd mailing list > > Nena-ltd@lists.cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/nena-ltd > > >_______________________________________________ >Nena-ltd mailing list >Nena-ltd@lists.cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/nena-ltd _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 11:25:30 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8323A67F8; Tue, 14 Oct 2008 11:25:30 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374773A67F8 for ; Tue, 14 Oct 2008 11:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.27 X-Spam-Level: X-Spam-Status: No, score=-3.27 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVJR6WBzcu5T for ; Tue, 14 Oct 2008 11:25:26 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 9001B3A6774 for ; Tue, 14 Oct 2008 11:25:25 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9EIPZRs006125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Oct 2008 20:25:36 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9EIPYlX027125; Tue, 14 Oct 2008 20:25:35 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 20:25:29 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 20:25:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 21:04:02 +0300 Message-ID: In-Reply-To: <04de01c92dfd$b93cb8b0$2bb62a10$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call Thread-Index: Ackt8ubHOAdjXzPzQLmHqGE2+O5wIQACEYDwAAAcXZAAAFbnIAAAav6A References: <04d601c92dfb$7668a320$6339e960$@net> <04de01c92dfd$b93cb8b0$2bb62a10$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Brian Rosen" , "ECRIT" X-OriginalArrivalTime: 14 Oct 2008 18:25:26.0895 (UTC) FILETIME=[3AEDFFF0:01C92E2A] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081014202535-73812BB0-6809980C/0-0/0-15 X-purgate-size: 5579/0 Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Brian, >Hannes > >If it's not possible in most circumstances to have proxies >recognize emergency dial strings, then it's not possible to >make it a requirement that they do so. > >The fact is that the endpoint must do it. That is the actual >requirement. Quoting the document: ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If the service provider always knows the location of the device, then the service provider could recognize them. >The proxy text is a backstop; it's not required, it's not >usually even possible, but it's nice to have. >If anything, you could be arguing we should delete the proxy >requirement, or at least reword it to cover the case of a >guarantee that the visited network handles emergency calls. In >fact, since most emergency calls are made from visited >networks where the local emergency dial strings are the same >as home dial strings, it will actually work most of the time >in most networks. >That's my argument for keeping it. Henning already made a suggestion for text and I will take a look at that one to see how it works out. Ciao Hannes > >Ergo, SHOULD > >Brian > >-----Original Message----- >From: Tschofenig, Hannes (NSN - FI/Espoo) >[mailto:hannes.tschofenig@nsn.com] > >Sent: Tuesday, October 14, 2008 8:58 AM >To: ext Brian Rosen; ECRIT >Subject: RE: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: >Identifying an emergency call > >Hi Brian, > >I know this challenge. > >Still, you have to put a must in there to make sure that the >call is actually recognized. > >The architecture is very much build on the idea that either >the end host or the VSP (directly or indirectly) get location >from somewhere. >As we learned at the previous emergency services workshops >there are some sort of hacks one can do to bypass this need >but they only work when there is a relationship between the >VSP and the ISP. Currently, these things are being setup in >individual countries and as such the question of recognizing >emergency service numbers is essentially solved. > > >Ciao >Hannes > >>-----Original Message----- >>From: ext Brian Rosen [mailto:br@brianrosen.net] >>Sent: 14 October, 2008 15:51 >>To: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' >>Subject: RE: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: >>Identifying an emergency call >> >>The problem is that proxies don't have location, and therefore can't >>recognize them in most cases. Mobile systems with IMS, where the >>visited network handles emergency calls would be an exception, but a >>wireline IMS system which allowed nomading would not be able to >>recognize local emergency dialstrings. >>That is why SHOULD is appropriate. >> >>Brian >> >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >>Of Tschofenig, Hannes (NSN - FI/Espoo) >>Sent: Tuesday, October 14, 2008 7:49 AM >>To: ECRIT >>Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an >>emergency call >> >> >> ED-3 Endpoints SHOULD recognize dial strings of emergency >calls. If >> the service provider always knows the location of the device, then >> the service provider could recognize them. >> >> SP-2 Proxy servers SHOULD recognize emergency dial strings if for >> some reason the endpoint does not recognize them. This cannot be >> relied upon by the device if the service provider cannot always >> determine the location of the device. >> >> >>Looking at these 2 SHOULDs I can imagine cases where neither one of >>them recognizes them. >> >>Wouldn't it be better to have a MUST with the 2nd requirement? >>I would delete the 2nd sentence since in that case it would be very >>difficult to route the call and to find the right PSAP as well. >> >>Comparing with the following requirement I recognize a mismatch: >> >> ED-19/INT-10/SP-13 Where proxies provide location on behalf of >> endpoints, the service provider MUST ensure that either the end >> device is provided with the local dial strings for its current >> location (where the end device recognizes dial strings), or the >> service provider proxy MUST detect the appropriate local dial >>strings >> at the time of the call. >> >> >> >> ED-5/SP-4 Local dial strings MUST be recognized. >> >>"MUST" be recognized by whom? See requirements above. >> >> >> ED-6/SP-5 Devices MUST be able to be configured with the home >>country >> from which the home dial string(s) can be determined. >> >> >>Shouldn't this read like >>" >>Devices MUST be have mechanisms to learn the user's home emergency >>numbers. >>" >> >> >> ED-9 Endpoints SHOULD be able to have home dial strings provisioned >> by configuration. >> >>I guess ED-9 should say something like "Endpoints SHOULD be able to >>have home dial strings dynamically provisioned." >>To refer to the case that manual configuration may also be used in >>order to meet the previous requirements. >> >> >> ED-11/SP-9 All emergency services specified in [RFC5031] MUST be >> recognized. >> >>Should say something like: >>" >>All emergency services URNs specified in .... MUST be recognized. >>" >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit >> >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 11:26:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C303A6874; Tue, 14 Oct 2008 11:26:43 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D643A6874 for ; Tue, 14 Oct 2008 11:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta9H87uAbzVZ for ; Tue, 14 Oct 2008 11:26:41 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 00D633A6862 for ; Tue, 14 Oct 2008 11:26:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,410,1220227200"; d="scan'208";a="95103956" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 14 Oct 2008 18:26:40 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m9EIQeI0011196; Tue, 14 Oct 2008 11:26:40 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m9EIQeXX014007; Tue, 14 Oct 2008 18:26:40 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 11:26:39 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.91.34]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 11:26:39 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Oct 2008 13:26:57 -0500 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ECRIT" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 14 Oct 2008 18:26:39.0249 (UTC) FILETIME=[660E5810:01C92E2A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5191; t=1224008800; x=1224872800; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20ECRIT=20WG=20Rechartering |Sender:=20; bh=gGeY/5/p2USDDDHI4KX3tvegXYOuruDuVCdELQASRNM=; b=rvKQukXlc2jjCZQiVsZg9tTliCLQklxe0nKdNJn/jUldMq7S/+wk1VrFMQ sVmO0GVT4rXVCbgCuMFd8cPnO7uEfEk6qF23LbFnM0LuUWP1w7EA92jyyJU2 +lpzFXYS0k; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Ecrit] ECRIT WG Rechartering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 01:13 AM 10/14/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >Here is a first proposal for the ECRIT WG rechartering based on the >discussions we had around IETF#72. >For the moment, I have put 3 additional documents onto the charter: >http://tools.ietf.org/id/draft-polk-ecrit-local-emergency-rph-namespace- >03.txt I'll have a new version before the -00 deadline. Can either of you chairs submit to the Secretariat that draft-ietf-ecrit-local-emergency-rph-namespace-00 is coming and approved by the chairs (so we don't end up with a timing issue)? Thanks James >http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc-00.txt >http://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00.txt > >Regarding the following two documents >http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.txt >http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-00.txt >I am waiting for additional feedback from the draft authors on how they >perceive these documents should be progressed through the IETF, see my >mail here: >http://www.ietf.org/mail-archive/web/ecrit/current/msg05518.html > >Please take a look at it and give me feedback till the 21st October >2008. > >------------------------------------------------------------------------ >--------------------------- > >Emergency Context Resolution with Internet Technologies (ecrit) > >Description of Working Group: > >In a number of areas, the public switched telephone network (PSTN) has >been configured to recognize an explicitly specified number (commonly >one that is short and easily memorized) as a call for emergency >services. These numbers (e.g. 911, 112) relate to an emergency >service context and depend on a broad, regional configuration of >service contact methods and a geographically-constrained context of >service delivery. These calls are intended to be delivered to special >call centers equipped to manage emergency response. Successful >delivery of an emergency service call within those systems requires >both an association of the physical location of the originator with an >appropriate emergency service center and call routing to deliver the >call to the center. > >Calls placed using Internet technologies do not use the same systems >to achieve those goals, and the common use of overlay networks and >tunnels (either as VPNs or for mobility) makes meeting them more >challenging. There are, however, Internet technologies available to >describe location and to manage call routing. This working group will >describe when these may be appropriate and how they may be used. This >group is considering emergency services calls which might be made by >any user of the Internet, as opposed to government or military >services that may impose very different authentication and routing >requirements. > >While this group anticipates a close working relationship with groups >such as NENA and ETSI EMTEL, any solution presented must be useful >regardless of jurisdiction, and it must be possible to use without a >single, central authority. Further, it must be possible for multiple >delegations within a jurisdiction to be handled independently, as call >routing for specific emergency types may be independent. > >The group will work on the maintainance of the >Location-to-Service Translation (LoST) protocol, on (emergency services >and non-emergency services related)extensions to LoST to the as well as >on necessary extension related to emergency call routing. > >This working group cares about privacy and security concerns, and will >address them within its documents. > >Goals and Milestones: > >Done An Informational RFC containing terminology definitions >and the requirements >Done An Informational document describing the threats and >security considerations >Done A Standards Track RFC describing how to identify a >session set-up request is to an emergency response center >Done A Standards Track RFC describing how to route an >emergency call based on location information >Done An Informational document describing the Mapping >Protocol Architecture >Dec 2008 An Informational document describing the ECRIT Framework >Dec 2008 A BCP document describing the emergency call support for >devices >Oct 2008 An Informational document providing a problem statement >and requirements for location hiding >Oct 2008 An Informational document specifying how to express >holes in LoST service boundaries >Dec 2008 An Informational document describing how to synchronize >LoST servers >Jan 2009 A Standards Track RFC registering a SIP Resource >Priority Header Namespace for Local Emergency Communications >Feb 2009 An Informational document describing how imprecise >location is used for emergency context resolution >Feb 2009 A Standards Track RFC containing Location-to-Service >Translation Protocol (LoST) Extensions >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 14 11:47:41 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59F393A686E; Tue, 14 Oct 2008 11:47:41 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A79E3A6849 for ; Tue, 14 Oct 2008 11:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQuT7dA5LP6p for ; Tue, 14 Oct 2008 11:47:40 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id 7BAF13A67F8 for ; Tue, 14 Oct 2008 11:47:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1224010078; x=1224096478; h=From:Date:Subject:Message-ID:Content-class:Content-Type:Content-Transfer-Encod ing; b=e/HzMpq/5oSJK+Dbsu2nsKjMKIF+ynLA1fqudLkt1I/P6jcJRGwTpmt8XPjskyt7i0CgjjfzUK49Qq sKJKI2aA== Received: from ([10.31.13.50]) by chihiron2.nc.neustar.com with ESMTP id 5202415.8859537; Tue, 14 Oct 2008 14:47:34 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 14:46:38 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ATOCA BOF Request Text Thread-Index: AckuLTBcAW5j2MyKQ9u7o+tRVlTalA== From: "Rosen, Brian" To: "ECRIT" Subject: [Ecrit] ATOCA BOF Request Text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org ATOCA BOF Authority-to-Citizen Alert Mailing Lists: earlywarn@ietf.org BOF chairs: Brian Rosen [brian.rosen at neustar.biz] Steve Norreys [steve.norreys@bt.com] Temporary Area Directorate: Real Time Applications (RAI) Ultimate Area Directorate: TBD BOF Purpose. ecrit is working on citizen-to-authority calls. Alerts that are sent from "authorities" (which we define broadly to any level of authority, including, for example, a school administrator) to "citizen" (which we also define broadly to include visitors and other individuals and groups) are of great interest. Many efforts are underway in other fora, but all of them are stovepipes: limited by which authorities can invoke alerts as well as which networks they can be distributed on. What is needed is a more flexible way to deliver alerts from any notifier to any interested or affected individual, via any device connected to the Internet. This is a large problem: some alerts must be delivered to an enormous number of endpoints; a Tsunami warning may involve millions of devices eventually. A system which can deliver messages to billions of endpoints with one notification are obviously attractive attack targets. This is further complicated by the desire to accept notifications from a wide variety of notifiers, complicating authentication mechanisms that might be employed. The security implications of any solutions must be addressed as a intergral part of the solution from the very start of the work. Classic alert systems typically use layer 2 broadcast mechanisms and often use some kind of location as a criteria for who gets the alert. On the Internet, multicast mechanisms may be helpful, but the paucity of multicast deployment must be considered. Besides broadcast, which certainly is very appropriate, it is very useful to be able to subscribe to events for individuals who may not normally meet criteria for being included in a broadcast. For example, parents may wish to receive alerts that affect their children. An alert directed to anyone in the path of a hurricane may be broadcast, but the parent may need a subscription to get the same alert when they are not in the affected area. The content of an alert is also a significant challenge to Internet scale alerts. The alert must be rendered on a wide variety of devices with different user interface capabilities. Multiple languages have to be accomodated. Networks with limited bandwidth must be considered. Alert work is being done in many fora, and some is directly applicable to this work. For example, OASIS work on Common Alerting Protocol is likely part of the solution. It should also be recognised that this is an area of work that will be highly regulated and as such close work with the fora where regulators operate (e.g. ATIS, ETSI and ITU-T) may help with the deployment of any solutions. The purpose of the BOF is to determine the need and scope for authority to citizen alerts, what existing protocols and mechansims need to be adapted to meet those needs and the appropriate representation for alerts should be. This work could be accomplished within an expanded charter of ecrit, or a new work group could be formed. This work will leverage geopriv work on location. Proposed Deliverables: 1) Requirements for ATOCA . 2) An ATOCA Framework. 3) Various protocol and mechanism enhancements to meet the requirements identified Input Documents: 1) Requirements draft-norreys-ecrit-authority2individuals-requirements-01.txt _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 17 16:22:42 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AD8428C144; Fri, 17 Oct 2008 16:22:42 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737B828C144 for ; Fri, 17 Oct 2008 16:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.203 X-Spam-Level: X-Spam-Status: No, score=-105.203 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFK52P1AOdZl for ; Fri, 17 Oct 2008 16:22:40 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 83FFE28C13B for ; Fri, 17 Oct 2008 16:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1224285826; x=1255821826; h=message-id:in-reply-to:references:x-mailer: x-message-flag:date:to:from:subject:cc:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20|References:=20<006e01c9299e$9324 6fa0$b96d4ee0$@net>=0D=0A=20=0D=0A=20|X-Mailer:=20Eudora=20for=20Mac=20O S=20X|X-message-flag:=20Warning:=20Outlook=20in=20use.=20 =20Upgrade=20to=20Eudora:=20|Date: =20Fri,=2017=20Oct=202008=2016:20:38=20-0700|To:=20"Tscho fenig,=20Hannes=20(NSN=20-=20FI/Espoo)"=20,=0D=0A=20=20=20=20=20=20=20=20ext=0D=0A=20Ma rc=20Linsner=20,=0D=0A=20=20=20=20=20 =20=20=20Brian=20Rosen=20|From:=20Rand all=20Gellens=20|Subject:=20Re:=20[Ec rit]=20IETF=20ECRIT=20Design=20Team=20on=20Premature=20Ca ll=20=20=0D=0A=20Termination|CC:=20ECRIT=20|MIME-Version:=201.0|Content-Type:=20text/html=3B=20cha rset=3D"us-ascii"|X-Random-Sig-Tag:=201.0b28 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5408"=3B=20 a=3D"11112665"; bh=hY7D3vLb9DWZY0tBVyOb2xFbflYrWUDECqQn/JuscpE=; b=gz99u+cN1QCu9+ncQ3fWZbs2cEnbuJyG8HxsWj6IqYb2qAAhbFlwmsxe 8CyJq2kZ5/tjVZlxVmJt0LAO6+03Vx5hRX+zDaXP24grIOsvHPSxu1LaA Ob11HZvzBVxPuE7iJ9YpWvEoi5hTR/7gWyY1ttKWfK3c26OEgh67Fb7Tx 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5408"; a="11112665" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Oct 2008 16:23:45 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9HNNj3K011695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Oct 2008 16:23:45 -0700 Received: from nasanexhc01.na.qualcomm.com (nasanexhc01.na.qualcomm.com [172.30.37.21]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9HNNgOK003736 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Oct 2008 16:23:45 -0700 Received: from nasanexhub01.na.qualcomm.com (10.46.93.121) by nasanexhc01.na.qualcomm.com (172.30.37.21) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 17 Oct 2008 16:23:42 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 17 Oct 2008 16:23:42 -0700 Received: from loud.qualcomm.com (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 17 Oct 2008 16:23:41 -0700 Message-ID: In-Reply-To: References: <006e01c9299e$93246fa0$b96d4ee0$@net> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 17 Oct 2008 16:20:38 -0700 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , ext Marc Linsner , Brian Rosen From: Randall Gellens MIME-Version: 1.0 X-Random-Sig-Tag: 1.0b28 Cc: ECRIT Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1665221318==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============1665221318== Content-Type: text/html; charset="us-ascii" Re: [Ecrit] IETF ECRIT Design Team on Premature Call Ter
At 4:13 PM +0300 10/9/08, Hannes (NSN - FI/Espoo) Tschofenig wrote:

Folks, we need to get things going. Here is my suggestion:

1) Read through Brian's draft again
http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnect-rqmts-00
.txt
2) Take a look at the previously received comments
   - during the IETF meeting
   - after the meeting on the list
   Here are some links:
http://www.ietf.org/mail-archive/web/ecrit/current/msg05450.html
http://www.ietf.org/mail-archive/web/ecrit/current/msg05447.html
3) Determine whether we can agree on some of the requirements.

Here is one issue:

In jurisdiction where there is no CPH and PSAP calls back the originator,
is CPH and call-back perceived different?(Ted)

Yes it's different. Real problem is you can get Voicemail.. Instead of
the originator.
Originator can also make a call, with CPH, originator can't make another
call. (Brian)

Currently, cell phones don't implement CPH, but most do implement a feature that, for some time period following an emergency call, the phone can't be used to place a new call unless the user hits "end call" twice.  The intent, as I understand it, is to "reserve" the phone for PSAP call-back, while allowing the user to over-ride this reservation.

It seems to me that this suggests several things that are worth noting: A lot can and will need to be done in the UI; the user needs to be able to over-ride any restrictions; keeping the call itself up is not necessarily the optimal solution, especially in cellular networks.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I never travel without my diary.  One should always have something
sensational to read on the train.
   --Oscar Wilde
--===============1665221318== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1665221318==-- From ecrit-bounces@ietf.org Sat Oct 18 15:01:29 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF1863A68A7; Sat, 18 Oct 2008 15:01:28 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7F63A68A7 for ; Sat, 18 Oct 2008 15:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuyEEt5Eu27y for ; Sat, 18 Oct 2008 15:01:26 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 1AA5A3A67E2 for ; Sat, 18 Oct 2008 15:01:26 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KrJsI-0003D3-VJ; Sat, 18 Oct 2008 17:02:20 -0500 From: "Brian Rosen" To: "'Randall Gellens'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext Marc Linsner'" References: <006e01c9299e$93246fa0$b96d4ee0$@net> In-Reply-To: Date: Sat, 18 Oct 2008 18:02:18 -0400 Message-ID: <018301c9316d$32dfe4e0$989faea0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ackwr2bdEtBq4RfkQwamS9q+VEUroAAu+hlA Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You can get voicemail from call forwarding, network congestion, etc, in addition to making a call. UI can't fix that. Interestingly, I don't recall ever reading anywhere else about the feature you described. I wonder if in fact it is implemented widely. = There isn't anything magic about cellular networks AFAIK; what makes you believe that cellular networks should be treated differently for emergency calls? I'd bet that the outcome where CPH is employed is quite a bit higher than those where the caller can hang up. People under stress do stupid things quite often. Call takers tend to have better judgment on when a call should be taken down. YMMV I agree that the mechanism must fail safe. Brian From: Randall Gellens [mailto:randy@qualcomm.com] = Sent: Friday, October 17, 2008 7:21 PM To: Tschofenig, Hannes (NSN - FI/Espoo); ext Marc Linsner; Brian Rosen Cc: ECRIT Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination At 4:13 PM +0300 10/9/08, Hannes (NSN - FI/Espoo) Tschofenig wrote: Folks, we need to get things going. Here is my suggestion: 1) Read through Brian's draft again http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnect-rqmts-00 .txt 2) Take a look at the previously received comments =A0=A0 - during the IETF meeting =A0=A0 - after the meeting on the list =A0=A0 Here are some links: = http://www.ietf.org/mail-archive/web/ecrit/current/msg05450.html http://www.ietf.org/mail-archive/web/ecrit/current/msg05447.html 3) Determine whether we can agree on some of the requirements. Here is one issue: In jurisdiction where there is no CPH and PSAP calls back the originator, is CPH and call-back perceived different?(Ted) Yes it's different. Real problem is you can get Voicemail.. Instead of the originator. Originator can also make a call, with CPH, originator can't make another call. (Brian) Currently, cell phones don't implement CPH, but most do implement a feature that, for some time period following an emergency call, the phone can't be used to place a new call unless the user hits "end call" twice.=A0 The inte= nt, as I understand it, is to "reserve" the phone for PSAP call-back, while allowing the user to over-ride this reservation. = It seems to me that this suggests several things that are worth noting: A lot can and will need to be done in the UI; the user needs to be able to over-ride any restrictions; keeping the call itself up is not necessarily the optimal solution, especially in cellular networks. -- = Randall Gellens Opinions are personal;=A0=A0=A0 facts are suspect;=A0=A0=A0 I speak for mys= elf only -------------- Randomly-selected tag: --------------- I never travel without my diary. =A0One should always have something sensational to read on the train. =A0=A0=A0--Oscar Wilde _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 20 12:39:02 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8AF3A6A72; Mon, 20 Oct 2008 12:39:02 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 262903A6780 for ; Mon, 20 Oct 2008 12:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-ZUE6E8y5mf for ; Mon, 20 Oct 2008 12:39:01 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 214203A63CB for ; Mon, 20 Oct 2008 12:38:59 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2008 19:32:48 -0000 Received: from chello084114137227.1.15.vie.surfer.at (EHLO 4FIL42860) [84.114.137.227] by mail.gmx.net (mp030) with SMTP; 20 Oct 2008 21:32:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19gxWhDP9JgzRXEPp0AVv+LhDcw3F8P3+mRcMdzWH cUfnmoFdDPmzKk From: "Hannes Tschofenig" To: , "'ECRIT'" , Date: Mon, 20 Oct 2008 22:32:34 +0300 Message-ID: <040101c932ea$a43ee090$0900a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acky6nUtari5f/mpQTSxaKrzUnnVug== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Subject: [Ecrit] Updated Info for the 5th Emergency Services Workshop X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, please find the updated info for the conference bridge and the detailed agenda here: http://www.emergency-services-coordination.info/esw5.html More specifically, direct links can be found here: http://www.emergency-services-coordination.info/2008Oct/webex.txt http://www.emergency-services-coordination.info/2008Oct/agenda.txt We are going to upload the slides and other information during the workshop. The links will be added to the main workshop page. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 22 10:42:52 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 450D03A6A03; Wed, 22 Oct 2008 10:42:52 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24F43A6A03 for ; Wed, 22 Oct 2008 10:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFTPpAwKiyHU for ; Wed, 22 Oct 2008 10:42:49 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 907CA3A6947 for ; Wed, 22 Oct 2008 10:42:49 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so578291yxg.49 for ; Wed, 22 Oct 2008 10:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=npTSxfhOwRp9iLeAMCq9QaLcNNTFXiVgUtyO+0miM6g=; b=hQkSM7X2ZgaBzCzXuFXLQHRHY4ukO9pbiWtHAWfPNYDLJcKTzrxw6EoUl+ZQ6bclrN i8EaJqjn1xZ3pWYyuX7LB5uF6QuCiKsbbwayMeTwnpeyh1FloCHygJBGYowM7MaTI1UI VNbrentJQYEksMzbJ/vcrib5uktKpT0n6yjD0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=iWp3A3Hy5pZrcoBzT1+vVtcAAKOGKf1YSmyH3PDhROgX0KQYsRe8Di2DPsmmzhmDER MKj8FRf7HVaqYMlXF61gEBpe+uy3UCn9IJoM9eardtgbvlGkFAAn1oz5SL3mupp85UDJ LUjj7DSlZiqDSR8GD1v8+aPZ8PAK4Q8HlISj8= Received: by 10.100.142.15 with SMTP id p15mr12126042and.33.1224697393580; Wed, 22 Oct 2008 10:43:13 -0700 (PDT) Received: by 10.100.34.5 with HTTP; Wed, 22 Oct 2008 10:43:13 -0700 (PDT) Message-ID: <385b0c950810221043ie014a97h5c46274cdc14b981@mail.gmail.com> Date: Wed, 22 Oct 2008 12:43:13 -0500 From: "John-Luc Bakker" To: "Barclay, Deborah L (Deb)" In-Reply-To: <0AB57A5DEF898646A069F23604A2635301D3D9FE@ILEXC2U01.ndc.lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <0AB57A5DEF898646A069F23604A2635301D3D9FE@ILEXC2U01.ndc.lucent.com> Cc: ecrit@ietf.org Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Deb, Thanks for commenting. RFC 5031 mentions a generic emergency URN and emergency URNs for specific emergency service types; such as "urn:service:sos.gas" or other locally relevant types (e.g "urn:service:sos.eletricity?"). Would an INVITE, for the purposes of making a call back, from a UAS handling urn:service:sos. calls also include the sos parameter? In case the UAC failed to recognize the request as a emergency session request and the local network translates, say "121", to "urn:service:sos.electricity", would the UAC still receive an opaque "sos" indicator? In case emergency service type information is available, I see no harm in indicating the emergency service type information to the UAC. I am not sure what "efficiency" is gained by not indicating emergency service type information using a few extra characters in a SIP message. Kind regards, John-Luc On Fri, Oct 10, 2008 at 4:50 PM, Barclay, Deborah L (Deb) wrote: > > Milan, John-Luc, > > For the example provided below, the service-urn would be replaced as a > result of determining the call is routed to a CS PSAP. The service-urn > is preserved until the routing function determines the appropriate > emergency center and only replaces the service-urn because it had to be > converted to a digits. If different service-urns require different > destinations, that would have been accounted for. The single sos > parameter should be sufficient for proper emergency call handling and > the service-urn is available and sufficient for correct routing. > > Since opinions were being sought, my opinion is to keep the sos > parameter/marker simple for efficient emergency call handling purposes. > > Thank you, > Deb Barclay > >> ------------------------------ >> >> Message: 2 >> Date: Fri, 3 Oct 2008 14:45:08 +0100 >> From: "Milan Patel" >> Subject: Re: [Ecrit] [Fwd: I-D >> Action:draft-patel-ecrit-sos-parameter-00.txt] >> To: "John-Luc Bakker" , "ECRIT" >> >> Message-ID: >> >> <0913B6CD18F370498CD65864CF254E9006BFCF94@zharhxm1.corp.nortel.com> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi John-Luc, >> >> Currently the draft only specifies that the "sos" parameter >> only conveys information that the request/response is related >> to an emergency session. But I do find your use case valid. >> I'd like to know what others think, but can propose the >> extension in version-01 if there is wider support. >> >> Best regards, >> Milan >> >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of John-Luc Bakker >> Sent: 03 October 2008 14:32 >> To: ECRIT >> Subject: Re: [Ecrit] [Fwd: I-D >> Action:draft-patel-ecrit-sos-parameter-00.txt] >> >> Milan, >> >> The proposed new URI parameter is opaque. It marks the call >> as an emergency call but fails to convey the emergency call >> type even if an emergency call type could be deduced from the >> original request. >> Particularly if the Emergency Service URN in the Request-URI >> is replaced by a network entity, as you suggest, not loosing >> the emergency call type information seems useful. In some >> deployments, emergency calls are routed to PSAPs that support >> the requested emergency types. >> >> Kind regards, >> >> John-Luc >> >> On Mon, Sep 15, 2008 at 3:24 AM, Hannes Tschofenig >> wrote: >> > Please take a look at this document. Milan would like to hear some >> comments! >> > >> > Ciao >> > Hannes >> > >> > -------- Original Message -------- >> > Subject: I-D Action:draft-patel-ecrit-sos-parameter-00.txt >> > Date: Fri, 12 Sep 2008 09:45:01 -0700 (PDT) >> > From: Internet-Drafts@ietf.org >> > Reply-To: internet-drafts@ietf.org >> > To: i-d-announce@ietf.org >> > >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > >> > Title : SOS Uniform Resource Identifier (URI) >> parameter for marking of Session Initiation Protocol (SIP) >> requests related to emergency services >> > Author(s) : M. Patel >> > Filename : draft-patel-ecrit-sos-parameter-00.txt >> > Pages : 9 >> > Date : 2008-09-12 >> > >> > This memo describes requirements and protocol conventions for a new >> > SIP (Session Initiation Protocol) URI parameter intended >> for marking >> > SIP requests and responses related to emergency services. This >> > proposal addresses issues that exist in the current 3rd Generation >> > Partnership Project IP Multimedia Subsystem (IMS) Emergency >> services >> > solution, but is not precluded from being used by other SIP-based >> > emergency services solutions. It is not intended as a >> replacement for >> > the service URN. >> > >> > A URL for this Internet-Draft is: >> > >> > http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-parameter-00.t > xt >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > Below is the data which will enable a MIME compliant mail reader >> > implementation to automatically retrieve the ASCII version of the >> > Internet-Draft. >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 23 06:18:10 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 809423A6827; Thu, 23 Oct 2008 06:18:10 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1773A6827 for ; Thu, 23 Oct 2008 06:18:09 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NRzHhUVHtUO for ; Thu, 23 Oct 2008 06:17:57 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id DA3983A681B for ; Thu, 23 Oct 2008 06:17:56 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m9NDIOIF005890; Thu, 23 Oct 2008 08:19:11 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.11]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Oct 2008 08:18:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 23 Oct 2008 08:18:54 -0500 Message-ID: <0AB57A5DEF898646A069F23604A2635301D9A0D5@ILEXC2U01.ndc.lucent.com> In-Reply-To: <385b0c950810221043ie014a97h5c46274cdc14b981@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] Thread-Index: Ack0bamSfM5EDaJtRrS4+g5sA7bd6gAlxjUw References: <0AB57A5DEF898646A069F23604A2635301D3D9FE@ILEXC2U01.ndc.lucent.com> <385b0c950810221043ie014a97h5c46274cdc14b981@mail.gmail.com> From: "Barclay, Deborah L (Deb)" To: "John-Luc Bakker" X-OriginalArrivalTime: 23 Oct 2008 13:18:59.0614 (UTC) FILETIME=[E8F953E0:01C93511] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: ecrit@ietf.org Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi John-Luc, I have provided responses to your questions. See "dlb>" below. Thanks, Deb > -----Original Message----- > From: John-Luc Bakker [mailto:jlbakker.ietf@googlemail.com] > Sent: Wednesday, October 22, 2008 12:43 PM > To: Barclay, Deborah L (Deb) > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] [Fwd: I-D > Action:draft-patel-ecrit-sos-parameter-00.txt] > > Hi Deb, > > Thanks for commenting. > RFC 5031 mentions a generic emergency URN and emergency URNs > for specific emergency service types; such as > "urn:service:sos.gas" or other locally relevant types (e.g > "urn:service:sos.eletricity?"). > Would an INVITE, for the purposes of making a call back, from > a UAS handling urn:service:sos. calls > also include the sos parameter? Dlb> If sos.gas was sent by the UE to make the original call and supported by the network, then according to rfc5031, it is an emergency service requiring immediate response and it was not used for general services. Therefore, it seems that the jurisdictions that treat sos.gas as an emergency call would then treat the callback as a callback for an emergency call - and would include the indicator. This is consistent with ecrit phonebcp, it would be treated as an emergency callback because emergency callback is determined "by retaining the domain of the PSAP which answers an outgoing emergency call". Do you agree with this analysis? > > In case the UAC failed to recognize the request as a > emergency session request and the local network translates, > say "121", to "urn:service:sos.electricity", would the UAC > still receive an opaque "sos" indicator? Dlb> Assuming this is a bad example and meant one that is in the rfc (electricity is not)then, applying the same logic, yes, if the network determined it was an emergency call then the sos indicator applies since rfc5031 says sos service urns should only be used for emergencies requiring an immediate response and should not be used for general services. Do you agree? > > In case emergency service type information is available, I > see no harm in indicating the emergency service type > information to the UAC. I am not sure what "efficiency" is > gained by not indicating emergency service type information > using a few extra characters in a SIP message. Dlb> There aren't any 3GPP requirements/procedures (or ecrit) for emergency call handling, other than the ability to route to different destinations, that alter handling based on a sub-service type (e.g., the MMtel interaction procedures are just for emergency calls and callback - nothing different depending on subservice type). So I don't see the need to define sub-service types for the sos parameter. Do you agree? :) > > Kind regards, > > John-Luc > > On Fri, Oct 10, 2008 at 4:50 PM, Barclay, Deborah L (Deb) > wrote: > > > > Milan, John-Luc, > > > > For the example provided below, the service-urn would be > replaced as a > > result of determining the call is routed to a CS PSAP. The > > service-urn is preserved until the routing function determines the > > appropriate emergency center and only replaces the > service-urn because > > it had to be converted to a digits. If different > service-urns require > > different destinations, that would have been accounted for. The > > single sos parameter should be sufficient for proper emergency call > > handling and the service-urn is available and sufficient > for correct routing. > > > > Since opinions were being sought, my opinion is to keep the sos > > parameter/marker simple for efficient emergency call > handling purposes. > > > > Thank you, > > Deb Barclay > > > >> ------------------------------ > >> > >> Message: 2 > >> Date: Fri, 3 Oct 2008 14:45:08 +0100 > >> From: "Milan Patel" > >> Subject: Re: [Ecrit] [Fwd: I-D > >> Action:draft-patel-ecrit-sos-parameter-00.txt] > >> To: "John-Luc Bakker" , "ECRIT" > >> > >> Message-ID: > >> > >> <0913B6CD18F370498CD65864CF254E9006BFCF94@zharhxm1.corp.nortel.com> > >> Content-Type: text/plain; charset="us-ascii" > >> > >> Hi John-Luc, > >> > >> Currently the draft only specifies that the "sos" parameter only > >> conveys information that the request/response is related to an > >> emergency session. But I do find your use case valid. > >> I'd like to know what others think, but can propose the > extension in > >> version-01 if there is wider support. > >> > >> Best regards, > >> Milan > >> > >> > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> Behalf Of John-Luc Bakker > >> Sent: 03 October 2008 14:32 > >> To: ECRIT > >> Subject: Re: [Ecrit] [Fwd: I-D > >> Action:draft-patel-ecrit-sos-parameter-00.txt] > >> > >> Milan, > >> > >> The proposed new URI parameter is opaque. It marks the call as an > >> emergency call but fails to convey the emergency call type > even if an > >> emergency call type could be deduced from the original request. > >> Particularly if the Emergency Service URN in the Request-URI is > >> replaced by a network entity, as you suggest, not loosing the > >> emergency call type information seems useful. In some deployments, > >> emergency calls are routed to PSAPs that support the requested > >> emergency types. > >> > >> Kind regards, > >> > >> John-Luc > >> > >> On Mon, Sep 15, 2008 at 3:24 AM, Hannes Tschofenig > >> wrote: > >> > Please take a look at this document. Milan would like to > hear some > >> comments! > >> > > >> > Ciao > >> > Hannes > >> > > >> > -------- Original Message -------- > >> > Subject: I-D Action:draft-patel-ecrit-sos-parameter-00.txt > >> > Date: Fri, 12 Sep 2008 09:45:01 -0700 (PDT) > >> > From: Internet-Drafts@ietf.org > >> > Reply-To: internet-drafts@ietf.org > >> > To: i-d-announce@ietf.org > >> > > >> > > >> > > >> > A New Internet-Draft is available from the on-line > Internet-Drafts > >> directories. > >> > > >> > Title : SOS Uniform Resource Identifier (URI) > >> parameter for marking of Session Initiation Protocol (SIP) > requests > >> related to emergency services > >> > Author(s) : M. Patel > >> > Filename : draft-patel-ecrit-sos-parameter-00.txt > >> > Pages : 9 > >> > Date : 2008-09-12 > >> > > >> > This memo describes requirements and protocol > conventions for a new > >> > SIP (Session Initiation Protocol) URI parameter intended > >> for marking > >> > SIP requests and responses related to emergency services. This > >> > proposal addresses issues that exist in the current 3rd > Generation > >> > Partnership Project IP Multimedia Subsystem (IMS) Emergency > >> services > >> > solution, but is not precluded from being used by other > SIP-based > >> > emergency services solutions. It is not intended as a > >> replacement for > >> > the service URN. > >> > > >> > A URL for this Internet-Draft is: > >> > > >> > > > http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-parameter-00 > > .t > > xt > >> > > >> > Internet-Drafts are also available by anonymous FTP at: > >> > ftp://ftp.ietf.org/internet-drafts/ > >> > > >> > Below is the data which will enable a MIME compliant mail reader > >> > implementation to automatically retrieve the ASCII > version of the > >> > Internet-Draft. > >> > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 23 07:51:24 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C82903A6AD6; Thu, 23 Oct 2008 07:51:24 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F683A6A29 for ; Thu, 23 Oct 2008 07:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPo4YmlnhD4Q for ; Thu, 23 Oct 2008 07:51:15 -0700 (PDT) Received: from mail-gx0-f16.google.com (mail-gx0-f16.google.com [209.85.217.16]) by core3.amsl.com (Postfix) with ESMTP id DBC713A6AD6 for ; Thu, 23 Oct 2008 07:51:09 -0700 (PDT) Received: by gxk9 with SMTP id 9so79920gxk.13 for ; Thu, 23 Oct 2008 07:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=yJioBUTfdjRr7lQGTqxDMpPhf2sv3tCrzuiEuTnyVks=; b=MBelZWi9GdJWHoucynOt4oretH5ktvfYo5YygDMQ+3kkmDNgSFnJ30SySeiuhkC9Sg Zr2QyaINhmpqGQvf368i2wJQxHa98DxOiQfjDMGnMTyJ6FEBXIPS0bzniEnLkB0qw6nj kGrCsfecBTDPBD5dMs/jX50X3zj4ZY9kYes1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=EGNa+XPYanTqRIDUgz1AKy7/6fqw8GzChUEG4q7bVLg7QnzCv9Xl4NYSE+XdG3Ob6F g+zwCgGSfwU7aua16H7NSHOt+WyR/Wvg+5VKpZkbkeL//lKlltGzfObh61FTIWUsnFI3 KzSTv5f0SeOezWM7u/Tq7kSVfnyo3wCUdDk7w= Received: by 10.150.157.17 with SMTP id f17mr3968623ybe.81.1224773544291; Thu, 23 Oct 2008 07:52:24 -0700 (PDT) Received: by 10.150.140.2 with HTTP; Thu, 23 Oct 2008 07:52:24 -0700 (PDT) Message-ID: <385b0c950810230752h6179e3a1u284c64632bbe11a6@mail.gmail.com> Date: Thu, 23 Oct 2008 09:52:24 -0500 From: "John-Luc Bakker" To: "Barclay, Deborah L (Deb)" In-Reply-To: <0AB57A5DEF898646A069F23604A2635301D9A0D5@ILEXC2U01.ndc.lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <0AB57A5DEF898646A069F23604A2635301D3D9FE@ILEXC2U01.ndc.lucent.com> <385b0c950810221043ie014a97h5c46274cdc14b981@mail.gmail.com> <0AB57A5DEF898646A069F23604A2635301D9A0D5@ILEXC2U01.ndc.lucent.com> Cc: ecrit@ietf.org Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Deb, Thank you for your swift responses! Similarly, see below. On Thu, Oct 23, 2008 at 8:18 AM, Barclay, Deborah L (Deb) wrote: > Hi John-Luc, > > I have provided responses to your questions. See "dlb>" below. > > Thanks, > Deb > >> -----Original Message----- >> From: John-Luc Bakker [mailto:jlbakker.ietf@googlemail.com] >> Sent: Wednesday, October 22, 2008 12:43 PM >> To: Barclay, Deborah L (Deb) >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] [Fwd: I-D >> Action:draft-patel-ecrit-sos-parameter-00.txt] >> >> Hi Deb, >> >> Thanks for commenting. >> RFC 5031 mentions a generic emergency URN and emergency URNs >> for specific emergency service types; such as >> "urn:service:sos.gas" or other locally relevant types (e.g >> "urn:service:sos.eletricity?"). >> Would an INVITE, for the purposes of making a call back, from >> a UAS handling urn:service:sos. calls >> also include the sos parameter? > > Dlb> If sos.gas was sent by the UE to make the original call and > supported by the network, then according to rfc5031, it is an emergency > service requiring immediate response and it was not used for general > services. Therefore, it seems that the jurisdictions that treat sos.gas > as an emergency call would then treat the callback as a callback for an > emergency call - and would include the indicator. This is consistent > with ecrit phonebcp, it would be treated as an emergency callback > because emergency callback is determined "by retaining the domain of the > PSAP which answers an outgoing emergency call". Do you agree with this > analysis? What is the case for not including the emergency type information? A UE may handle PSAP call backs for different emergency types differently. E.g. calls backs from a PSAP handling requests for "animal-control" may get different treatment when another PSAP call back is in progress. >> In case the UAC failed to recognize the request as a >> emergency session request and the local network translates, >> say "121", to "urn:service:sos.electricity", would the UAC >> still receive an opaque "sos" indicator? > > Dlb> Assuming this is a bad example and meant one that is in the rfc > (electricity is not)then, applying the same logic, yes, if the network > determined it was an emergency call then the sos indicator applies since > rfc5031 says sos service urns should only be used for emergencies > requiring an immediate response and should not be used for general > services. Do you agree? I agree that "electricity" is not presently in the RFC however the RFC does outline how the set of emergency types can be enhanced so urn:service:sos.electricity may make it into the set with emergency types at some point. Clearly, a solution needs to take into account evolution of the set of emergency service types. Hypothetics aside, if the network determines that a call with some digits in the R-URI is an emergency call and the network determines that the request requests a certain emergency service type (e.g. gas or poison or animal-control per RFC) then it would be useful to indicate to the UAC what type of undetected emergency call was made. A UAC may be configured differently for dealing with certain emergency call types, e.g. a user request for privacy of location information may or may not apply for certain emergency types. It is demonstrated that the network can deduce the emergency service type from the dialed digits so not informing the UAC of that bit of information seems unnecessary restrictive. I am not aware of requirements that the emergency service type MUST not be indicated. What is the case for not including emergency type information? >> In case emergency service type information is available, I >> see no harm in indicating the emergency service type >> information to the UAC. I am not sure what "efficiency" is >> gained by not indicating emergency service type information >> using a few extra characters in a SIP message. > > Dlb> There aren't any 3GPP requirements/procedures (or ecrit) for > emergency call handling, other than the ability to route to different > destinations, that alter handling based on a sub-service type (e.g., the > MMtel interaction procedures are just for emergency calls and callback - > nothing different depending on subservice type). So I don't see the > need to define sub-service types for the sos parameter. Do you agree? > :) Recognizing emergency service types has more uses than "routing". Including a subservice type is also useful if the local jurisdiction doesn't recognize a call to e.g. "animal-control" as an emergency. For example, because a PSAP and the rest of the infrastructure wasn't designed for the increased load if such calls are required to receive emergency call treatment. Having a discussion of whether or not to be able to indicate subservice types using the sos parameter seems a discussion in scope of the ECRIT list. Absence of the information may have undesirable side effects as indicated above. I fail to see the efficiency gain by not including it. AFAIK no case has been made for not including it when the information is available. >> Kind regards, >> >> John-Luc >> >> On Fri, Oct 10, 2008 at 4:50 PM, Barclay, Deborah L (Deb) >> wrote: >> > >> > Milan, John-Luc, >> > >> > For the example provided below, the service-urn would be >> replaced as a >> > result of determining the call is routed to a CS PSAP. The >> > service-urn is preserved until the routing function determines the >> > appropriate emergency center and only replaces the >> service-urn because >> > it had to be converted to a digits. If different >> service-urns require >> > different destinations, that would have been accounted for. The >> > single sos parameter should be sufficient for proper emergency call >> > handling and the service-urn is available and sufficient >> for correct routing. >> > >> > Since opinions were being sought, my opinion is to keep the sos >> > parameter/marker simple for efficient emergency call >> handling purposes. >> > >> > Thank you, >> > Deb Barclay >> > >> >> ------------------------------ >> >> >> >> Message: 2 >> >> Date: Fri, 3 Oct 2008 14:45:08 +0100 >> >> From: "Milan Patel" >> >> Subject: Re: [Ecrit] [Fwd: I-D >> >> Action:draft-patel-ecrit-sos-parameter-00.txt] >> >> To: "John-Luc Bakker" , "ECRIT" >> >> >> >> Message-ID: >> >> >> >> <0913B6CD18F370498CD65864CF254E9006BFCF94@zharhxm1.corp.nortel.com> >> >> Content-Type: text/plain; charset="us-ascii" >> >> >> >> Hi John-Luc, >> >> >> >> Currently the draft only specifies that the "sos" parameter only >> >> conveys information that the request/response is related to an >> >> emergency session. But I do find your use case valid. >> >> I'd like to know what others think, but can propose the >> extension in >> >> version-01 if there is wider support. >> >> >> >> Best regards, >> >> Milan >> >> >> >> >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> >> Behalf Of John-Luc Bakker >> >> Sent: 03 October 2008 14:32 >> >> To: ECRIT >> >> Subject: Re: [Ecrit] [Fwd: I-D >> >> Action:draft-patel-ecrit-sos-parameter-00.txt] >> >> >> >> Milan, >> >> >> >> The proposed new URI parameter is opaque. It marks the call as an >> >> emergency call but fails to convey the emergency call type >> even if an >> >> emergency call type could be deduced from the original request. >> >> Particularly if the Emergency Service URN in the Request-URI is >> >> replaced by a network entity, as you suggest, not loosing the >> >> emergency call type information seems useful. In some deployments, >> >> emergency calls are routed to PSAPs that support the requested >> >> emergency types. >> >> >> >> Kind regards, >> >> >> >> John-Luc >> >> >> >> On Mon, Sep 15, 2008 at 3:24 AM, Hannes Tschofenig >> >> wrote: >> >> > Please take a look at this document. Milan would like to >> hear some >> >> comments! >> >> > >> >> > Ciao >> >> > Hannes >> >> > >> >> > -------- Original Message -------- >> >> > Subject: I-D Action:draft-patel-ecrit-sos-parameter-00.txt >> >> > Date: Fri, 12 Sep 2008 09:45:01 -0700 (PDT) >> >> > From: Internet-Drafts@ietf.org >> >> > Reply-To: internet-drafts@ietf.org >> >> > To: i-d-announce@ietf.org >> >> > >> >> > >> >> > >> >> > A New Internet-Draft is available from the on-line >> Internet-Drafts >> >> directories. >> >> > >> >> > Title : SOS Uniform Resource Identifier (URI) >> >> parameter for marking of Session Initiation Protocol (SIP) >> requests >> >> related to emergency services >> >> > Author(s) : M. Patel >> >> > Filename : draft-patel-ecrit-sos-parameter-00.txt >> >> > Pages : 9 >> >> > Date : 2008-09-12 >> >> > >> >> > This memo describes requirements and protocol >> conventions for a new >> >> > SIP (Session Initiation Protocol) URI parameter intended >> >> for marking >> >> > SIP requests and responses related to emergency services. This >> >> > proposal addresses issues that exist in the current 3rd >> Generation >> >> > Partnership Project IP Multimedia Subsystem (IMS) Emergency >> >> services >> >> > solution, but is not precluded from being used by other >> SIP-based >> >> > emergency services solutions. It is not intended as a >> >> replacement for >> >> > the service URN. >> >> > >> >> > A URL for this Internet-Draft is: >> >> > >> >> >> > >> http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-parameter-00 >> > .t >> > xt >> >> > >> >> > Internet-Drafts are also available by anonymous FTP at: >> >> > ftp://ftp.ietf.org/internet-drafts/ >> >> > >> >> > Below is the data which will enable a MIME compliant mail reader >> >> > implementation to automatically retrieve the ASCII >> version of the >> >> > Internet-Draft. >> >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 27 00:48:04 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C178328C153; Mon, 27 Oct 2008 00:48:04 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349F83A68CC for ; Mon, 27 Oct 2008 00:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.334, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VC7069+eRGe for ; Mon, 27 Oct 2008 00:48:03 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id BB45628C153 for ; Mon, 27 Oct 2008 00:48:02 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9R7m08E026852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 27 Oct 2008 08:48:00 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9R7lw9u025667 for ; Mon, 27 Oct 2008 08:48:00 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 08:47:59 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 08:47:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Oct 2008 09:47:58 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interim meeting in January Thread-Index: Ack4CFRtAxCsM52vSxOVXLl9eSTH7Q== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 27 Oct 2008 07:47:59.0253 (UTC) FILETIME=[54EDBC50:01C93808] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081027084800-63991BB0-DF929778/0-0/0-15 X-purgate-size: 947/0 Subject: [Ecrit] Interim meeting in January X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0775552239==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0775552239== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93808.549C3BA4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C93808.549C3BA4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let me know ASAP if you would like to have an interim meeting in January next year.=20 ------_=_NextPart_001_01C93808.549C3BA4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Interim meeting in January

Let me know ASAP if you would = like to have an interim meeting in January next year.=20

------_=_NextPart_001_01C93808.549C3BA4-- --===============0775552239== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============0775552239==-- From ecrit-bounces@ietf.org Mon Oct 27 01:39:52 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A73DE3A689B; Mon, 27 Oct 2008 01:39:52 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13E1D3A6851 for ; Mon, 27 Oct 2008 01:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=-2.780, BAYES_50=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 404r4lJM+8iO for ; Mon, 27 Oct 2008 01:39:50 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id D8E413A67CC for ; Mon, 27 Oct 2008 01:39:49 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9R8dloZ027224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Oct 2008 09:39:47 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9R8dk5T006141; Mon, 27 Oct 2008 09:39:47 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 09:39:08 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.16]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 09:39:07 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Oct 2008 10:37:20 +0200 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ATOCA BOF Request Text Thread-Index: AckuLTBcAW5j2MyKQ9u7o+tRVlTalAJ4gFKg References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Rosen, Brian" , "ECRIT" X-OriginalArrivalTime: 27 Oct 2008 08:39:07.0702 (UTC) FILETIME=[79DDE560:01C9380F] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081027093947-63999BB0-47CCF873/0-0/0-15 X-purgate-size: 4329/0 Subject: Re: [Ecrit] ATOCA BOF Request Text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Brian, Please inform us about the status of the BOF. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Rosen, Brian >Sent: 14 October, 2008 21:47 >To: ECRIT >Subject: [Ecrit] ATOCA BOF Request Text > >ATOCA BOF > >Authority-to-Citizen Alert > > >Mailing Lists: earlywarn@ietf.org > > >BOF chairs: > > >Brian Rosen [brian.rosen at neustar.biz] > > >Steve Norreys [steve.norreys@bt.com] > > >Temporary Area Directorate: Real Time Applications (RAI) > > >Ultimate Area Directorate: TBD > > >BOF Purpose. > >ecrit is working on citizen-to-authority calls. Alerts that >are sent from "authorities" >(which we define broadly to any level of authority, including, >for example, a school >administrator) to "citizen" (which we also define broadly to >include visitors and other individuals and groups) are of >great interest. Many efforts are underway in other fora, but >all of them are stovepipes: limited by which authorities can >invoke alerts as well as which networks they can be >distributed on. What is needed is a more flexible way to >deliver alerts from any notifier to any interested or affected >individual, via any device connected to the Internet. > >This is a large problem: some alerts must be delivered to an >enormous number of endpoints; a Tsunami warning may involve >millions of devices eventually. A system which can deliver >messages to billions of endpoints with one notification are >obviously attractive attack targets. This is further >complicated by the desire to accept notifications from a wide >variety of notifiers, complicating authentication mechanisms >that might be employed. >The security implications of any solutions must be addressed >as a intergral part of the >solution from the very start of the work. > >Classic alert systems typically use layer 2 broadcast >mechanisms and often use some kind of location as a criteria >for who gets the alert. On the Internet, multicast mechanisms >may be helpful, but the paucity of multicast deployment must >be considered. >Besides broadcast, >which certainly is very appropriate, it is very useful to be >able to subscribe to events for individuals who may not >normally meet criteria for being included in a broadcast. >For example, parents may wish to receive alerts that affect >their children. An alert directed to anyone in the path of a >hurricane may be broadcast, but the parent may need a >subscription to get the same alert when they are not in the >affected area. > >The content of an alert is also a significant challenge to >Internet scale alerts. The alert must be rendered on a wide >variety of devices with different user interface capabilities. >Multiple languages have to be accomodated. Networks with >limited bandwidth must be considered. > >Alert work is being done in many fora, and some is directly >applicable to this work. For example, OASIS work on Common >Alerting Protocol is likely part of the solution. It should >also be recognised that this is an area of work that will be >highly regulated and as such close work with the fora where >regulators operate (e.g. ATIS, ETSI and ITU-T) may help with >the deployment of any solutions. > >The purpose of the BOF is to determine the need and scope for >authority to citizen alerts, what existing protocols and >mechansims need to be adapted to meet those needs and the >appropriate representation for alerts should be. > >This work could be accomplished within an expanded charter of >ecrit, or a new work group could be formed. This work will >leverage geopriv work on location. > > >Proposed Deliverables: > > >1) Requirements for ATOCA . >2) An ATOCA Framework. >3) Various protocol and mechanism enhancements to meet the >requirements identified > > >Input Documents: > > >1) Requirements >draft-norreys-ecrit-authority2individuals-requirements-01.txt > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 27 04:49:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 987C53A6A2A; Mon, 27 Oct 2008 04:49:25 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D763D3A69CC; Mon, 27 Oct 2008 04:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+GnoYN+wmKS; Mon, 27 Oct 2008 04:49:21 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 80C9E3A69EF; Mon, 27 Oct 2008 04:49:21 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9RBnJD7000703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Oct 2008 12:49:19 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9RBnGsq010607; Mon, 27 Oct 2008 12:49:19 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 12:49:11 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.16]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 12:49:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Oct 2008 13:49:39 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Interim Meeting Opportunity in January 2009 Thread-Index: AckyEW0uQ2P+BHW7RPqTb+mqLvqD5wGGBYAw From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" , , X-OriginalArrivalTime: 27 Oct 2008 11:49:11.0087 (UTC) FILETIME=[06D05BF0:01C9382A] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081027124919-63996BB0-C09AB10F/0-0/0-15 X-purgate-size: 2561/0 Subject: [Ecrit] FW: WG Interim Meeting Opportunity in January 2009 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It seems that not everyone is following various discussions on IETF mailing lists and is therefore not informed about the new plans of our IETF Chair Russ Housely. Here is a forward: >-----Original Message----- >From: wgchairs-bounces@ietf.org >[mailto:wgchairs-bounces@ietf.org] On Behalf Of IETF Chair >Sent: 16 October, 2008 23:34 >To: Working Group Chairs >Cc: chair@ietf.org >Subject: WG Interim Meeting Opportunity in January 2009 > >In our continuing effort to ensure that IETF WGs are getting >enough meeting time to progress their work, we are conducting >another experiment. > Many WGs have found interim meetings an effective way to >tackle thorny technical issues, resolve contentious technical >issues, accelerate standards development, and provide traction >for new work. As always, an interim WG meeting is not a >substitute for a regular session at the traditional IETF >meeting. Since some WG Chairs and ADs have found the amount >of time necessary to put together an interim meeting can be >excessive, we are trying to reduce the effort necessary to >conduct an interim meeting to determine whether reducing this >burden will expedite IETF standards development. To this end, >the Secretariat will facilitate a large interim meeting from >20-22 January 2009 in Malta. If you are interested in >participating in this experiment, please contact your Area >Director for approval. All face-to-face interim meetings >require AD approval, and this is no exception. The IETF >Secretariat is putting together a program with three full days >and four tracks on each day. Each WG interim meeting is >expected to consume at least one full day on one of the tracks. > >ADs will schedule the sessions. A URL for the schedule will >be announced shortly. Once it is available, if you detect a >scheduling conflict, please raise the concern with your AD for >resolution. Session time is limited, and sessions will be >allocated first come, first served. > >The Secretariat will provide registration, food and beverage, >audio visual facilities, and on site registration support. >VeriLAN will provide network and audio streaming support. It >is expected that the meeting fee will be $375 for early >registration and $475 for late registration. > >The Internet Society is looking for meeting sponsors for this event. >Anyone interested please contact Drew Dvorshak . > >Russ > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 27 05:54:31 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16DD3A68DD; Mon, 27 Oct 2008 05:54:31 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7963A680D for ; Mon, 27 Oct 2008 05:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KPksoL2+9IX for ; Mon, 27 Oct 2008 05:54:30 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 44EBF3A6A82 for ; Mon, 27 Oct 2008 05:54:30 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KuRc1-0001RJ-C7; Mon, 27 Oct 2008 07:54:25 -0500 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: In-Reply-To: Date: Mon, 27 Oct 2008 08:54:17 -0400 Message-ID: <030801c93833$20e7f5d0$62b7e170$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack4CFRtAxCsM52vSxOVXLl9eSTH7QAKq45A Content-language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Interim meeting in January X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1176067488==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1176067488== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0309_01C93811.99D655D0" Content-language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0309_01C93811.99D655D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I probably could not get travel approval for Malta. Brian From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Monday, October 27, 2008 3:48 AM To: ECRIT Subject: [Ecrit] Interim meeting in January Let me know ASAP if you would like to have an interim meeting in January next year. ------=_NextPart_000_0309_01C93811.99D655D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Interim meeting in January

I probably could not get travel approval for Malta.  =

 

Brian

 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Monday, October 27, 2008 3:48 AM
To: ECRIT
Subject: [Ecrit] Interim meeting in January

 

Let me = know ASAP if you would like to have an interim meeting in January next year. =

------=_NextPart_000_0309_01C93811.99D655D0-- --===============1176067488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1176067488==-- From ecrit-bounces@ietf.org Mon Oct 27 05:55:31 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8303A6A82; Mon, 27 Oct 2008 05:55:31 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAEF83A6A86 for ; Mon, 27 Oct 2008 05:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.159 X-Spam-Level: X-Spam-Status: No, score=0.159 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_50=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5uiC4yvAyZe for ; Mon, 27 Oct 2008 05:55:28 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 888183A68DD for ; Mon, 27 Oct 2008 05:55:28 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KuRcx-0001Tw-Nx; Mon, 27 Oct 2008 07:55:24 -0500 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "Rosen, Brian" , "'ECRIT'" References: In-Reply-To: Date: Mon, 27 Oct 2008 08:55:16 -0400 Message-ID: <030d01c93833$446d2160$cd476420$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckuLTBcAW5j2MyKQ9u7o+tRVlTalAJ4gFKgAAj8GYA= Content-language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] ATOCA BOF Request Text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I have heard from the ADs that they are going to postpone the BOF due to scheduling issues with the "Where are we going with RAI" discussion. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Monday, October 27, 2008 4:37 AM To: ext Rosen, Brian; ECRIT Subject: Re: [Ecrit] ATOCA BOF Request Text Hi Brian, Please inform us about the status of the BOF. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Rosen, Brian >Sent: 14 October, 2008 21:47 >To: ECRIT >Subject: [Ecrit] ATOCA BOF Request Text > >ATOCA BOF > >Authority-to-Citizen Alert > > >Mailing Lists: earlywarn@ietf.org > > >BOF chairs: > > >Brian Rosen [brian.rosen at neustar.biz] > > >Steve Norreys [steve.norreys@bt.com] > > >Temporary Area Directorate: Real Time Applications (RAI) > > >Ultimate Area Directorate: TBD > > >BOF Purpose. > >ecrit is working on citizen-to-authority calls. Alerts that >are sent from "authorities" >(which we define broadly to any level of authority, including, >for example, a school >administrator) to "citizen" (which we also define broadly to >include visitors and other individuals and groups) are of >great interest. Many efforts are underway in other fora, but >all of them are stovepipes: limited by which authorities can >invoke alerts as well as which networks they can be >distributed on. What is needed is a more flexible way to >deliver alerts from any notifier to any interested or affected >individual, via any device connected to the Internet. > >This is a large problem: some alerts must be delivered to an >enormous number of endpoints; a Tsunami warning may involve >millions of devices eventually. A system which can deliver >messages to billions of endpoints with one notification are >obviously attractive attack targets. This is further >complicated by the desire to accept notifications from a wide >variety of notifiers, complicating authentication mechanisms >that might be employed. >The security implications of any solutions must be addressed >as a intergral part of the >solution from the very start of the work. > >Classic alert systems typically use layer 2 broadcast >mechanisms and often use some kind of location as a criteria >for who gets the alert. On the Internet, multicast mechanisms >may be helpful, but the paucity of multicast deployment must >be considered. >Besides broadcast, >which certainly is very appropriate, it is very useful to be >able to subscribe to events for individuals who may not >normally meet criteria for being included in a broadcast. >For example, parents may wish to receive alerts that affect >their children. An alert directed to anyone in the path of a >hurricane may be broadcast, but the parent may need a >subscription to get the same alert when they are not in the >affected area. > >The content of an alert is also a significant challenge to >Internet scale alerts. The alert must be rendered on a wide >variety of devices with different user interface capabilities. >Multiple languages have to be accomodated. Networks with >limited bandwidth must be considered. > >Alert work is being done in many fora, and some is directly >applicable to this work. For example, OASIS work on Common >Alerting Protocol is likely part of the solution. It should >also be recognised that this is an area of work that will be >highly regulated and as such close work with the fora where >regulators operate (e.g. ATIS, ETSI and ITU-T) may help with >the deployment of any solutions. > >The purpose of the BOF is to determine the need and scope for >authority to citizen alerts, what existing protocols and >mechansims need to be adapted to meet those needs and the >appropriate representation for alerts should be. > >This work could be accomplished within an expanded charter of >ecrit, or a new work group could be formed. This work will >leverage geopriv work on location. > > >Proposed Deliverables: > > >1) Requirements for ATOCA . >2) An ATOCA Framework. >3) Various protocol and mechanism enhancements to meet the >requirements identified > > >Input Documents: > > >1) Requirements >draft-norreys-ecrit-authority2individuals-requirements-01.txt > > > >_______________________________________________ >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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 27 06:39:47 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EDDE3A6AD0; Mon, 27 Oct 2008 06:39:47 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68693A6842 for ; Mon, 27 Oct 2008 06:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnKHmoIpLmuf for ; Mon, 27 Oct 2008 06:39:45 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by core3.amsl.com (Postfix) with ESMTP id 841353A6AE3 for ; Mon, 27 Oct 2008 06:39:44 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id b39so221230ugd.15 for ; Mon, 27 Oct 2008 06:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=ZiWSycxRr2bGzTNkdgjr0nATBXXBvewQ5Ok7njgOtOE=; b=NF7iDCwsO1IQkpQjm/EQnz/DgPuTzsDJqnZKhMz/Gcpo8jC23hEh+0WwbZiwLuA1Yc yC7tmhmP8A/X6gq4VF68SIXJ/YhBGS1I+e0kCnNeeEEy9IrbLeWqAvfRAHsUZVfAyPIL HD17JC2cc+EFHAVzwgp5cS7X1PalqMZGHCZq4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=dc2KajTo7iaWWEIyzGK8x/6hcrQyRm9wEAiCM86jejFNoM7ntOTzpHPC71IDtBtFQc gIPPzq9JNYiMlYlTC7veKgrzXrW+C0QzdugVOVhJy6melg2KncNlfOO97ClgJi+kdsgY /Me50HQu2fHxjgqcAdPLBox/PQHoBFE6yym40= Received: by 10.66.218.15 with SMTP id q15mr2053656ugg.77.1225114782737; Mon, 27 Oct 2008 06:39:42 -0700 (PDT) Received: by 10.67.122.13 with HTTP; Mon, 27 Oct 2008 06:39:41 -0700 (PDT) Message-ID: Date: Mon, 27 Oct 2008 17:39:41 +0400 From: "Richard Barnes" To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: MIME-Version: 1.0 References: Cc: ECRIT Subject: Re: [Ecrit] ECRIT WG Rechartering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0760795021==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============0760795021== Content-Type: multipart/alternative; boundary="----=_Part_580_21210554.1225114782713" ------=_Part_580_21210554.1225114782713 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think there are a few milestones missing from this charter: -- A Standards-Track document describing how SIP messages related to emergency calling are distinguished from other messages(draft-patel-ecrit-sos-parameter) 3GPP have made it pretty clear (both on this list and last week at the emergency services workshop) that this mechanism or something like it is a requirement for their emergency calling system. -- An Informational document describing requirements for emergency calling by unregistered or unauthenticated devices. (draft-schulzrinne-ecrit-unauthenticated access) This is an issue that ECRIT has avoided for a long time, as other SDOs have been developing mechanisms. It would be useful to have an Internet-level analysis to unify these lower-level approaches and guide their development. -- An Informational document describing best practices for emergency calling from autonomous devices (vs. human callers) (draft-rosen-ecrit-ecall) Lots of different organizations (e.g., EU eCall and OGC's sensor web) are interested in having sensors or other devices place emergency calls. These efforts could be more interoperable and better aligned with the ECRIT architecture if it were made explicit which subset of the ECRIT framework these systems should use. Cheers, --Richard On Tue, Oct 14, 2008 at 10:13 AM, Tschofenig, Hannes (NSN - FI/Espoo) < hannes.tschofenig@nsn.com> wrote: > Here is a first proposal for the ECRIT WG rechartering based on the > discussions we had around IETF#72. > For the moment, I have put 3 additional documents onto the charter: > http://tools.ietf.org/id/draft-polk-ecrit-local-emergency-rph-namespace- > 03.txt > http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc-00.txt > http://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00.txt > > Regarding the following two documents > http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.txt > http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-00.txt > I am waiting for additional feedback from the draft authors on how they > perceive these documents should be progressed through the IETF, see my > mail here: > http://www.ietf.org/mail-archive/web/ecrit/current/msg05518.html > > Please take a look at it and give me feedback till the 21st October > 2008. > > ------------------------------------------------------------------------ > --------------------------- > > Emergency Context Resolution with Internet Technologies (ecrit) > > Description of Working Group: > > In a number of areas, the public switched telephone network (PSTN) has > been configured to recognize an explicitly specified number (commonly > one that is short and easily memorized) as a call for emergency > services. These numbers (e.g. 911, 112) relate to an emergency > service context and depend on a broad, regional configuration of > service contact methods and a geographically-constrained context of > service delivery. These calls are intended to be delivered to special > call centers equipped to manage emergency response. Successful > delivery of an emergency service call within those systems requires > both an association of the physical location of the originator with an > appropriate emergency service center and call routing to deliver the > call to the center. > > Calls placed using Internet technologies do not use the same systems > to achieve those goals, and the common use of overlay networks and > tunnels (either as VPNs or for mobility) makes meeting them more > challenging. There are, however, Internet technologies available to > describe location and to manage call routing. This working group will > describe when these may be appropriate and how they may be used. This > group is considering emergency services calls which might be made by > any user of the Internet, as opposed to government or military > services that may impose very different authentication and routing > requirements. > > While this group anticipates a close working relationship with groups > such as NENA and ETSI EMTEL, any solution presented must be useful > regardless of jurisdiction, and it must be possible to use without a > single, central authority. Further, it must be possible for multiple > delegations within a jurisdiction to be handled independently, as call > routing for specific emergency types may be independent. > > The group will work on the maintainance of the > Location-to-Service Translation (LoST) protocol, on (emergency services > and non-emergency services related)extensions to LoST to the as well as > on necessary extension related to emergency call routing. > > This working group cares about privacy and security concerns, and will > address them within its documents. > > Goals and Milestones: > > Done An Informational RFC containing terminology definitions > and the requirements > Done An Informational document describing the threats and > security considerations > Done A Standards Track RFC describing how to identify a > session set-up request is to an emergency response center > Done A Standards Track RFC describing how to route an > emergency call based on location information > Done An Informational document describing the Mapping > Protocol Architecture > Dec 2008 An Informational document describing the ECRIT Framework > Dec 2008 A BCP document describing the emergency call support for > devices > Oct 2008 An Informational document providing a problem statement > and requirements for location hiding > Oct 2008 An Informational document specifying how to express > holes in LoST service boundaries > Dec 2008 An Informational document describing how to synchronize > LoST servers > Jan 2009 A Standards Track RFC registering a SIP Resource > Priority Header Namespace for Local Emergency Communications > Feb 2009 An Informational document describing how imprecise > location is used for emergency context resolution > Feb 2009 A Standards Track RFC containing Location-to-Service > Translation Protocol (LoST) Extensions > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > ------=_Part_580_21210554.1225114782713 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think there are a few milestones missing from this charter:

-- A Standards-Track document describing how SIP messages related to
emergency calling are distinguished from other
messages(draft-patel-ecrit-sos-parameter)
3GPP have made it pretty clear (both on this list and last week at the
emergency services workshop) that this mechanism or something like it is a
requirement for their emergency calling system.

-- An Informational document describing requirements for emergency calling
by unregistered or unauthenticated devices.
(draft-schulzrinne-ecrit-unauthenticated access)
This is an issue that ECRIT has avoided for a long time, as other SDOs have
been developing mechanisms.  It would be useful to have an Internet-level
analysis to unify these lower-level approaches and guide their development.

-- An Informational document describing best practices for emergency
calling from autonomous devices (vs. human callers)
(draft-rosen-ecrit-ecall)
Lots of different organizations (e.g., EU eCall and OGC's sensor web) are
interested in having sensors or other devices place emergency calls.  These
efforts could be more interoperable and better aligned with the ECRIT
architecture if it were made explicit which subset of the ECRIT framework
these systems should use.

Cheers,
--Richard



On Tue, Oct 14, 2008 at 10:13 AM, Tschofenig, Hannes (NSN - FI/Espoo) <hannes.tschofenig@nsn.com> wrote:
Here is a first proposal for the ECRIT WG rechartering based on the
discussions we had around IETF#72.
For the moment, I have put 3 additional documents onto the charter:
http://tools.ietf.org/id/draft-polk-ecrit-local-emergency-rph-namespace-
03.txt
http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc-00.txt
http://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00.txt

Regarding the following two documents
http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.txt
http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-00.txt
I am waiting for additional feedback from the draft authors on how they
perceive these documents should be progressed through the IETF, see my
mail here:
http://www.ietf.org/mail-archive/web/ecrit/current/msg05518.html

Please take a look at it and give me feedback till the 21st October
2008.

------------------------------------------------------------------------
---------------------------

Emergency Context Resolution with Internet Technologies (ecrit)

Description of Working Group:

In a number of areas, the public switched telephone network (PSTN) has
been configured to recognize an explicitly specified number (commonly
one that is short and easily memorized) as a call for emergency
services.  These numbers (e.g. 911, 112) relate to an emergency
service context and depend on a broad, regional configuration of
service contact methods and a geographically-constrained context of
service delivery.  These calls are intended to be delivered to special
call centers equipped to manage emergency response. Successful
delivery of an emergency service call within those systems requires
both an association of the physical location of the originator with an
appropriate emergency service center and call routing to deliver the
call to the center.

Calls placed using Internet technologies do not use the same systems
to achieve those goals, and the common use of overlay networks and
tunnels (either as VPNs or for mobility) makes meeting them more
challenging.  There are, however, Internet technologies available to
describe location and to manage call routing.  This working group will
describe when these may be appropriate and how they may be used. This
group is considering emergency services calls which might be made by
any user of the Internet, as opposed to government or military
services that may impose very different authentication and routing
requirements.

While this group anticipates a close working relationship with groups
such as NENA and ETSI EMTEL, any solution presented must be useful
regardless of jurisdiction, and it must be possible to use without a
single, central authority.  Further, it must be possible for multiple
delegations within a jurisdiction to be handled independently, as call
routing for specific emergency types may be independent.

The group will work on the maintainance of the
Location-to-Service Translation (LoST) protocol, on (emergency services
and non-emergency services related)extensions to LoST to the as well as
on necessary extension related to emergency call routing.

This working group cares about privacy and security concerns, and will
address them within its documents.

Goals and Milestones:

Done            An Informational RFC containing terminology definitions
and the requirements
Done            An Informational document describing the threats and
security considerations
Done            A Standards Track RFC describing how to identify a
session set-up request is to an emergency response center
Done            A Standards Track RFC describing how to route an
emergency call based on location information
Done            An Informational document describing the Mapping
Protocol Architecture
Dec 2008        An Informational document describing the ECRIT Framework
Dec 2008        A BCP document describing the emergency call support for
devices
Oct 2008        An Informational document providing a problem statement
and requirements for location hiding
Oct 2008        An Informational document specifying how to express
holes in LoST service boundaries
Dec 2008        An Informational document describing how to synchronize
LoST servers
Jan 2009        A Standards Track RFC registering a SIP Resource
Priority Header Namespace for Local Emergency Communications
Feb 2009        An Informational document describing how imprecise
location is used for emergency context resolution
Feb 2009        A Standards Track RFC containing Location-to-Service
Translation Protocol (LoST) Extensions
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

------=_Part_580_21210554.1225114782713-- --===============0760795021== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============0760795021==-- From ecrit-bounces@ietf.org Mon Oct 27 11:02:11 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585B13A6BA5; Mon, 27 Oct 2008 11:02:11 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C843A6B8A for ; Mon, 27 Oct 2008 11:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yBV8bReD9oB for ; Mon, 27 Oct 2008 11:02:09 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 956443A6BB2 for ; Mon, 27 Oct 2008 11:02:07 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Mon, 27 Oct 2008 11:02:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Oct 2008 11:00:27 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750B199F92@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <019801c9256a$cd661430$68323c90$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] thread-index: AcklXM0v3DWcQkerSz+0dKuGXD4ZiQAACaKAAALu2NAEvKLFUA== References: <385b0c950810030631m10a6e47ehd07dc417700fa528@mail.gmail.com><0913B6CD18F370498CD65864CF254E9006BFCF94@zharhxm1.corp.nortel.com> <019801c9256a$cd661430$68323c90$@net> From: "Roger Marshall" To: "ECRIT" Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org My understanding, based on Milan's 3GPP status at last week's 5th Emergency Services Workshop, is that 3GPP is open to adopting some IETF solution for call marking, so far has none, and that the window to finalize solutions for their the requirements is closing. It seemed that the message at the workshop was that 3GPP will either use an IETF mechanism - or create one of their own. I think that Brian has captured 4 topics that this draft (and list discussion) is targeting: 1. Marking emergency call registration 2. Keeping the Route header containing an SOS URN to the end 3. Tagging the UA as an emergency call 4. Marking a call back for specific call treatment Regardless of whether all of these issues are adequately handled in this early draft (likely not yet), what does seem to be clear is that 3GPP has additional requirements not currently met by the existing marking mechanism. I would like to see this draft be turned into a working group item. After that, we can work out the exact approach. I would encourage others to weigh in on making this a wg item. -roger marshall. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Friday, October 03, 2008 8:15 AM > To: 'Milan Patel'; 'John-Luc Bakker'; 'ECRIT' > Subject: Re: [Ecrit] [Fwd: I-D > Action:draft-patel-ecrit-sos-parameter-00.txt] > > I am still opposed to this mechanism. > > There seems to be four threads here: > 1. Marking an emergency registration > 2. Keeping the Route header with the sos urn on the call as > far as it needs to go 3. Making the UA aware of an emergency > call when it didn't recognize that itself 4. Marking a call back > > I recognize a need to mark an emergency registration. As > before, I'm not convinced this is the best solution, but > there is a problem that needs to be solved. > > I see no reason why the Route header with the sos urn does > not get put on the call as soon as it is recognized, and > remain on the call until it gets to the last SIP hop (a > gateway in the case that is being discussed, a PSAP if the > call is terminated in PS). Leave the Route header on, and > use that as the marking. > > The UA should recognize the emergency call. If you are > planning a system where you know it won't, fix that. Having > a backup mechanism is okay. The way to alert the UA is to > redirect the call to urn:service:sos. Then the UA knows it's > an emergency call. > > Call backs have not yet really been addressed well, but > "recognize the domain" works. It works for everyone: it > works for the gateway, it works for a proxy, it works for the > UA if the UA knows it was an emergency call. > I will say that I would prefer a more specific marking for a > call back. I'd prefer to have a comprehensive discussion of > call backs and make sure we have all the parts dealt with. I > will say this: there are two kinds of call backs. One is > immediate, when a call is lost, or while the call is being > handled more information is needed. The address used for > that is the Contact, not the AoR. The latter is a follow up > call placed later, and does use AoR (or P-A-I). The former > needs marking, the latter doesn't. It may be that we make > that the URI in Contact is distinguished in some way that > lets us know that this is a call back of an emergency call. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Milan Patel > Sent: Friday, October 03, 2008 9:45 AM > To: John-Luc Bakker; ECRIT > Subject: Re: [Ecrit] [Fwd: I-D > Action:draft-patel-ecrit-sos-parameter-00.txt] > > Hi John-Luc, > > Currently the draft only specifies that the "sos" parameter > only conveys information that the request/response is related > to an emergency session. But I do find your use case valid. > I'd like to know what others think, but can propose the > extension in version-01 if there is wider support. > > Best regards, > Milan > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of John-Luc Bakker > Sent: 03 October 2008 14:32 > To: ECRIT > Subject: Re: [Ecrit] [Fwd: I-D > Action:draft-patel-ecrit-sos-parameter-00.txt] > > Milan, > > The proposed new URI parameter is opaque. It marks the call > as an emergency call but fails to convey the emergency call > type even if an emergency call type could be deduced from the > original request. > Particularly if the Emergency Service URN in the Request-URI > is replaced by a network entity, as you suggest, not loosing > the emergency call type information seems useful. In some > deployments, emergency calls are routed to PSAPs that support > the requested emergency types. > > Kind regards, > > John-Luc > > On Mon, Sep 15, 2008 at 3:24 AM, Hannes Tschofenig > wrote: > > Please take a look at this document. Milan would like to hear some > comments! > > > > Ciao > > Hannes > > > > -------- Original Message -------- > > Subject: I-D Action:draft-patel-ecrit-sos-parameter-00.txt > > Date: Fri, 12 Sep 2008 09:45:01 -0700 (PDT) > > From: Internet-Drafts@ietf.org > > Reply-To: internet-drafts@ietf.org > > To: i-d-announce@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : SOS Uniform Resource Identifier (URI) > parameter for marking of Session Initiation Protocol (SIP) > requests related to emergency services > > Author(s) : M. Patel > > Filename : draft-patel-ecrit-sos-parameter-00.txt > > Pages : 9 > > Date : 2008-09-12 > > > > This memo describes requirements and protocol conventions for a new > > SIP (Session Initiation Protocol) URI parameter intended > for marking > > SIP requests and responses related to emergency services. This > > proposal addresses issues that exist in the current 3rd Generation > > Partnership Project IP Multimedia Subsystem (IMS) Emergency > services > > solution, but is not precluded from being used by other SIP-based > > emergency services solutions. It is not intended as a > replacement for > > the service URN. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-para > meter-00.t > xt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > _______________________________________________ > > 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 > _______________________________________________ > 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 > 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 From ecrit-bounces@ietf.org Mon Oct 27 11:24:29 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481C928C1EE; Mon, 27 Oct 2008 11:24:29 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CBB428C1EC for ; Mon, 27 Oct 2008 11:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Rtfb9n-0Jpl for ; Mon, 27 Oct 2008 11:24:25 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id CE45328C220 for ; Mon, 27 Oct 2008 11:23:06 -0700 (PDT) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m9RIN2M06915; Mon, 27 Oct 2008 18:23:02 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Oct 2008 18:22:58 -0000 Message-ID: <0913B6CD18F370498CD65864CF254E90071648FD@zharhxm1.corp.nortel.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B199F92@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] Thread-Index: AcklXM0v3DWcQkerSz+0dKuGXD4ZiQAACaKAAALu2NAEvKLFUAABGiTg References: <385b0c950810030631m10a6e47ehd07dc417700fa528@mail.gmail.com><0913B6CD18F370498CD65864CF254E9006BFCF94@zharhxm1.corp.nortel.com><019801c9256a$cd661430$68323c90$@net> <8C837214C95C864C9F34F3635C2A65750B199F92@SEA-EXCHVS-2.telecomsys.com> From: "Milan Patel" To: "Roger Marshall" , "ECRIT" Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thanks for the support Roger. Indeed, I failed to express the urgency of 3GPP to have a solution defined before the end of the year. I believe if we keep the proposed parameter simple as described by Deborah, progress can be achieved more quickly. I have had offline discussions with Brian on his previous comments and he has suggested some alternative methods of solving the four topics of the draft. These may be proposed as an alternative solution for the forthcoming 3GPP meetings. I will upload a -01 version of the draft based upon the current status of 3GPP requirements but in the mean time appreciate the comments received. Regards, Milan -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: 27 October 2008 18:00 To: ECRIT Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] My understanding, based on Milan's 3GPP status at last week's 5th Emergency Services Workshop, is that 3GPP is open to adopting some IETF solution for call marking, so far has none, and that the window to finalize solutions for their the requirements is closing. It seemed that the message at the workshop was that 3GPP will either use an IETF mechanism - or create one of their own. I think that Brian has captured 4 topics that this draft (and list discussion) is targeting: 1. Marking emergency call registration 2. Keeping the Route header containing an SOS URN to the end 3. Tagging the UA as an emergency call 4. Marking a call back for specific call treatment Regardless of whether all of these issues are adequately handled in this early draft (likely not yet), what does seem to be clear is that 3GPP has additional requirements not currently met by the existing marking mechanism. I would like to see this draft be turned into a working group item. After that, we can work out the exact approach. I would encourage others to weigh in on making this a wg item. -roger marshall. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Friday, October 03, 2008 8:15 AM > To: 'Milan Patel'; 'John-Luc Bakker'; 'ECRIT' > Subject: Re: [Ecrit] [Fwd: I-D > Action:draft-patel-ecrit-sos-parameter-00.txt] > > I am still opposed to this mechanism. > > There seems to be four threads here: > 1. Marking an emergency registration > 2. Keeping the Route header with the sos urn on the call as far as it > needs to go 3. Making the UA aware of an emergency call when it didn't > recognize that itself 4. Marking a call back > > I recognize a need to mark an emergency registration. As before, I'm > not convinced this is the best solution, but there is a problem that > needs to be solved. > > I see no reason why the Route header with the sos urn does not get put > on the call as soon as it is recognized, and remain on the call until > it gets to the last SIP hop (a gateway in the case that is being > discussed, a PSAP if the call is terminated in PS). Leave the Route > header on, and use that as the marking. > > The UA should recognize the emergency call. If you are planning a > system where you know it won't, fix that. Having a backup mechanism > is okay. The way to alert the UA is to redirect the call to > urn:service:sos. Then the UA knows it's an emergency call. > > Call backs have not yet really been addressed well, but "recognize the > domain" works. It works for everyone: it works for the gateway, it > works for a proxy, it works for the UA if the UA knows it was an > emergency call. > I will say that I would prefer a more specific marking for a call > back. I'd prefer to have a comprehensive discussion of call backs and > make sure we have all the parts dealt with. I will say this: there > are two kinds of call backs. One is immediate, when a call is lost, > or while the call is being handled more information is needed. The > address used for that is the Contact, not the AoR. The latter is a > follow up call placed later, and does use AoR (or P-A-I). The former > needs marking, the latter doesn't. It may be that we make that the > URI in Contact is distinguished in some way that lets us know that > this is a call back of an emergency call. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Milan Patel > Sent: Friday, October 03, 2008 9:45 AM > To: John-Luc Bakker; ECRIT > Subject: Re: [Ecrit] [Fwd: I-D > Action:draft-patel-ecrit-sos-parameter-00.txt] > > Hi John-Luc, > > Currently the draft only specifies that the "sos" parameter only > conveys information that the request/response is related to an > emergency session. But I do find your use case valid. > I'd like to know what others think, but can propose the extension in > version-01 if there is wider support. > > Best regards, > Milan > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of John-Luc Bakker > Sent: 03 October 2008 14:32 > To: ECRIT > Subject: Re: [Ecrit] [Fwd: I-D > Action:draft-patel-ecrit-sos-parameter-00.txt] > > Milan, > > The proposed new URI parameter is opaque. It marks the call as an > emergency call but fails to convey the emergency call type even if an > emergency call type could be deduced from the original request. > Particularly if the Emergency Service URN in the Request-URI is > replaced by a network entity, as you suggest, not loosing the > emergency call type information seems useful. In some deployments, > emergency calls are routed to PSAPs that support the requested > emergency types. > > Kind regards, > > John-Luc > > On Mon, Sep 15, 2008 at 3:24 AM, Hannes Tschofenig > wrote: > > Please take a look at this document. Milan would like to hear some > comments! > > > > Ciao > > Hannes > > > > -------- Original Message -------- > > Subject: I-D Action:draft-patel-ecrit-sos-parameter-00.txt > > Date: Fri, 12 Sep 2008 09:45:01 -0700 (PDT) > > From: Internet-Drafts@ietf.org > > Reply-To: internet-drafts@ietf.org > > To: i-d-announce@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : SOS Uniform Resource Identifier (URI) > parameter for marking of Session Initiation Protocol (SIP) requests > related to emergency services > > Author(s) : M. Patel > > Filename : draft-patel-ecrit-sos-parameter-00.txt > > Pages : 9 > > Date : 2008-09-12 > > > > This memo describes requirements and protocol conventions for a new > > SIP (Session Initiation Protocol) URI parameter intended > for marking > > SIP requests and responses related to emergency services. This > > proposal addresses issues that exist in the current 3rd Generation > > Partnership Project IP Multimedia Subsystem (IMS) Emergency > services > > solution, but is not precluded from being used by other SIP-based > > emergency services solutions. It is not intended as a > replacement for > > the service URN. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-para > meter-00.t > xt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > _______________________________________________ > > 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 > _______________________________________________ > 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 > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 27 11:36:07 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7BC23A6B7A; Mon, 27 Oct 2008 11:36:07 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4183A6A0D for ; Mon, 27 Oct 2008 11:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6aPY0ESOEj1 for ; Mon, 27 Oct 2008 11:36:02 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 994B33A6B7A for ; Mon, 27 Oct 2008 11:36:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,493,1220227200"; d="scan'208";a="25793304" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Oct 2008 18:36:01 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9RIa1Gn003908; Mon, 27 Oct 2008 14:36:01 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9RIa1bo010484; Mon, 27 Oct 2008 18:36:01 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 14:36:01 -0400 Received: from jmpolk-wxp01.cisco.com ([10.82.254.148]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 14:36:01 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Oct 2008 13:35:59 -0500 To: "Richard Barnes" , "Tschofenig, Hannes (NSN - FI/Espoo)" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 27 Oct 2008 18:36:01.0182 (UTC) FILETIME=[DC5D43E0:01C93862] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7011; t=1225132561; x=1225996561; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20ECRIT=20WG=20Rechartering |Sender:=20 |To:=20=22Richard=20Barnes=22=20,=0A=20=20=20=20=20=20=20=20=22Tschofenig,=20Hannes=20(N SN=20-=20FI/Espoo)=22=20; bh=TfiXMKuuFZbNRhjtChr44nTnxPEGZhk+ZQIlcsuhBXc=; b=t/VDgvsNbF2dbcj+nlaek/9p1R77PQS8WKnHJySMBDpd/AUDfdW1MxEPQV 522onDAIAmVvGw6u4ZwEVmr+OcDKU1WZMM5SoNdTfwWk74abWbTGe6BYWucg gPO+O31pQ8; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: ECRIT Subject: Re: [Ecrit] ECRIT WG Rechartering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 08:39 AM 10/27/2008, Richard Barnes wrote: >I think there are a few milestones missing from this charter: I think, but could be wrong, that only one of these IDs (Henning's) has been presented to the WG. That usually limits their ability to be a WG item yet. >-- A Standards-Track document describing how SIP messages related to >emergency calling are distinguished from other >messages(draft-patel-ecrit-sos-parameter) >3GPP have made it pretty clear (both on this list and last week at the >emergency services workshop) that this mechanism or something like it is a >requirement for their emergency calling system. > >-- An Informational document describing requirements for emergency calling >by unregistered or unauthenticated devices. >(draft-schulzrinne-ecrit-unauthenticated access) >This is an issue that ECRIT has avoided for a long time, as other SDOs have >been developing mechanisms. It would be useful to have an Internet-level >analysis to unify these lower-level approaches and guide their development. > >-- An Informational document describing best practices for emergency >calling from autonomous devices (vs. human callers) >(draft-rosen-ecrit-ecall) >Lots of different organizations (e.g., EU eCall and OGC's sensor web) are >interested in having sensors or other devices place emergency calls. These >efforts could be more interoperable and better aligned with the ECRIT >architecture if it were made explicit which subset of the ECRIT framework >these systems should use. > >Cheers, >--Richard > > > >On Tue, Oct 14, 2008 at 10:13 AM, Tschofenig, Hannes (NSN - >FI/Espoo) <hannes.tschofenig@nsn.com> wrote: >Here is a first proposal for the ECRIT WG rechartering based on the >discussions we had around IETF#72. >For the moment, I have put 3 additional documents onto the charter: >http://tools.ietf.org/id/draft-polk-ecrit-local-emergency-rph-namespace- >03.txt >http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc-00.txt >http://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00.txt > >Regarding the following two documents >http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.txt >http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-00.txt >I am waiting for additional feedback from the draft authors on how they >perceive these documents should be progressed through the IETF, see my >mail here: >http://www.ietf.org/mail-archive/web/ecrit/current/msg05518.html > >Please take a look at it and give me feedback till the 21st October >2008. > >------------------------------------------------------------------------ >--------------------------- > >Emergency Context Resolution with Internet Technologies (ecrit) > >Description of Working Group: > >In a number of areas, the public switched telephone network (PSTN) has >been configured to recognize an explicitly specified number (commonly >one that is short and easily memorized) as a call for emergency >services. These numbers (e.g. 911, 112) relate to an emergency >service context and depend on a broad, regional configuration of >service contact methods and a geographically-constrained context of >service delivery. These calls are intended to be delivered to special >call centers equipped to manage emergency response. Successful >delivery of an emergency service call within those systems requires >both an association of the physical location of the originator with an >appropriate emergency service center and call routing to deliver the >call to the center. > >Calls placed using Internet technologies do not use the same systems >to achieve those goals, and the common use of overlay networks and >tunnels (either as VPNs or for mobility) makes meeting them more >challenging. There are, however, Internet technologies available to >describe location and to manage call routing. This working group will >describe when these may be appropriate and how they may be used. This >group is considering emergency services calls which might be made by >any user of the Internet, as opposed to government or military >services that may impose very different authentication and routing >requirements. > >While this group anticipates a close working relationship with groups >such as NENA and ETSI EMTEL, any solution presented must be useful >regardless of jurisdiction, and it must be possible to use without a >single, central authority. Further, it must be possible for multiple >delegations within a jurisdiction to be handled independently, as call >routing for specific emergency types may be independent. > >The group will work on the maintainance of the >Location-to-Service Translation (LoST) protocol, on (emergency services >and non-emergency services related)extensions to LoST to the as well as >on necessary extension related to emergency call routing. > >This working group cares about privacy and security concerns, and will >address them within its documents. > >Goals and Milestones: > >Done An Informational RFC containing terminology definitions >and the requirements >Done An Informational document describing the threats and >security considerations >Done A Standards Track RFC describing how to identify a >session set-up request is to an emergency response center >Done A Standards Track RFC describing how to route an >emergency call based on location information >Done An Informational document describing the Mapping >Protocol Architecture >Dec 2008 An Informational document describing the ECRIT Framework >Dec 2008 A BCP document describing the emergency call support for >devices >Oct 2008 An Informational document providing a problem statement >and requirements for location hiding >Oct 2008 An Informational document specifying how to express >holes in LoST service boundaries >Dec 2008 An Informational document describing how to synchronize >LoST servers >Jan 2009 A Standards Track RFC registering a SIP Resource >Priority Header Namespace for Local Emergency Communications >Feb 2009 An Informational document describing how imprecise >location is used for emergency context resolution >Feb 2009 A Standards Track RFC containing Location-to-Service >Translation Protocol (LoST) Extensions >_______________________________________________ >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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 27 11:38:58 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 415AB3A6B8F; Mon, 27 Oct 2008 11:38:58 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0353D3A6B88 for ; Mon, 27 Oct 2008 11:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.315 X-Spam-Level: X-Spam-Status: No, score=-4.315 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, MANGLED_EMRG=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kQCme3dPkTB for ; Mon, 27 Oct 2008 11:38:55 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 028F53A68D0 for ; Mon, 27 Oct 2008 11:38:54 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9RIcN3N018848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Oct 2008 19:38:23 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9RIcLhs005116; Mon, 27 Oct 2008 19:38:22 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 19:38:11 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 19:38:11 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 27 Oct 2008 20:38:02 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT WG Rechartering Thread-Index: Ack4Yt7/xf6mXN7zQXq8uLxQ03WhmAAAB+CA References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext James M. Polk" , "Richard Barnes" X-OriginalArrivalTime: 27 Oct 2008 18:38:11.0476 (UTC) FILETIME=[2A068D40:01C93863] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081027193823-115F1BB0-D271D624/0-0/0-15 X-purgate-size: 7954/0 Cc: ECRIT Subject: Re: [Ecrit] ECRIT WG Rechartering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org We in the group can make decisions at any time regardless of what was presented at the meeting. I believe we should speed up a bit with our work. I also hope that you and Brian are going to update the PhoneBCP/Framework document so that we get that document out of our way >-----Original Message----- >From: ext James M. Polk [mailto:jmpolk@cisco.com] >Sent: 27 October, 2008 20:36 >To: Richard Barnes; Tschofenig, Hannes (NSN - FI/Espoo) >Cc: ECRIT >Subject: Re: [Ecrit] ECRIT WG Rechartering > >At 08:39 AM 10/27/2008, Richard Barnes wrote: >>I think there are a few milestones missing from this charter: > >I think, but could be wrong, that only one of these IDs >(Henning's) has been presented to the WG. That usually limits >their ability to be a WG item yet. > > >>-- A Standards-Track document describing how SIP messages related to >>emergency calling are distinguished from other >>messages(draft-patel-ecrit-sos-parameter) >>3GPP have made it pretty clear (both on this list and last >week at the >>emergency services workshop) that this mechanism or something like it >>is a requirement for their emergency calling system. >> >>-- An Informational document describing requirements for emergency >>calling by unregistered or unauthenticated devices. >>(draft-schulzrinne-ecrit-unauthenticated access) This is an >issue that >>ECRIT has avoided for a long time, as other SDOs have been developing >>mechanisms. It would be useful to have an Internet-level analysis to >>unify these lower-level approaches and guide their development. >> >>-- An Informational document describing best practices for emergency >>calling from autonomous devices (vs. human callers) >>(draft-rosen-ecrit-ecall) >>Lots of different organizations (e.g., EU eCall and OGC's sensor web) >>are interested in having sensors or other devices place emergency >>calls. These efforts could be more interoperable and better aligned >>with the ECRIT architecture if it were made explicit which subset of >>the ECRIT framework these systems should use. >> >>Cheers, >>--Richard >> >> >> >>On Tue, Oct 14, 2008 at 10:13 AM, Tschofenig, Hannes (NSN - >>FI/Espoo) ><hannes.tschofenig@nsn.com> wrote: >>Here is a first proposal for the ECRIT WG rechartering based on the >>discussions we had around IETF#72. >>For the moment, I have put 3 additional documents onto the charter: >>-namespac >>e-03.txt>http://tools.ietf.org/id/draft-polk-ecrit-local-emerg >ency-rph- >>namespace- >>03.txt >>http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc-00.txt >>.txt>http >>://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00.txt >> >>Regarding the following two documents >>tion-00.t >>xt>http://tools.ietf.org/id/draft-forte-ecrit-service-classifi >cation-00 >>.txt http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-00.txt >>I am waiting for additional feedback from the draft authors >on how they >>perceive these documents should be progressed through the >IETF, see my >>mail here: >>tml>http: >>//www.ietf.org/mail-archive/web/ecrit/current/msg05518.html >> >>Please take a look at it and give me feedback till the 21st October >>2008. >> >>-------------------------------------------------------------- >--------- >>- >>--------------------------- >> >>Emergency Context Resolution with Internet Technologies (ecrit) >> >>Description of Working Group: >> >>In a number of areas, the public switched telephone network >(PSTN) has >>been configured to recognize an explicitly specified number (commonly >>one that is short and easily memorized) as a call for emergency >>services. These numbers (e.g. 911, 112) relate to an >emergency service >>context and depend on a broad, regional configuration of service >>contact methods and a geographically-constrained context of service >>delivery. These calls are intended to be delivered to special call >>centers equipped to manage emergency response. Successful delivery of >>an emergency service call within those systems requires both an >>association of the physical location of the originator with an >>appropriate emergency service center and call routing to deliver the >>call to the center. >> >>Calls placed using Internet technologies do not use the same >systems to >>achieve those goals, and the common use of overlay networks >and tunnels >>(either as VPNs or for mobility) makes meeting them more >challenging. >>There are, however, Internet technologies available to describe >>location and to manage call routing. This working group will >describe >>when these may be appropriate and how they may be used. This group is >>considering emergency services calls which might be made by >any user of >>the Internet, as opposed to government or military services that may >>impose very different authentication and routing requirements. >> >>While this group anticipates a close working relationship with groups >>such as NENA and ETSI EMTEL, any solution presented must be useful >>regardless of jurisdiction, and it must be possible to use without a >>single, central authority. Further, it must be possible for multiple >>delegations within a jurisdiction to be handled >independently, as call >>routing for specific emergency types may be independent. >> >>The group will work on the maintainance of the Location-to-Service >>Translation (LoST) protocol, on (emergency services and non-emergency >>services related)extensions to LoST to the as well as on necessary >>extension related to emergency call routing. >> >>This working group cares about privacy and security concerns, >and will >>address them within its documents. >> >>Goals and Milestones: >> >>Done An Informational RFC containing terminology >definitions >>and the requirements >>Done An Informational document describing the threats and >>security considerations >>Done A Standards Track RFC describing how to identify a >>session set-up request is to an emergency response center >>Done A Standards Track RFC describing how to route an >>emergency call based on location information >>Done An Informational document describing the Mapping >>Protocol Architecture >>Dec 2008 An Informational document describing the >ECRIT Framework >>Dec 2008 A BCP document describing the emergency call >support for >>devices >>Oct 2008 An Informational document providing a problem >statement >>and requirements for location hiding >>Oct 2008 An Informational document specifying how to express >>holes in LoST service boundaries >>Dec 2008 An Informational document describing how to >synchronize >>LoST servers >>Jan 2009 A Standards Track RFC registering a SIP Resource >>Priority Header Namespace for Local Emergency Communications >>Feb 2009 An Informational document describing how imprecise >>location is used for emergency context resolution >>Feb 2009 A Standards Track RFC containing Location-to-Service >>Translation Protocol (LoST) Extensions >>_______________________________________________ >>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 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 27 12:23:13 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB4F3A6BB7; Mon, 27 Oct 2008 12:23:13 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4204F3A6BC1 for ; Mon, 27 Oct 2008 12:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmi6N47Gw9AQ for ; Mon, 27 Oct 2008 12:23:10 -0700 (PDT) Received: from mail-gx0-f18.google.com (mail-gx0-f18.google.com [209.85.217.18]) by core3.amsl.com (Postfix) with ESMTP id 9294B3A6BB0 for ; Mon, 27 Oct 2008 12:23:10 -0700 (PDT) Received: by gxk11 with SMTP id 11so570029gxk.13 for ; Mon, 27 Oct 2008 12:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=rWroAtuEnAdjge+mPks4NyhlJkIMEpG7RfASpimTvfw=; b=q5UEbC5npuqu8jLewSsIvulOPVoqg2YSL34EXAHlledZnmRSsJSjKb0JolXqyJWD7G rAzHCuYl7r3kqCZ9m2MFsaXu0EIk1mGxM3jjejCLK/a9v1wyyN4R6KeNiHl/kFOYCkmR foaBFyLcTkLAsIHlbs1RQ0LD2z5OotfLneze8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=I7roy96WsqLGwTjMTEjyFL59L6cVeJajgXLRKm+SdB7zkmBJOrH298KutVUWyFHxdb 81/oWdNS2xcM6FBio6cQda4t8U23LYWFEgK4uOBigxao5N9uNIx1DxeomDqLqX7KwmYH mfxuwlxOTHS1qX1ygndEgJDxYhr47VMWdkMww= Received: by 10.150.52.2 with SMTP id z2mr12706996ybz.210.1225135389744; Mon, 27 Oct 2008 12:23:09 -0700 (PDT) Received: by 10.150.218.15 with HTTP; Mon, 27 Oct 2008 12:23:09 -0700 (PDT) Message-ID: <385b0c950810271223j70fc5fb4l76c0801c615587e8@mail.gmail.com> Date: Mon, 27 Oct 2008 14:23:09 -0500 From: "John-Luc Bakker" To: "Milan Patel" In-Reply-To: <0913B6CD18F370498CD65864CF254E90071648FD@zharhxm1.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline References: <385b0c950810030631m10a6e47ehd07dc417700fa528@mail.gmail.com> <0913B6CD18F370498CD65864CF254E9006BFCF94@zharhxm1.corp.nortel.com> <019801c9256a$cd661430$68323c90$@net> <8C837214C95C864C9F34F3635C2A65750B199F92@SEA-EXCHVS-2.telecomsys.com> <0913B6CD18F370498CD65864CF254E90071648FD@zharhxm1.corp.nortel.com> Cc: ECRIT Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Milan, I fail to see how the opaque parameter's description would expedite matters more when compared to a description that includes type of service information. I fail to see how excluding the type of service information would impede expedience. I would very much like to see you include a few lines on type of service information given the usefullness expressed, lack of additional complexity, and lack of decreased efficiency. Regards, John-Luc On Mon, Oct 27, 2008 at 1:22 PM, Milan Patel wrote: > Thanks for the support Roger. > Indeed, I failed to express the urgency of 3GPP to have a solution > defined before the end of the year. I believe if we keep the proposed > parameter simple as described by Deborah, progress can be achieved more > quickly. I have had offline discussions with Brian on his previous > comments and he has suggested some alternative methods of solving the > four topics of the draft. These may be proposed as an alternative > solution for the forthcoming 3GPP meetings. I will upload a -01 version > of the draft based upon the current status of 3GPP requirements but in > the mean time appreciate the comments received. > > Regards, > Milan > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Roger Marshall > Sent: 27 October 2008 18:00 > To: ECRIT > Subject: Re: [Ecrit] [Fwd: I-D > Action:draft-patel-ecrit-sos-parameter-00.txt] > > My understanding, based on Milan's 3GPP status at last week's 5th > Emergency Services Workshop, is that 3GPP is open to adopting some IETF > solution for call marking, so far has none, and that the window to > finalize solutions for their the requirements is closing. It seemed > that the message at the workshop was that 3GPP will either use an IETF > mechanism - or create one of their own. > > I think that Brian has captured 4 topics that this draft (and list > discussion) is targeting: > 1. Marking emergency call registration > 2. Keeping the Route header containing an SOS URN to the end 3. Tagging > the UA as an emergency call 4. Marking a call back for specific call > treatment > > Regardless of whether all of these issues are adequately handled in this > early draft (likely not yet), what does seem to be clear is that 3GPP > has additional requirements not currently met by the existing marking > mechanism. > > I would like to see this draft be turned into a working group item. > After that, we can work out the exact approach. I would encourage > others to weigh in on making this a wg item. > > -roger marshall. > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >> Of Brian Rosen >> Sent: Friday, October 03, 2008 8:15 AM >> To: 'Milan Patel'; 'John-Luc Bakker'; 'ECRIT' >> Subject: Re: [Ecrit] [Fwd: I-D >> Action:draft-patel-ecrit-sos-parameter-00.txt] >> >> I am still opposed to this mechanism. >> >> There seems to be four threads here: >> 1. Marking an emergency registration >> 2. Keeping the Route header with the sos urn on the call as far as it >> needs to go 3. Making the UA aware of an emergency call when it didn't > >> recognize that itself 4. Marking a call back >> >> I recognize a need to mark an emergency registration. As before, I'm >> not convinced this is the best solution, but there is a problem that >> needs to be solved. >> >> I see no reason why the Route header with the sos urn does not get put > >> on the call as soon as it is recognized, and remain on the call until >> it gets to the last SIP hop (a gateway in the case that is being >> discussed, a PSAP if the call is terminated in PS). Leave the Route >> header on, and use that as the marking. >> >> The UA should recognize the emergency call. If you are planning a >> system where you know it won't, fix that. Having a backup mechanism >> is okay. The way to alert the UA is to redirect the call to >> urn:service:sos. Then the UA knows it's an emergency call. >> >> Call backs have not yet really been addressed well, but "recognize the > >> domain" works. It works for everyone: it works for the gateway, it >> works for a proxy, it works for the UA if the UA knows it was an >> emergency call. >> I will say that I would prefer a more specific marking for a call >> back. I'd prefer to have a comprehensive discussion of call backs and > >> make sure we have all the parts dealt with. I will say this: there >> are two kinds of call backs. One is immediate, when a call is lost, >> or while the call is being handled more information is needed. The >> address used for that is the Contact, not the AoR. The latter is a >> follow up call placed later, and does use AoR (or P-A-I). The former >> needs marking, the latter doesn't. It may be that we make that the >> URI in Contact is distinguished in some way that lets us know that >> this is a call back of an emergency call. >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >> Of Milan Patel >> Sent: Friday, October 03, 2008 9:45 AM >> To: John-Luc Bakker; ECRIT >> Subject: Re: [Ecrit] [Fwd: I-D >> Action:draft-patel-ecrit-sos-parameter-00.txt] >> >> Hi John-Luc, >> >> Currently the draft only specifies that the "sos" parameter only >> conveys information that the request/response is related to an >> emergency session. But I do find your use case valid. >> I'd like to know what others think, but can propose the extension in >> version-01 if there is wider support. >> >> Best regards, >> Milan >> >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >> Of John-Luc Bakker >> Sent: 03 October 2008 14:32 >> To: ECRIT >> Subject: Re: [Ecrit] [Fwd: I-D >> Action:draft-patel-ecrit-sos-parameter-00.txt] >> >> Milan, >> >> The proposed new URI parameter is opaque. It marks the call as an >> emergency call but fails to convey the emergency call type even if an >> emergency call type could be deduced from the original request. >> Particularly if the Emergency Service URN in the Request-URI is >> replaced by a network entity, as you suggest, not loosing the >> emergency call type information seems useful. In some deployments, >> emergency calls are routed to PSAPs that support the requested >> emergency types. >> >> Kind regards, >> >> John-Luc >> >> On Mon, Sep 15, 2008 at 3:24 AM, Hannes Tschofenig >> wrote: >> > Please take a look at this document. Milan would like to hear some >> comments! >> > >> > Ciao >> > Hannes >> > >> > -------- Original Message -------- >> > Subject: I-D Action:draft-patel-ecrit-sos-parameter-00.txt >> > Date: Fri, 12 Sep 2008 09:45:01 -0700 (PDT) >> > From: Internet-Drafts@ietf.org >> > Reply-To: internet-drafts@ietf.org >> > To: i-d-announce@ietf.org >> > >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > >> > Title : SOS Uniform Resource Identifier (URI) >> parameter for marking of Session Initiation Protocol (SIP) requests >> related to emergency services >> > Author(s) : M. Patel >> > Filename : draft-patel-ecrit-sos-parameter-00.txt >> > Pages : 9 >> > Date : 2008-09-12 >> > >> > This memo describes requirements and protocol conventions for a new >> > SIP (Session Initiation Protocol) URI parameter intended >> for marking >> > SIP requests and responses related to emergency services. This >> > proposal addresses issues that exist in the current 3rd Generation >> > Partnership Project IP Multimedia Subsystem (IMS) Emergency >> services >> > solution, but is not precluded from being used by other SIP-based >> > emergency services solutions. It is not intended as a >> replacement for >> > the service URN. >> > >> > A URL for this Internet-Draft is: >> > >> http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-para >> meter-00.t >> xt >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > Below is the data which will enable a MIME compliant mail reader >> > implementation to automatically retrieve the ASCII version of the >> > Internet-Draft. >> > >> > >> > _______________________________________________ >> > 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 >> _______________________________________________ >> 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 >> > > 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 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 27 12:25:26 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47A843A67D4; Mon, 27 Oct 2008 12:25:26 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2639F3A6BB0 for ; Mon, 27 Oct 2008 12:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, MANGLED_EMRG=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MPo8LxtqSZv for ; Mon, 27 Oct 2008 12:25:19 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 2F8B43A6BB1 for ; Mon, 27 Oct 2008 12:25:13 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KuXi4-0006oI-8X; Mon, 27 Oct 2008 14:25:04 -0500 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext James M. Polk'" , "'Richard Barnes'" References: In-Reply-To: Date: Mon, 27 Oct 2008 15:25:01 -0400 Message-ID: <014501c93869$b741bcb0$25c53610$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack4Yt7/xf6mXN7zQXq8uLxQ03WhmAAAB+CAAAGiPAA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] ECRIT WG Rechartering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Another item that I think deserves some chartered work is PSAP call backs. There are a number of issues that have been raised about how call backs work, including marking, services that might be affected (for example, consider call forwarding), and any kind of priority mechanisms that might be applied. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Monday, October 27, 2008 2:38 PM To: ext James M. Polk; Richard Barnes Cc: ECRIT Subject: Re: [Ecrit] ECRIT WG Rechartering We in the group can make decisions at any time regardless of what was presented at the meeting. I believe we should speed up a bit with our work. I also hope that you and Brian are going to update the PhoneBCP/Framework document so that we get that document out of our way >-----Original Message----- >From: ext James M. Polk [mailto:jmpolk@cisco.com] >Sent: 27 October, 2008 20:36 >To: Richard Barnes; Tschofenig, Hannes (NSN - FI/Espoo) >Cc: ECRIT >Subject: Re: [Ecrit] ECRIT WG Rechartering > >At 08:39 AM 10/27/2008, Richard Barnes wrote: >>I think there are a few milestones missing from this charter: > >I think, but could be wrong, that only one of these IDs >(Henning's) has been presented to the WG. That usually limits >their ability to be a WG item yet. > > >>-- A Standards-Track document describing how SIP messages related to >>emergency calling are distinguished from other >>messages(draft-patel-ecrit-sos-parameter) >>3GPP have made it pretty clear (both on this list and last >week at the >>emergency services workshop) that this mechanism or something like it >>is a requirement for their emergency calling system. >> >>-- An Informational document describing requirements for emergency >>calling by unregistered or unauthenticated devices. >>(draft-schulzrinne-ecrit-unauthenticated access) This is an >issue that >>ECRIT has avoided for a long time, as other SDOs have been developing >>mechanisms. It would be useful to have an Internet-level analysis to >>unify these lower-level approaches and guide their development. >> >>-- An Informational document describing best practices for emergency >>calling from autonomous devices (vs. human callers) >>(draft-rosen-ecrit-ecall) >>Lots of different organizations (e.g., EU eCall and OGC's sensor web) >>are interested in having sensors or other devices place emergency >>calls. These efforts could be more interoperable and better aligned >>with the ECRIT architecture if it were made explicit which subset of >>the ECRIT framework these systems should use. >> >>Cheers, >>--Richard >> >> >> >>On Tue, Oct 14, 2008 at 10:13 AM, Tschofenig, Hannes (NSN - >>FI/Espoo) ><hannes.tschofenig@nsn.com> wrote: >>Here is a first proposal for the ECRIT WG rechartering based on the >>discussions we had around IETF#72. >>For the moment, I have put 3 additional documents onto the charter: >>-namespac >>e-03.txt>http://tools.ietf.org/id/draft-polk-ecrit-local-emerg >ency-rph- >>namespace- >>03.txt >>http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc-00.txt >>.txt>http >>://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00.txt >> >>Regarding the following two documents >>tion-00.t >>xt>http://tools.ietf.org/id/draft-forte-ecrit-service-classifi >cation-00 >>.txt http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-00.txt >>I am waiting for additional feedback from the draft authors >on how they >>perceive these documents should be progressed through the >IETF, see my >>mail here: >>tml>http: >>//www.ietf.org/mail-archive/web/ecrit/current/msg05518.html >> >>Please take a look at it and give me feedback till the 21st October >>2008. >> >>-------------------------------------------------------------- >--------- >>- >>--------------------------- >> >>Emergency Context Resolution with Internet Technologies (ecrit) >> >>Description of Working Group: >> >>In a number of areas, the public switched telephone network >(PSTN) has >>been configured to recognize an explicitly specified number (commonly >>one that is short and easily memorized) as a call for emergency >>services. These numbers (e.g. 911, 112) relate to an >emergency service >>context and depend on a broad, regional configuration of service >>contact methods and a geographically-constrained context of service >>delivery. These calls are intended to be delivered to special call >>centers equipped to manage emergency response. Successful delivery of >>an emergency service call within those systems requires both an >>association of the physical location of the originator with an >>appropriate emergency service center and call routing to deliver the >>call to the center. >> >>Calls placed using Internet technologies do not use the same >systems to >>achieve those goals, and the common use of overlay networks >and tunnels >>(either as VPNs or for mobility) makes meeting them more >challenging. >>There are, however, Internet technologies available to describe >>location and to manage call routing. This working group will >describe >>when these may be appropriate and how they may be used. This group is >>considering emergency services calls which might be made by >any user of >>the Internet, as opposed to government or military services that may >>impose very different authentication and routing requirements. >> >>While this group anticipates a close working relationship with groups >>such as NENA and ETSI EMTEL, any solution presented must be useful >>regardless of jurisdiction, and it must be possible to use without a >>single, central authority. Further, it must be possible for multiple >>delegations within a jurisdiction to be handled >independently, as call >>routing for specific emergency types may be independent. >> >>The group will work on the maintainance of the Location-to-Service >>Translation (LoST) protocol, on (emergency services and non-emergency >>services related)extensions to LoST to the as well as on necessary >>extension related to emergency call routing. >> >>This working group cares about privacy and security concerns, >and will >>address them within its documents. >> >>Goals and Milestones: >> >>Done An Informational RFC containing terminology >definitions >>and the requirements >>Done An Informational document describing the threats and >>security considerations >>Done A Standards Track RFC describing how to identify a >>session set-up request is to an emergency response center >>Done A Standards Track RFC describing how to route an >>emergency call based on location information >>Done An Informational document describing the Mapping >>Protocol Architecture >>Dec 2008 An Informational document describing the >ECRIT Framework >>Dec 2008 A BCP document describing the emergency call >support for >>devices >>Oct 2008 An Informational document providing a problem >statement >>and requirements for location hiding >>Oct 2008 An Informational document specifying how to express >>holes in LoST service boundaries >>Dec 2008 An Informational document describing how to >synchronize >>LoST servers >>Jan 2009 A Standards Track RFC registering a SIP Resource >>Priority Header Namespace for Local Emergency Communications >>Feb 2009 An Informational document describing how imprecise >>location is used for emergency context resolution >>Feb 2009 A Standards Track RFC containing Location-to-Service >>Translation Protocol (LoST) Extensions >>_______________________________________________ >>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 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 27 12:32:15 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98E33A6B4E; Mon, 27 Oct 2008 12:32:15 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DBF73A6AF9 for ; Mon, 27 Oct 2008 12:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.314 X-Spam-Level: X-Spam-Status: No, score=-4.314 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, MANGLED_EMRG=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9wl4ofdoFsc for ; Mon, 27 Oct 2008 12:32:13 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4D1243A6BB7 for ; Mon, 27 Oct 2008 12:31:02 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9RJUqoq024154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Oct 2008 20:30:52 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9RJUlF7013026; Mon, 27 Oct 2008 20:30:51 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 20:30:49 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 20:30:48 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 27 Oct 2008 21:29:57 +0200 Message-ID: In-Reply-To: <014501c93869$b741bcb0$25c53610$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT WG Rechartering Thread-Index: Ack4Yt7/xf6mXN7zQXq8uLxQ03WhmAAAB+CAAAGiPAAAACS10A== References: <014501c93869$b741bcb0$25c53610$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Brian Rosen" , "ext James M. Polk" , "Richard Barnes" X-OriginalArrivalTime: 27 Oct 2008 19:30:48.0844 (UTC) FILETIME=[83F6ACC0:01C9386A] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081027203052-115F1BB0-CA8DD6C7/0-0/0-15 X-purgate-size: 9396/0 Cc: ECRIT Subject: Re: [Ecrit] ECRIT WG Rechartering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Brian, my reading of Milan's document was that he wanted to work on a solution in that enables PSAP callbacks. See, for example, [REQ 4] at http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-00.txt Ciao Hannes >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net] >Sent: 27 October, 2008 21:25 >To: Tschofenig, Hannes (NSN - FI/Espoo); 'ext James M. Polk'; >'Richard Barnes' >Cc: 'ECRIT' >Subject: RE: [Ecrit] ECRIT WG Rechartering > >Another item that I think deserves some chartered work is PSAP >call backs. >There are a number of issues that have been raised about how >call backs work, including marking, services that might be >affected (for example, consider call forwarding), and any kind >of priority mechanisms that might be applied. > >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >Sent: Monday, October 27, 2008 2:38 PM >To: ext James M. Polk; Richard Barnes >Cc: ECRIT >Subject: Re: [Ecrit] ECRIT WG Rechartering > >We in the group can make decisions at any time regardless of >what was presented at the meeting. >I believe we should speed up a bit with our work. > >I also hope that you and Brian are going to update the >PhoneBCP/Framework document so that we get that document out >of our way > >>-----Original Message----- >>From: ext James M. Polk [mailto:jmpolk@cisco.com] >>Sent: 27 October, 2008 20:36 >>To: Richard Barnes; Tschofenig, Hannes (NSN - FI/Espoo) >>Cc: ECRIT >>Subject: Re: [Ecrit] ECRIT WG Rechartering >> >>At 08:39 AM 10/27/2008, Richard Barnes wrote: >>>I think there are a few milestones missing from this charter: >> >>I think, but could be wrong, that only one of these IDs >>(Henning's) has been presented to the WG. That usually limits their >>ability to be a WG item yet. >> >> >>>-- A Standards-Track document describing how SIP messages related to >>>emergency calling are distinguished from other >>>messages(draft-patel-ecrit-sos-parameter) >>>3GPP have made it pretty clear (both on this list and last >>week at the >>>emergency services workshop) that this mechanism or >something like it >>>is a requirement for their emergency calling system. >>> >>>-- An Informational document describing requirements for emergency >>>calling by unregistered or unauthenticated devices. >>>(draft-schulzrinne-ecrit-unauthenticated access) This is an >>issue that >>>ECRIT has avoided for a long time, as other SDOs have been >developing >>>mechanisms. It would be useful to have an Internet-level >analysis to >>>unify these lower-level approaches and guide their development. >>> >>>-- An Informational document describing best practices for emergency >>>calling from autonomous devices (vs. human callers) >>>(draft-rosen-ecrit-ecall) >>>Lots of different organizations (e.g., EU eCall and OGC's >sensor web) >>>are interested in having sensors or other devices place emergency >>>calls. These efforts could be more interoperable and better aligned >>>with the ECRIT architecture if it were made explicit which subset of >>>the ECRIT framework these systems should use. >>> >>>Cheers, >>>--Richard >>> >>> >>> >>>On Tue, Oct 14, 2008 at 10:13 AM, Tschofenig, Hannes (NSN - >>>FI/Espoo) >><hannes.tschofenig@nsn.com> wrote: >>>Here is a first proposal for the ECRIT WG rechartering based on the >>>discussions we had around IETF#72. >>>For the moment, I have put 3 additional documents onto the charter: >>>>-namespac >>>e-03.txt>http://tools.ietf.org/id/draft-polk-ecrit-local-emerg >>ency-rph- >>>namespace- >>>03.txt >>>http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc-00.txt >>>>.txt>http >>>://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00.txt >>> >>>Regarding the following two documents >>>>tion-00.t >>>xt>http://tools.ietf.org/id/draft-forte-ecrit-service-classifi >>cation-00 >>>.txt http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-00.txt >>>I am waiting for additional feedback from the draft authors >>on how they >>>perceive these documents should be progressed through the >>IETF, see my >>>mail here: >>>>tml>http: >>>//www.ietf.org/mail-archive/web/ecrit/current/msg05518.html >>> >>>Please take a look at it and give me feedback till the 21st October >>>2008. >>> >>>-------------------------------------------------------------- >>--------- >>>- >>>--------------------------- >>> >>>Emergency Context Resolution with Internet Technologies (ecrit) >>> >>>Description of Working Group: >>> >>>In a number of areas, the public switched telephone network >>(PSTN) has >>>been configured to recognize an explicitly specified number >(commonly >>>one that is short and easily memorized) as a call for emergency >>>services. These numbers (e.g. 911, 112) relate to an >>emergency service >>>context and depend on a broad, regional configuration of service >>>contact methods and a geographically-constrained context of service >>>delivery. These calls are intended to be delivered to special call >>>centers equipped to manage emergency response. Successful >delivery of >>>an emergency service call within those systems requires both an >>>association of the physical location of the originator with an >>>appropriate emergency service center and call routing to deliver the >>>call to the center. >>> >>>Calls placed using Internet technologies do not use the same >>systems to >>>achieve those goals, and the common use of overlay networks >>and tunnels >>>(either as VPNs or for mobility) makes meeting them more >>challenging. >>>There are, however, Internet technologies available to describe >>>location and to manage call routing. This working group will >>describe >>>when these may be appropriate and how they may be used. This >group is >>>considering emergency services calls which might be made by >>any user of >>>the Internet, as opposed to government or military services that may >>>impose very different authentication and routing requirements. >>> >>>While this group anticipates a close working relationship >with groups >>>such as NENA and ETSI EMTEL, any solution presented must be useful >>>regardless of jurisdiction, and it must be possible to use without a >>>single, central authority. Further, it must be possible for >multiple >>>delegations within a jurisdiction to be handled >>independently, as call >>>routing for specific emergency types may be independent. >>> >>>The group will work on the maintainance of the Location-to-Service >>>Translation (LoST) protocol, on (emergency services and >non-emergency >>>services related)extensions to LoST to the as well as on necessary >>>extension related to emergency call routing. >>> >>>This working group cares about privacy and security concerns, >>and will >>>address them within its documents. >>> >>>Goals and Milestones: >>> >>>Done An Informational RFC containing terminology >>definitions >>>and the requirements >>>Done An Informational document describing the threats and >>>security considerations >>>Done A Standards Track RFC describing how to identify a >>>session set-up request is to an emergency response center >>>Done A Standards Track RFC describing how to route an >>>emergency call based on location information >>>Done An Informational document describing the Mapping >>>Protocol Architecture >>>Dec 2008 An Informational document describing the >>ECRIT Framework >>>Dec 2008 A BCP document describing the emergency call >>support for >>>devices >>>Oct 2008 An Informational document providing a problem >>statement >>>and requirements for location hiding >>>Oct 2008 An Informational document specifying how to express >>>holes in LoST service boundaries >>>Dec 2008 An Informational document describing how to >>synchronize >>>LoST servers >>>Jan 2009 A Standards Track RFC registering a SIP Resource >>>Priority Header Namespace for Local Emergency Communications >>>Feb 2009 An Informational document describing how imprecise >>>location is used for emergency context resolution >>>Feb 2009 A Standards Track RFC containing Location-to-Service >>>Translation Protocol (LoST) Extensions >>>_______________________________________________ >>>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 >> >> >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 27 13:57:10 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B8F13A6A66; Mon, 27 Oct 2008 13:57:10 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97CD83A6AB0 for ; Mon, 27 Oct 2008 13:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_EMRG=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOZRX+vWvF+R for ; Mon, 27 Oct 2008 13:57:07 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1FDBF3A68C4 for ; Mon, 27 Oct 2008 13:57:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,494,1220227200"; d="scan'208";a="25813175" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 27 Oct 2008 20:56:54 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9RKurmP019498; Mon, 27 Oct 2008 16:56:53 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9RKurHw003721; Mon, 27 Oct 2008 20:56:53 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 16:56:53 -0400 Received: from jmpolk-wxp01.cisco.com ([10.82.254.148]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 16:56:52 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Oct 2008 15:56:52 -0500 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "Richard Barnes" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 27 Oct 2008 20:56:52.0844 (UTC) FILETIME=[89F28AC0:01C93876] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8254; t=1225141013; x=1226005013; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20ECRIT=20WG=20Rechartering |Sender:=20 |To:=20=22Tschofenig,=20Hannes=20(NSN=20-=20FI/Espoo)=22=20 ,=0A=20=20=20=20=20=20=20=20=22Ri chard=20Barnes=22=20; bh=fykygYUHEj4ARUEvWJ1uERI0mDwXPheLcXsvrG5DlCw=; b=CNxg4r0yaC0eznzFaJYjJCvlZas7sMtbhUuK8WlW7vItHbnPHwB/esMwr3 qLXqDeNGvCbGrkbrfAZvOt5PvAGn+/j1T78+VwnMn7IZAtf+2iaq6N2IA/RO 8syR4Whi/p; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: ECRIT Subject: Re: [Ecrit] ECRIT WG Rechartering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 01:38 PM 10/27/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >We in the group can make decisions at any time regardless of what was >presented at the meeting. >I believe we should speed up a bit with our work. > >I also hope that you and Brian are going to update the >PhoneBCP/Framework document so that we get that document out of our way these are kinda held back by the idea of refusing the BYE discussion, aren't they? > >-----Original Message----- > >From: ext James M. Polk [mailto:jmpolk@cisco.com] > >Sent: 27 October, 2008 20:36 > >To: Richard Barnes; Tschofenig, Hannes (NSN - FI/Espoo) > >Cc: ECRIT > >Subject: Re: [Ecrit] ECRIT WG Rechartering > > > >At 08:39 AM 10/27/2008, Richard Barnes wrote: > >>I think there are a few milestones missing from this charter: > > > >I think, but could be wrong, that only one of these IDs > >(Henning's) has been presented to the WG. That usually limits > >their ability to be a WG item yet. > > > > > >>-- A Standards-Track document describing how SIP messages related to > >>emergency calling are distinguished from other > >>messages(draft-patel-ecrit-sos-parameter) > >>3GPP have made it pretty clear (both on this list and last > >week at the > >>emergency services workshop) that this mechanism or something like it > >>is a requirement for their emergency calling system. > >> > >>-- An Informational document describing requirements for emergency > >>calling by unregistered or unauthenticated devices. > >>(draft-schulzrinne-ecrit-unauthenticated access) This is an > >issue that > >>ECRIT has avoided for a long time, as other SDOs have been developing > >>mechanisms. It would be useful to have an Internet-level analysis to > >>unify these lower-level approaches and guide their development. > >> > >>-- An Informational document describing best practices for emergency > >>calling from autonomous devices (vs. human callers) > >>(draft-rosen-ecrit-ecall) > >>Lots of different organizations (e.g., EU eCall and OGC's sensor web) > >>are interested in having sensors or other devices place emergency > >>calls. These efforts could be more interoperable and better aligned > >>with the ECRIT architecture if it were made explicit which subset of > >>the ECRIT framework these systems should use. > >> > >>Cheers, > >>--Richard > >> > >> > >> > >>On Tue, Oct 14, 2008 at 10:13 AM, Tschofenig, Hannes (NSN - > >>FI/Espoo) > ><hannes.tschofenig@nsn.com> wrote: > >>Here is a first proposal for the ECRIT WG rechartering based on the > >>discussions we had around IETF#72. > >>For the moment, I have put 3 additional documents onto the charter: > >>-namespac > >>e-03.txt>http://tools.ietf.org/id/draft-polk-ecrit-local-emerg > >ency-rph- > >>namespace- > >>03.txt > >>http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc-00.txt > >>.txt>http > >>://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-00.txt > >> > >>Regarding the following two documents > >>tion-00.t > >>xt>http://tools.ietf.org/id/draft-forte-ecrit-service-classifi > >cation-00 > >>.txt http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-00.txt > >>I am waiting for additional feedback from the draft authors > >on how they > >>perceive these documents should be progressed through the > >IETF, see my > >>mail here: > >>tml>http: > >>//www.ietf.org/mail-archive/web/ecrit/current/msg05518.html > >> > >>Please take a look at it and give me feedback till the 21st October > >>2008. > >> > >>-------------------------------------------------------------- > >--------- > >>- > >>--------------------------- > >> > >>Emergency Context Resolution with Internet Technologies (ecrit) > >> > >>Description of Working Group: > >> > >>In a number of areas, the public switched telephone network > >(PSTN) has > >>been configured to recognize an explicitly specified number (commonly > >>one that is short and easily memorized) as a call for emergency > >>services. These numbers (e.g. 911, 112) relate to an > >emergency service > >>context and depend on a broad, regional configuration of service > >>contact methods and a geographically-constrained context of service > >>delivery. These calls are intended to be delivered to special call > >>centers equipped to manage emergency response. Successful delivery of > >>an emergency service call within those systems requires both an > >>association of the physical location of the originator with an > >>appropriate emergency service center and call routing to deliver the > >>call to the center. > >> > >>Calls placed using Internet technologies do not use the same > >systems to > >>achieve those goals, and the common use of overlay networks > >and tunnels > >>(either as VPNs or for mobility) makes meeting them more > >challenging. > >>There are, however, Internet technologies available to describe > >>location and to manage call routing. This working group will > >describe > >>when these may be appropriate and how they may be used. This group is > >>considering emergency services calls which might be made by > >any user of > >>the Internet, as opposed to government or military services that may > >>impose very different authentication and routing requirements. > >> > >>While this group anticipates a close working relationship with groups > >>such as NENA and ETSI EMTEL, any solution presented must be useful > >>regardless of jurisdiction, and it must be possible to use without a > >>single, central authority. Further, it must be possible for multiple > >>delegations within a jurisdiction to be handled > >independently, as call > >>routing for specific emergency types may be independent. > >> > >>The group will work on the maintainance of the Location-to-Service > >>Translation (LoST) protocol, on (emergency services and non-emergency > >>services related)extensions to LoST to the as well as on necessary > >>extension related to emergency call routing. > >> > >>This working group cares about privacy and security concerns, > >and will > >>address them within its documents. > >> > >>Goals and Milestones: > >> > >>Done An Informational RFC containing terminology > >definitions > >>and the requirements > >>Done An Informational document describing the threats and > >>security considerations > >>Done A Standards Track RFC describing how to identify a > >>session set-up request is to an emergency response center > >>Done A Standards Track RFC describing how to route an > >>emergency call based on location information > >>Done An Informational document describing the Mapping > >>Protocol Architecture > >>Dec 2008 An Informational document describing the > >ECRIT Framework > >>Dec 2008 A BCP document describing the emergency call > >support for > >>devices > >>Oct 2008 An Informational document providing a problem > >statement > >>and requirements for location hiding > >>Oct 2008 An Informational document specifying how to express > >>holes in LoST service boundaries > >>Dec 2008 An Informational document describing how to > >synchronize > >>LoST servers > >>Jan 2009 A Standards Track RFC registering a SIP Resource > >>Priority Header Namespace for Local Emergency Communications > >>Feb 2009 An Informational document describing how imprecise > >>location is used for emergency context resolution > >>Feb 2009 A Standards Track RFC containing Location-to-Service > >>Translation Protocol (LoST) Extensions > >>_______________________________________________ > >>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 > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 27 16:45:05 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D183A6C07; Mon, 27 Oct 2008 16:45:05 -0700 (PDT) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 159BA3A6A2B; Mon, 27 Oct 2008 16:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081027234502.159BA3A6A2B@core3.amsl.com> Date: Mon, 27 Oct 2008 16:45:02 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-local-emergency-rph-namespace-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --NextPart 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 : IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications Author(s) : J. Polk Filename : draft-ietf-ecrit-local-emergency-rph-namespace-00.txt Pages : 9 Date : 2008-10-27 This document creates and IANA registers the new Session Initiation Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-local-emergency-rph-namespace-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-27164422.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Mon Oct 27 17:32:19 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B303A68B5; Mon, 27 Oct 2008 17:32:19 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95FD3A68B9 for ; Mon, 27 Oct 2008 17:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWssKuzmx0-9 for ; Mon, 27 Oct 2008 17:32:17 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B6F723A689A for ; Mon, 27 Oct 2008 17:32:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,495,1220227200"; d="scan'208";a="25862613" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 28 Oct 2008 00:32:15 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9S0WFsJ014160 for ; Mon, 27 Oct 2008 20:32:15 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9S0WFQK027085 for ; Tue, 28 Oct 2008 00:32:15 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 20:32:15 -0400 Received: from jmpolk-wxp01.cisco.com ([10.82.254.148]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 20:32:15 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Oct 2008 19:32:14 -0500 To: "'ECRIT'" From: "James M. Polk" Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 28 Oct 2008 00:32:15.0312 (UTC) FILETIME=[A056AD00:01C93894] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1230; t=1225153935; x=1226017935; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20draft-ietf-ecrit-local-emergency-rph-namespace- 00 |Sender:=20 |To:=20=22'ECRIT'=22=20; bh=WW2TC7GgIzivVyqrSmWVv8Yt7d5y2ePQnP6/FeNTdUk=; b=QJuntKxhrshMJLafG+QDVuWEbfQtjwk2STUzILxX1o+R45ymG0ig5CDaht sQvqTseTQB+YMSzBtwCmEOtMcTy2xo36MtATWqyZb2AkluDGW/0oEC3Ebjx3 y8OGhGkRZP; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org ECRIT WG Here is a update to a ID I think is pretty near done, given that this is merely an IANA registration ID of an existing mechanism. Comments are wanted >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 : IANA Registering a SIP Resource Priority > Header Namespace for Local Emergency Communications > Author(s) : J. Polk > Filename : > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > Pages : 9 > Date : 2008-10-27 > >This document creates and IANA registers the new Session Initiation >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for >local emergency usage to a public safety answering point (PSAP), >between PSAPs, and between a PSAP and first responders and their >organizations. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 27 20:46:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69F8328C261; Mon, 27 Oct 2008 20:46:14 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E9E3A688A; Mon, 27 Oct 2008 20:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqUezfbGZN9M; Mon, 27 Oct 2008 20:46:07 -0700 (PDT) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by core3.amsl.com (Postfix) with ESMTP id 7B2B03A6A86; Mon, 27 Oct 2008 20:46:00 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-5.tower-171.messagelabs.com!1225165557!19482176!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 9071 invoked from network); 28 Oct 2008 03:45:58 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-5.tower-171.messagelabs.com with AES256-SHA encrypted SMTP; 28 Oct 2008 03:45:58 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id m9S3jvWk016291; Mon, 27 Oct 2008 23:45:57 -0400 In-Reply-To: To: "James M. Polk" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Mon, 27 Oct 2008 23:45:43 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 10/27/2008 11:48:32 PM, Serialize complete at 10/27/2008 11:48:32 PM Cc: 'ECRIT' , ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1024826478==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1024826478== Content-Type: multipart/alternative; boundary="=_alternative 0014AABB852574F0_=" This is a multipart message in MIME format. --=_alternative 0014AABB852574F0_= Content-Type: text/plain; charset="US-ASCII" I apologize for not tracking this as closely as I meant to, as these comments apply to earlier versions as well. This sentence at the end of sec 1 doesn't quite work. "This document IANA registers the "esnet" RPH namespace for use within emergency services networks, not just of those from citizens to PSAPs." (no clear antecedent for "those") Perhaps "This document IANA registers the "esnet" RPH namespace for use within emergency services networks, not just for calls or sessions from citizens to PSAPs." Section 2 says "This document updates the behaviors of the SIP Resource Priority header, defined in [RFC4412], during the treatment options surrounding this new "esnet" namespace only. The usage of the "esnet" namespace does not have a normal, or routine call level. Every use of this namespace will be in times of an emergency, where at least one end of the signaling is with a local emergency organization." I don't see this as an "update of the behavior of 4412". Neither the ets namespace not the wps namespace have a "normal" or "routine" call level. Every use of the wps and ets namespaces will have priority over calls without RPH. You say "This namespace, therefore, MAY be overwritten or deleted, contrary to the rules of RFC 4412 [RFC4412]." It is not clear to me why this is "contrary to the rules of 4412". It is certainly anticipated that other RPH will be overwritten or deleted, when the UAS understands the namespace. 4412 says "Existing implementations of RFC 3261 that do not participate in the resource priority mechanism follow the normal rules of RFC 3261, Section 8.2.2: "If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message". " But I do not see anywhere that is says that a UAS that DOES understand the namespace is forbidden from deleting it. For instance, sec 4.7.1 of 4412 says that "the UAC MAY attempt a subsequent request with the same or different resource value." This certainly implies the ability to overwrite or delete an RPH namespace. (See also, for instance the PTSC SAC document on the use of the ets and wps namespaces) Immediately following these statements, you give 3 options- "These proxies in the service provider MAY either o accept the existing RPH value with "esnet" in it, if one is present, and grant relative preferential treatment to the request when forwarding it to the ESINet. o replace any existing RPH value, if one is present, and insert an "esnet" namespace and give relative preferential treatment to the request when forwarding it to the ESINet. o insert an "esnet" namespace in a new RPH and give relative preferential treatment to the request when forwarding the SIP request towards the ESINet." Why do you exclude the possibility of adding the esnet RPH value without "replacing" an existing RPH value? Finally, there is another point that needs to be made clear. At least one person has contacted me expressing concern that this ID implied that the esnet namespace would have priority over other namespaces (in particular wps and ets). I assured him that this was not the case, that there was nothing prevent the expected behavior - that the ets and wps namespaces would be prioritized ahead of esnet in GETS Service Provider networks. However, since the question has already arisen, it would be a good idea to clarify this, perhaps in section 3, where you discuss the other namespaces. In particular, it needs to be made clear in section 3.2 that, even if "the local jurisdiction preferred to preempt normal calls in lieu of completing emergency calls. ", esnet calls will NOT preempt wps or ets calls. By the way, I think you mean "the local jurisdiction preferred to preempt normal calls in order to complete emergency calls. " - not "in lieu of". Or perhaps "the local jurisdiction preferred to preempt normal calls in lieu of dropping emergency calls. " In fact, it is not clear to me that 4412 permits a call with an RPH (e.g., esnet) to preempt a "normal" call (with no RPH namespace). Section 4.7.2.1 of 4412 says "4.7.2.1. User Agent Servers and Preemption Algorithm A UAS compliant with this specification MUST terminate a session established with a valid namespace and lower-priority value in favor of a new session set up with a valid namespace and higher relative priority value, unless local policy has some form of call-waiting capability enabled. " It doesn't say anything about preempting a call with no RPH Thanks Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. "James M. Polk" Sent by: ecrit-bounces@ietf.org 10/27/2008 08:32 PM To "'ECRIT'" cc Subject [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 ECRIT WG Here is a update to a ID I think is pretty near done, given that this is merely an IANA registration ID of an existing mechanism. Comments are wanted >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 : IANA Registering a SIP Resource Priority > Header Namespace for Local Emergency Communications > Author(s) : J. Polk > Filename : > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > Pages : 9 > Date : 2008-10-27 > >This document creates and IANA registers the new Session Initiation >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for >local emergency usage to a public safety answering point (PSAP), >between PSAPs, and between a PSAP and first responders and their >organizations. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > > > >< ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --=_alternative 0014AABB852574F0_= Content-Type: text/html; charset="US-ASCII"
I apologize for not tracking this as closely as I meant to, as these comments apply to  earlier versions as well.


This sentence at the end of sec 1 doesn't quite work.
"This document IANA registers the "esnet"
   RPH namespace for use within emergency services networks, not just
   of those from citizens to PSAPs." (no clear antecedent for "those")

Perhaps
"This document IANA registers the "esnet"
   RPH namespace for use within emergency services networks, not just for calls or sessions
    from citizens to PSAPs."

Section 2 says
 "This document updates the behaviors of the SIP Resource Priority
   header, defined in [RFC4412], during the treatment options
   surrounding this new "esnet" namespace only. The usage of the
   "esnet" namespace does not have a normal, or routine call level.  
   Every use of this namespace will be in times of an emergency, where
   at least one end of the signaling is with a local emergency
   organization."

I don't see this as an "update of the behavior of 4412".  Neither the ets namespace not the wps
namespace have a "normal" or "routine" call level.  Every use of the wps and ets namespaces will
have priority over calls without RPH.

You say "This
   namespace, therefore, MAY be overwritten or deleted, contrary to the
   rules of RFC 4412 [RFC4412]."

It is not clear to me why this is "contrary to the rules of 4412".  It is certainly anticipated
that other RPH will be overwritten or deleted, when the UAS understands the namespace.

4412 says "Existing implementations of RFC 3261 that do not participate in the
   resource priority mechanism follow the normal rules of RFC 3261,
   Section 8.2.2: "If a UAS does not understand a header field in a
   request (that is, the header field is not defined in this
   specification or in any supported extension), the server MUST ignore
   that header field and continue processing the message". "

But I do not see anywhere that is says that a UAS that DOES understand the namespace is
forbidden from deleting it.  For instance, sec 4.7.1 of 4412 says that "the UAC
   MAY attempt a subsequent request with the same or different resource
   value."  This certainly implies the ability to overwrite or delete an RPH namespace.  

(See also, for instance the PTSC SAC document on the use of the ets and wps namespaces)

Immediately following these statements, you give 3 options-
"These proxies in the service provider
   MAY either

   o  accept the existing RPH value with "esnet" in it, if one is
      present, and grant relative preferential treatment to the request
      when forwarding it to the ESINet.

   o  replace any existing RPH value, if one is present, and insert an
      "esnet" namespace and give relative preferential treatment to the
      request when forwarding it to the ESINet.

   o  insert an "esnet" namespace in a new RPH and give relative
      preferential treatment to the request when forwarding the SIP
      request towards the ESINet."

Why do you exclude the possibility of adding the esnet RPH value without "replacing" an existing RPH value?

Finally, there is another point that  needs to be made clear.  At least one person has contacted me expressing concern that this ID implied that the esnet namespace would  have priority over other namespaces (in particular wps and ets).  I assured him that this was not the case, that there was nothing prevent the expected behavior - that the ets and wps namespaces would be prioritized ahead of esnet in GETS Service Provider networks.

However, since the question has already arisen, it would be a good idea to clarify  this, perhaps in  section 3, where you discuss  the other namespaces.  In particular, it needs to be made clear in section 3.2  that, even if  "the   local jurisdiction preferred to preempt normal calls in lieu of
   completing emergency calls. ", esnet calls will NOT preempt wps or ets calls.

By the way, I think you mean "the   local jurisdiction preferred to preempt normal calls in order to complete emergency calls. "  - not "in lieu of".  Or perhaps "the   local jurisdiction preferred to preempt normal calls in lieu of  dropping emergency calls. "

In fact, it is not clear to me that 4412 permits a call with an RPH (e.g., esnet)  to preempt a "normal" call (with no RPH namespace).  Section 4.7.2.1 of 4412 says
"4.7.2.1.  User Agent Servers and Preemption Algorithm

   A UAS compliant with this specification MUST terminate a session
   established with a valid namespace and lower-priority value in favor
   of a new session set up with a valid namespace and higher relative
   priority value, unless local policy has some form of call-waiting
   capability enabled. "

It doesn't say anything about preempting a call with no RPH

Thanks

Janet






This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.


"James M. Polk" <jmpolk@cisco.com>
Sent by: ecrit-bounces@ietf.org

10/27/2008 08:32 PM

To
"'ECRIT'" <ecrit@ietf.org>
cc
Subject
[Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00





ECRIT WG

Here is a update to a ID I think is pretty near done, given that this
is merely an IANA registration ID of an existing mechanism.

Comments are wanted

>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           : IANA Registering a SIP Resource Priority
> Header Namespace for Local Emergency Communications
>         Author(s)       : J. Polk
>         Filename        :
> draft-ietf-ecrit-local-emergency-rph-namespace-00.txt
>         Pages           : 9
>         Date            : 2008-10-27
>
>This document creates and IANA registers the new Session Initiation
>Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for
>local emergency usage to a public safety answering point (PSAP),
>between PSAPs, and between a PSAP and first responders and their
>organizations.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-00.txt
>
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-00.txt>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
--=_alternative 0014AABB852574F0_=-- --===============1024826478== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1024826478==-- From ecrit-bounces@ietf.org Tue Oct 28 02:01:07 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC3683A68DE; Tue, 28 Oct 2008 02:01:07 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80193A68DE for ; Tue, 28 Oct 2008 02:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=-2.013, BAYES_00=-2.599, MANGLED_EMRG=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xC0xLGz2Qrsz for ; Tue, 28 Oct 2008 02:01:06 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id D2AEF3A682A for ; Tue, 28 Oct 2008 02:01:05 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9S913Hm017082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Oct 2008 10:01:03 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9S90xLU028460 for ; Tue, 28 Oct 2008 10:01:02 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 10:00:46 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 10:00:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C938DB.A94F7E36" Date: Tue, 28 Oct 2008 11:00:44 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] I-DAction:draft-ietf-ecrit-local-emergency-rph-namespace-00.txt Thread-Index: Ack4jjVopRs8D6ppTKufq9jVhAFbDAATTM1g From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 28 Oct 2008 09:00:45.0382 (UTC) FILETIME=[A9C1E660:01C938DB] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081028100103-63993BB0-E0358409/0-0/0-15 X-purgate-size: 2568/0 Subject: [Ecrit] FW: I-DAction:draft-ietf-ecrit-local-emergency-rph-namespace-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C938DB.A94F7E36 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable A mistake has happened as it seems.=20 James has submitted his draft as a WG item since we discussed it as part of the re-chartering activitiy.=20 Unfortunately, the updated charter has not yet been approved formally by our Ads. However, it seems that Marc has already accepted the submission.=20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of ext Internet-Drafts@ietf.org >Sent: 28 October, 2008 01:45 >To: i-d-announce@ietf.org >Cc: ecrit@ietf.org >Subject: [Ecrit]=20 >I-DAction:draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. >This draft is a work item of the Emergency Context Resolution=20 >with Internet Technologies Working Group of the IETF. > > > Title : IANA Registering a SIP Resource=20 >Priority Header Namespace for Local Emergency Communications > Author(s) : J. Polk > Filename :=20 >draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > Pages : 9 > Date : 2008-10-27 > >This document creates and IANA registers the new Session=20 >Initiation Protocol (SIP) Resource Priority header (RPH)=20 >namespace "esnet" for local emergency usage to a public safety=20 >answering point (PSAP), between PSAPs, and between a PSAP and=20 >first responders and their organizations. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emer >gency-rph-namespace-00.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail=20 >reader implementation to automatically retrieve the ASCII=20 >version of the Internet-Draft. > ------_=_NextPart_001_01C938DB.A94F7E36 Content-Type: application/octet-stream; name="draft-ietf-ecrit-local-emergency-rph-namespace-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-ecrit-local-emergency-rph-namespace-00.URL Content-Disposition: attachment; filename="draft-ietf-ecrit-local-emergency-rph-namespace-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWVjcml0LWxvY2FsLWVtZXJnZW5jeS1ycGgtbmFtZXNwYWNlLTAwLnR4dA0K ------_=_NextPart_001_01C938DB.A94F7E36 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C938DB.A94F7E36-- From ecrit-bounces@ietf.org Tue Oct 28 04:43:48 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1910D3A6C09; Tue, 28 Oct 2008 04:43:48 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A7823A6C09 for ; Tue, 28 Oct 2008 04:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.289 X-Spam-Level: X-Spam-Status: No, score=-5.289 tagged_above=-999 required=5 tests=[AWL=1.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2DW7lmNbL39 for ; Tue, 28 Oct 2008 04:43:41 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 771A83A6C03 for ; Tue, 28 Oct 2008 04:43:41 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9SBhYdJ020498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Oct 2008 12:43:34 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9SBhVrv021099; Tue, 28 Oct 2008 12:43:33 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 12:43:30 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 12:43:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 28 Oct 2008 13:43:27 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT WG Rechartering Thread-Index: Ack4dpbQ07KOClgVQQWZKoKkWzN96QAeqVfg References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext James M. Polk" , "Richard Barnes" X-OriginalArrivalTime: 28 Oct 2008 11:43:30.0430 (UTC) FILETIME=[662DF9E0:01C938F2] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081028124334-115F0BB0-A0111282/0-0/0-15 X-purgate-size: 606/0 Cc: ECRIT Subject: Re: [Ecrit] ECRIT WG Rechartering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >At 01:38 PM 10/27/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>We in the group can make decisions at any time regardless of what was >>presented at the meeting. >>I believe we should speed up a bit with our work. >> >>I also hope that you and Brian are going to update the >>PhoneBCP/Framework document so that we get that document out >of our way > >these are kinda held back by the idea of refusing the BYE >discussion, aren't they? Nope. As mentioned in the initial plan for Phone BCP we would delete the sentence about not sending a BYE. FINISH the document. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 28 14:56:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18F323A6CB9; Tue, 28 Oct 2008 14:56:43 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294C33A6CB9 for ; Tue, 28 Oct 2008 14:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-vKKUxLHVvA for ; Tue, 28 Oct 2008 14:56:39 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 63EB13A6C7F for ; Tue, 28 Oct 2008 14:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1225230998; x=1256766998; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<385b0c950810271223j70fc5f b4l76c0801c615587e8@mail.gmail.com>|References:=20<385b0c 950810030631m10a6e47ehd07dc417700fa528@mail.gmail.com>=0D =0A=20<0913B6CD18F370498CD65864CF254E9006BFCF94@zharhxm1. corp.nortel.com>=0D=0A=20<019801c9256a$cd661430$68323c90$ @net>=0D=0A=20<8C837214C95C864C9F34F3635C2A65750B199F92@S EA-EXCHVS-2.telecomsys.com>=0D=0A=20<0913B6CD18F370498CD6 5864CF254E90071648FD@zharhxm1.corp.nortel.com>=0D=0A=20<3 85b0c950810271223j70fc5fb4l76c0801c615587e8@mail.gmail.co m>|Date:=20Tue,=2028=20Oct=202008=2014:56:31=20-0700|To: =20John-Luc=20Bakker=20,=0D =0A=20=20=20=20=20=20=20=20Milan=20Patel=0D=0A=09|From:=20Ted=20Hardie=20 |Subject:=20Re:=20[Ecrit]=20[Fwd:=20I-D=0D=0A=20Action:dr aft-patel-ecrit-sos-parameter-00.txt]|CC:=20ECRIT=20|Content-Type:=20text/plain=3B=20charset=3D"us -ascii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5417 "=3B=20a=3D"11529239"; bh=pxg1lqkdDruc9WoYa+2efgmSuqrVq+Sj4Pw+DJtKrSc=; b=i4dsdtiaNgBOixmGRlCTeKwZv6l/rA6SDXZIEijX0OhgomvoVDWvQYxZ paQ4JLJme+7h8+f22DDyaF8YgsA9jocizxlpHlwwslpQfRvhrqMMJAXaz GEO8RVodKEVI7fH2PTHtDkpl/9l4HuDOZrn54F3caP2GRok56yd1yipn5 g=; X-IronPort-AV: E=McAfee;i="5300,2777,5417"; a="11529239" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Oct 2008 14:56:38 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9SLucmX026162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Oct 2008 14:56:38 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9SLuXMW020156 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Oct 2008 14:56:33 -0700 (PDT) Received: from nasanexhub02.na.qualcomm.com (10.46.143.120) by nasanexhc03.na.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 28 Oct 2008 14:56:33 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 28 Oct 2008 14:56:33 -0700 Received: from [10.72.34.67] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 28 Oct 2008 14:56:32 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <385b0c950810271223j70fc5fb4l76c0801c615587e8@mail.gmail.com> References: <385b0c950810030631m10a6e47ehd07dc417700fa528@mail.gmail.com> <0913B6CD18F370498CD65864CF254E9006BFCF94@zharhxm1.corp.nortel.com> <019801c9256a$cd661430$68323c90$@net> <8C837214C95C864C9F34F3635C2A65750B199F92@SEA-EXCHVS-2.telecomsys.com> <0913B6CD18F370498CD65864CF254E90071648FD@zharhxm1.corp.nortel.com> <385b0c950810271223j70fc5fb4l76c0801c615587e8@mail.gmail.com> Date: Tue, 28 Oct 2008 14:56:31 -0700 To: John-Luc Bakker , Milan Patel From: Ted Hardie Cc: ECRIT Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think it would be useful to have a working group discussion of this draft in Minneapolis, and maybe even some time prior to that for informal discussion. A couple of process questions: Since this is a SIP URI parameter, it is governed by 3969. That means this must be in a standards-track RFC. Is it also governed by a SIP change process the means SIP has to bless it? If so, has it been seen by SIP and discussed there? Can I assume it should be discussed in parallel, if this is required, given the timelines Milan has put forward? On the technical front, I'm not sure I yet understand what John-Luc is suggesting. Is there a set off diffs or a proposed addition that we can point to? (RFC Editor note style, for example) As a suggestion for content for the presentation, can I ask that Milan write up a brief summary of the other methods that were considered and rejected here, along with the reasoning? I have the suspicion that we could play "name your favorite alternate method" for some time on this one, and short-cutting that with pointers to discussions that have already completed might help. regards, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 28 17:26:34 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89CDA3A6CB0; Tue, 28 Oct 2008 17:26:34 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DAA53A6C7F for ; Tue, 28 Oct 2008 17:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUI88oOr0KWQ for ; Tue, 28 Oct 2008 17:26:26 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BAE1C3A6C00 for ; Tue, 28 Oct 2008 17:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1225239986; x=1256775986; h=message-id:in-reply-to:references:x-mailer: x-message-flag:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20<8C837214C95C864C9F34F3635C2A65750B199F92 @SEA-EXCHVS-2.telecomsys.com>|References:=20<385b0c950810 030631m10a6e47ehd07dc417700fa528@mail.gmail.com><0913B6CD =0D=0A=2018F370498CD65864CF254E9006BFCF94@zharhxm1.corp.n ortel.com>=0D=0A=20<019801c9256a$cd661430$68323c90$@net> =0D=0A=20<8C837214C95C864C9F34F3635C2A65750B199F92@SEA-EX CHVS-2.telecomsys.com>|X-Mailer:=20Eudora=20for=20Mac=20O S=20X|X-message-flag:=20Warning:=20Outlook=20in=20use.=20 =20Upgrade=20to=20Eudora:=20|Date: =20Tue,=2028=20Oct=202008=2015:47:24=20-0700|To:=20Roger =20Marshall=20,=20ECRIT=20|From:=20Randall=20Gellens=20|Subject:=20Re:=20[Ecrit]=20[Fwd:=20I-D=0D=0A=20Action :draft-patel-ecrit-sos-parameter-00.txt]|MIME-Version:=20 1.0|Content-Type:=20text/plain=3B=20charset=3D"us-ascii" =3B=20format=3Dflowed|X-Random-Sig-Tag:=201.0b28 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5417"=3B=20a =3D"11461993"; bh=H34dAaycIsWeARfyk99h55+Qw/2kReFPUkilOdhDr0w=; b=g8lufmoHOizrKPCrXdf3LUCqNkAO4PfAo43L4iES8Ux8lskQlL2/1DQ8 Pbl8cT4JWQ2vHFaY4mH/1oBRE/zMLgUe+sizZVrlUwKcJ1NZbaaD0aCyZ reWidBeCT4Ts/6rXUJjpcha3cM+H8jph0INohW0JSWqbzJFnz4Nh2FKPZ g=; X-IronPort-AV: E=McAfee;i="5100,188,5417"; a="11461993" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Oct 2008 17:26:26 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9T0QPEg015305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Oct 2008 17:26:25 -0700 Received: from nasanexhc01.na.qualcomm.com (nasanexhc01.na.qualcomm.com [172.30.37.21]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9T0QL4S022868 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Oct 2008 17:26:21 -0700 Received: from nasanexhub01.na.qualcomm.com (10.46.93.121) by nasanexhc01.na.qualcomm.com (172.30.37.21) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 28 Oct 2008 17:26:21 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 28 Oct 2008 17:26:20 -0700 Received: from [192.168.1.13] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 28 Oct 2008 17:26:19 -0700 Message-ID: In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B199F92@SEA-EXCHVS-2.telecomsys.com> References: <385b0c950810030631m10a6e47ehd07dc417700fa528@mail.gmail.com><0913B6CD 18F370498CD65864CF254E9006BFCF94@zharhxm1.corp.nortel.com> <019801c9256a$cd661430$68323c90$@net> <8C837214C95C864C9F34F3635C2A65750B199F92@SEA-EXCHVS-2.telecomsys.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 28 Oct 2008 15:47:24 -0700 To: Roger Marshall , ECRIT From: Randall Gellens MIME-Version: 1.0 X-Random-Sig-Tag: 1.0b28 Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 11:00 AM -0700 10/27/08, Roger Marshall wrote: > I think that Brian has captured 4 topics that this draft (and list > discussion) is targeting: > 1. Marking emergency call registration > 2. Keeping the Route header containing an SOS URN to the end > 3. Tagging the UA as an emergency call > 4. Marking a call back for specific call treatment > > Regardless of whether all of these issues are adequately handled in this > early draft (likely not yet), what does seem to be clear is that 3GPP > has additional requirements not currently met by the existing marking > mechanism. > > I would like to see this draft be turned into a working group item. > After that, we can work out the exact approach. I would encourage > others to weigh in on making this a wg item. It sounds like the WG does need a WG item to address the requirements. (I haven't had a chance to thoroughly read this particular draft, so I don't have an opinion as to if this specific draft should be the basis for the WG draft.) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Finagle's Second Law: No matter what the anticipated result, there will always be someone eager to (a) misinterpret it, (b) fake it, or (c) believe it happened according to his own pet theory. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 29 06:00:40 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA8A3A68AC; Wed, 29 Oct 2008 06:00:40 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 412433A6885 for ; Wed, 29 Oct 2008 06:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duX2TaQC4YOx for ; Wed, 29 Oct 2008 06:00:39 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 56F3E3A68AC for ; Wed, 29 Oct 2008 06:00:39 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9TD0Z4m025451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 29 Oct 2008 14:00:35 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9TD0VGm008609 for ; Wed, 29 Oct 2008 14:00:35 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Oct 2008 13:59:50 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Oct 2008 13:59:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 29 Oct 2008 14:43:47 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-rosen-ecrit-premature-disconnect-rqmts: Regulatory Requirements Thread-Index: Ack5w/xQPNMizDlNSma5i9VO8k7QDg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 29 Oct 2008 12:59:29.0246 (UTC) FILETIME=[2DDBD7E0:01C939C6] Subject: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts: Regulatory Requirements X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I have heard several times of about regulatory requirements about Premature Disconnect. Can someone send us a pointer to these requirements? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 29 06:06:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B9C3A68AC; Wed, 29 Oct 2008 06:06:45 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B4E3A68AC for ; Wed, 29 Oct 2008 06:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[AWL=-0.831, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Pw2vrQfraAV for ; Wed, 29 Oct 2008 06:06:43 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 04E413A686D for ; Wed, 29 Oct 2008 06:06:42 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9TD6ch2010024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 29 Oct 2008 14:06:38 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9TD6aJ2011813 for ; Wed, 29 Oct 2008 14:06:38 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Oct 2008 14:06:31 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Oct 2008 14:06:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 29 Oct 2008 15:06:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-rosen-ecrit-premature-disconnect-rqmts-00.txt: Implementations? Thread-Index: Ack5xy1Eqlh0oMG9TMSqOGfdglhwkA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 29 Oct 2008 13:06:30.0041 (UTC) FILETIME=[28AC1090:01C939C7] Subject: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt: Implementations? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Are there any attempts to come up with some prototyping implementations to see how complicated some of the proposed mechanisms are? This would give us valuable insights, I believe. Maybe someone has a spare student. I am asking because we hear all the time that end host manufacturers are unwilling to make changes to their SIP stack, to add new location protocols, to implement dial string recognition, to implement Phone BCP, etc. How do we convince them to implement these mechanisms? (particularly if they are more challenging implementation-wise) Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 29 06:10:10 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2D6F3A69DF; Wed, 29 Oct 2008 06:10:10 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92DF13A686B for ; Wed, 29 Oct 2008 06:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.861 X-Spam-Level: X-Spam-Status: No, score=-2.861 tagged_above=-999 required=5 tests=[AWL=-1.089, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sh98hx+bLjS8 for ; Wed, 29 Oct 2008 06:10:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 7706F3A686D for ; Wed, 29 Oct 2008 06:10:07 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9TDA5Uo019924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 29 Oct 2008 14:10:05 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9TDA5VB029848 for ; Wed, 29 Oct 2008 14:10:05 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Oct 2008 14:08:50 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Oct 2008 14:08:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 29 Oct 2008 15:08:58 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-rosen-ecrit-premature-disconnect-rqmts-00.txt Thread-Index: Ack5x4Ehe6EKJrT1Tz2huU01Y3k2IA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 29 Oct 2008 13:08:49.0581 (UTC) FILETIME=[7BD82DD0:01C939C7] Subject: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org A few clarifying comments: PD-1 It must be possible to have the PSAP rapidly re-establish communications with a caller that attempts to prematurely disconnect from the call. Rationale: Time is paramount when handling emergency calls. Keeping resources active and available until the call taker determines the call can be terminated saves valuable time. This seems to assume that a regular call-back is insufficient. Are there some timing requirements? PD-2 It must be possible for the PSAP to know when the user has attempted to prematurely disconnect Rationale: Knowledge of the device state (and caller action) gives valuable information to the call taker which may influence how the call will be managed going forward. How would this look like in reality? What information is this? Who provides it? PD-3 Reconnecting the caller must work reasonably reliably under congestion conditions. Rationale: PSAPs require robust mechanisms to perform their tasks. Unless you have end-to-end QoS mechanisms in place this will not work. Since we don't have them it will not work PD-5 When PD-1 is enforced,the caller must not be able to place another call until the PSAP allows the call to be released. Rationale: Priority must be given to the PSAP until such time the call taker determines the call can be terminated. Isn't there a chance to leave orphan state around that leaves the end host unusable? PD-6 All Media and signaling streams flowing between the caller and call taker must be maintained to the extent needed for rapid reconnection. Rationale: Media and signaling resources must be available as soon as the user re-answers. This essentially means that one should not tear-down the session. Would dummy media packets flow? AC-1 It must be possible for the PSAP, or the network that serves it, to have abandoned calls complete and stay connected. This does sound complicated or even impossible. I guess it is possible on the PSAP operators side to accept the call even though the call taker has not picked up the call yet. With many implementations this will obviously create a lot of confusion where the caller assumes that he can speak already whereas the call taker has not picked up the phone.. Missing something? AC-2 AC-1 shall be applied at the earliest possible time in the call establishment process. In an IP-based environment, how would this look like? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 29 06:14:01 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4FDA3A69AF; Wed, 29 Oct 2008 06:14:01 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24FEB3A686B for ; Wed, 29 Oct 2008 06:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajS4JIP-z1MF for ; Wed, 29 Oct 2008 06:14:00 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 588FF3A69AF for ; Wed, 29 Oct 2008 06:13:59 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m9TDF0qS016483; Wed, 29 Oct 2008 08:15:00 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 08:13:56 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 14:13:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 29 Oct 2008 14:13:51 +0100 Message-ID: <5D1A7985295922448D5550C94DE291800245BE95@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt:Implementations? Thread-Index: Ack5xy1Eqlh0oMG9TMSqOGfdglhwkAAAGiOQ References: From: "DRAGE, Keith \(Keith\)" To: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "ECRIT" X-OriginalArrivalTime: 29 Oct 2008 13:13:54.0108 (UTC) FILETIME=[315B4FC0:01C939C8] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt:Implementations? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org We are discussing the requirements still, not the implementation, AND THEY DO NOT YET have consensus. I have repeatedly asked for an updated version that reflects my comments made back in July and it so far has not appeared. I see little progress being made in this direction of discussion unless we know what the requirements are first, and they are agreed. Regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Wednesday, October 29, 2008 1:07 PM > To: ECRIT > Subject: [Ecrit] > draft-rosen-ecrit-premature-disconnect-rqmts-00.txt:Implementations? > > Are there any attempts to come up with some prototyping > implementations to see how complicated some of the proposed > mechanisms are? This would give us valuable insights, I > believe. Maybe someone has a spare student. > > I am asking because we hear all the time that end host > manufacturers are unwilling to make changes to their SIP > stack, to add new location protocols, to implement dial > string recognition, to implement Phone BCP, etc. > > How do we convince them to implement these mechanisms? > (particularly if they are more challenging implementation-wise) > > Ciao > Hannes > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 29 07:22:10 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B4E28C377; Wed, 29 Oct 2008 07:22:10 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3209D28C35A for ; Wed, 29 Oct 2008 07:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUSgpjFKMyue for ; Wed, 29 Oct 2008 07:22:08 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id EF6E428C386 for ; Wed, 29 Oct 2008 07:22:07 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KvBvl-0001IW-1T; Wed, 29 Oct 2008 09:21:53 -0500 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: In-Reply-To: Date: Wed, 29 Oct 2008 10:21:38 -0400 Message-ID: <018201c939d1$a9dc3960$fd94ac20$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack5x4Ehe6EKJrT1Tz2huU01Y3k2IAAAZi3Q Content-language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org See inline prefaced by "
" -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Wednesday, October 29, 2008 9:09 AM To: ECRIT Subject: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt A few clarifying comments: PD-1 It must be possible to have the PSAP rapidly re-establish communications with a caller that attempts to prematurely disconnect from the call. Rationale: Time is paramount when handling emergency calls. Keeping resources active and available until the call taker determines the call can be terminated saves valuable time. This seems to assume that a regular call-back is insufficient. Are there some timing requirements?
Well, the notion is no noticeable delay from the user's point of view: he attempts to disconnect, the phone alerts, he picks up the "call" -- the call taker should be able to immediately speak to him again. I guess we could put a time limit on it if you insist. ?1 second? PD-2 It must be possible for the PSAP to know when the user has attempted to prematurely disconnect Rationale: Knowledge of the device state (and caller action) gives valuable information to the call taker which may influence how the call will be managed going forward. How would this look like in reality? What information is this? Who provides it?
Presumably there is signaling that informs the PSAP. The call taker's screen displays an indication that the caller attempted to disconnect. Depending on how the mechanism works, the call taker may have to manually react to cause alerting on the user's device, or it may be automatic. When the call is re-established (whatever that actually means) the call taker screen indicates the caller is back "on the line". Of course, another course of action for the call taker is to terminate. PD-3 Reconnecting the caller must work reasonably reliably under congestion conditions. Rationale: PSAPs require robust mechanisms to perform their tasks. Unless you have end-to-end QoS mechanisms in place this will not work. Since we don't have them it will not work
This requirement is probably best met by NOT dropping the signaling or media sessions. If the mechanism assumes they are dropped, and then an attempt is made to re-establish, it's unlikely to work in congestion conditions. On the other hand, calls that are up tend to stay up in most network designs. Of course, without QoS, you can't guarantee it, which is why "reasonably reliably" is appropriate. PD-5 When PD-1 is enforced,the caller must not be able to place another call until the PSAP allows the call to be released. Rationale: Priority must be given to the PSAP until such time the call taker determines the call can be terminated. Isn't there a chance to leave orphan state around that leaves the end host unusable?
Well, indeed, some proposed mechanisms (such as just not sending BYE) have the capability to "brick" the phone. The later proposals don't do that. There is the discussion of what to do with a multi-line phone. It's not clear what the right thing to do here is. The kind of normal "flash, start another call" thing should not be allowed. If you had a real multibutton, multiline, with separate identities, etc, maybe that should be allowed EXCEPT that, generally, we say disable hold, and normally in order to switch from one line to another you have to terminate or hold. PD-6 All Media and signaling streams flowing between the caller and call taker must be maintained to the extent needed for rapid reconnection. Rationale: Media and signaling resources must be available as soon as the user re-answers. This essentially means that one should not tear-down the session. Would dummy media packets flow?
I suppose that requires some discussion. Phonebcp says to disable silence suppression. I suppose that means packets flow with silence. AC-1 It must be possible for the PSAP, or the network that serves it, to have abandoned calls complete and stay connected. This does sound complicated or even impossible. I guess it is possible on the PSAP operators side to accept the call even though the call taker has not picked up the call yet. With many implementations this will obviously create a lot of confusion where the caller assumes that he can speak already whereas the call taker has not picked up the phone..
There clearly is some point at which no reasonable system could force a call to go through. We allow (albeit discourage) networks to detect emergency calls for example, and if the call was abandoned before the network determined it was an emergency call, then it couldn't force it to complete. I think our working definition is that the signaling reaches the PSAP, and a reply is received by the endpoint. This allows a normal negotiation of features. Although it's conceivable that the call taker could be delayed in responding, the sequence as seen by the user is that they attempt to disconnect, but it doesn't work; the call proceeds. If they "hang up", the device should alert. If they pick up the call again, the call is either answered, with the call taker on the line, or it's still ringing. Either works. AC-2 AC-1 shall be applied at the earliest possible time in the call establishment process. In an IP-based environment, how would this look like?
Since it seems to be a requirement that the capability is enabled (or not) by the PSAP, the signaling has to reach the PSAP and be responded to. I think that is the earliest time. I'd like it to be earlier, but I don't think it's practical to make it any earlier. Hopefully, this is all how many tenths of a second. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 29 07:47:35 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 113D53A6D37; Wed, 29 Oct 2008 07:47:35 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6865B3A6D34 for ; Wed, 29 Oct 2008 07:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baE0Wl40OVT1 for ; Wed, 29 Oct 2008 07:47:28 -0700 (PDT) Received: from mail141.messagelabs.com (mail141.messagelabs.com [85.158.137.99]) by core3.amsl.com (Postfix) with ESMTP id B479D3A6BEC for ; Wed, 29 Oct 2008 07:47:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-13.tower-141.messagelabs.com!1225291477!18373400!107 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [206.47.0.173] Received: (qmail 20899 invoked from network); 29 Oct 2008 14:47:18 -0000 Received: from bell.ca (HELO TLS.Exchange.Bell.ca) (206.47.0.173) by server-13.tower-141.messagelabs.com with RC4-SHA encrypted SMTP; 29 Oct 2008 14:47:18 -0000 Received: from hub02-wyn.bell.corp.bce.ca (142.182.199.50) by dm1c8f.exchange1.bell.ca (198.235.102.112) with Microsoft SMTP Server id 8.1.278.0; Wed, 29 Oct 2008 10:46:39 -0400 Received: from MBX02.bell.corp.bce.ca ([142.182.199.11]) by hub02-wyn.bell.corp.bce.ca ([142.182.199.50]) with mapi; Wed, 29 Oct 2008 10:46:34 -0400 From: To: , Date: Wed, 29 Oct 2008 10:46:32 -0400 Thread-Topic: draft-rosen-ecrit-premature-disconnect-rqmts: Regulator Requirements Thread-Index: Ack5w/xQPNMizDlNSma5i9VO8k7QDgABODig Message-ID: <0FEAC1C09868B34A982F4FB40254B37C2637DA980E@MBX02.bell.corp.bce.ca> References: In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts: Regulator Requirements X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes, PSAP Call Control features are an integral part of the Emergency Services P= roviders' E9-1-1 service offer to the Canadian citizens. As such, those fea= tures are described in each ESP'S tariff document approved by our regulator= y body, the CRTC. Here is one example: Look for section 5.(c) on page 4: http://www.bce.ca/en/aboutbce/regulatoryinformation/tarrifs/index.php/ItemV= iew.asp?Tariff=3DGT%20%20%20&Part=3D%20%20%202%20%20%20%20%20%20&Item=3D%20= 1400%20%20%20%20%20 Guy -----Message d'origine----- De : ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] De la part de T= schofenig, Hannes (NSN - FI/Espoo) Envoy=E9 : 29 octobre 2008 08:44 =C0 : ECRIT Objet : [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts: Regulatory Re= quirements I have heard several times of about regulatory requirements about Premature Disconnect. Can someone send us a pointer to these requirements? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 29 08:12:17 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83E13A6D1C; Wed, 29 Oct 2008 08:12:17 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AE7A3A6BEC for ; Wed, 29 Oct 2008 08:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.772 X-Spam-Level: X-Spam-Status: No, score=-2.772 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNGDixzxSjR6 for ; Wed, 29 Oct 2008 08:12:16 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id B04533A69B2 for ; Wed, 29 Oct 2008 08:12:15 -0700 (PDT) Received: from [192.168.1.145] ([156.152.12.167]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9TFBuEh015247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Oct 2008 11:12:02 -0400 (EDT) Message-Id: <569CC9EB-681E-408B-89E1-3E1A4AD23841@cs.columbia.edu> From: Henning Schulzrinne To: ECRIT In-Reply-To: <018201c939d1$a9dc3960$fd94ac20$@net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 29 Oct 2008 11:11:55 -0400 References: <018201c939d1$a9dc3960$fd94ac20$@net> X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, I realize you are pushing a certain solution, so the discussion is largely pointless, but let's try. I think it would be much more helpful if the requirements draft, given the controversy, were to be edited by somebody without a horse in the race. On Oct 29, 2008, at 10:21 AM, Brian Rosen wrote: > > This seems to assume that a regular call-back is insufficient. Are > there > some timing requirements? >
Well, the notion is no noticeable delay from the user's point > of view: > he attempts to disconnect, the phone alerts, he picks up the "call" > -- the > call taker should be able to immediately speak to him again. I > guess we > could put a time limit on it if you insist. ?1 second? > Any human reaction is going to take time, even if the alerting is instantaneous, particularly since the user will be startled by the alerting (they are not expecting a call and won't know how this mechanism works). Thus, a few seconds aren't going to make any real difference. > > > PD-3 Reconnecting the caller must work reasonably reliably under > congestion conditions. > Rationale: PSAPs require robust mechanisms to perform their > tasks. > > Unless you have end-to-end QoS mechanisms in place this will not work. > Since we don't have them it will not work >
This requirement is probably best met by NOT dropping the > signaling or > media sessions. If the mechanism assumes they are dropped, and then > an > attempt is made to re-establish, it's unlikely to work in congestion > conditions. On the other hand, calls that are up tend to stay up in > most > network designs. Of course, without QoS, you can't guarantee it, > which is > why "reasonably reliably" is appropriate. I don't know what difference it makes to the delivery probability of IP packets whether a call has been up for ten minutes or ten seconds. Or are you talking about gateway resources? > > > > PD-5 When PD-1 is enforced,the caller must not be able to place > another call until the PSAP allows the call to be released. > Rationale: Priority must be given to the PSAP until such time the > call taker determines the call can be terminated. > > Isn't there a chance to leave orphan state around that leaves the end > host unusable? >
Well, indeed, some proposed mechanisms (such as just not sending > BYE) > have the capability to "brick" the phone. The later proposals don't > do > that. We had already discussed and achieved, I thought, rough consensus (minus Brian) that this is not an acceptable requirement since it does not leave final control with the user. I strongly object to the requirement. > > PD-6 All Media and signaling streams flowing between the caller and > call taker must be maintained to the extent needed for rapid > reconnection. > Rationale: Media and signaling resources must be available as > soon > as the user re-answers. > > This essentially means that one should not tear-down the session. > Would > dummy media packets flow? >
I suppose that requires some discussion. Phonebcp says to disable > silence suppression. I suppose that means packets flow with silence. This is a bogus requirement with no technical rationale, except some strange notion of keeping the pipes warm. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 29 09:00:46 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D97D3A696E; Wed, 29 Oct 2008 09:00:46 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E82683A69C0 for ; Wed, 29 Oct 2008 09:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVK+zJMsnlHX for ; Wed, 29 Oct 2008 09:00:41 -0700 (PDT) Received: from mail139.messagelabs.com (mail139.messagelabs.com [85.158.137.67]) by core3.amsl.com (Postfix) with ESMTP id AF84C3A696E for ; Wed, 29 Oct 2008 09:00:38 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-2.tower-139.messagelabs.com!1225296011!16558157!12 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [206.47.0.168] Received: (qmail 18912 invoked from network); 29 Oct 2008 16:00:22 -0000 Received: from srp004371srs (HELO TLS.Exchange.bell.ca) (206.47.0.168) by server-2.tower-139.messagelabs.com with RC4-SHA encrypted SMTP; 29 Oct 2008 16:00:22 -0000 Received: from hub02-wyn.bell.corp.bce.ca (142.182.199.50) by dm1c8g.exchange1.bell.ca (198.235.102.109) with Microsoft SMTP Server id 8.1.291.1; Wed, 29 Oct 2008 11:59:58 -0400 Received: from MBX02.bell.corp.bce.ca ([142.182.199.11]) by hub02-wyn.bell.corp.bce.ca ([142.182.199.50]) with mapi; Wed, 29 Oct 2008 11:59:59 -0400 From: To: , Date: Wed, 29 Oct 2008 11:59:56 -0400 Thread-Topic: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt: Implementations? Thread-Index: Ack5xy1Eqlh0oMG9TMSqOGfdglhwkAAFwPXg Message-ID: <0FEAC1C09868B34A982F4FB40254B37C2637DA9887@MBX02.bell.corp.bce.ca> References: In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt: Implementations? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes, I wonder if some cable company could provide such info. I understand that C= ableLabs has issued a SIP-Based Residential Telephony specification back in= 2006 that includes some mechanisms involving the UE for controlling premat= ure disconnects, signal hook status and provide ringback. Just a thought. Guy -----Message d'origine----- De : ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] De la part de T= schofenig, Hannes (NSN - FI/Espoo) Envoy=E9 : 29 octobre 2008 09:07 =C0 : ECRIT Objet : [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt: Implem= entations? Are there any attempts to come up with some prototyping implementations to see how complicated some of the proposed mechanisms are? This would give us valuable insights, I believe. Maybe someone has a spare student. I am asking because we hear all the time that end host manufacturers are unwilling to make changes to their SIP stack, to add new location protocols, to implement dial string recognition, to implement Phone BCP, etc. How do we convince them to implement these mechanisms? (particularly if they are more challenging implementation-wise) Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 29 09:46:11 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A6173A681B; Wed, 29 Oct 2008 09:46:11 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BCA83A635F for ; Wed, 29 Oct 2008 09:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-k0BwYl5xXU for ; Wed, 29 Oct 2008 09:46:06 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 3A6FE3A6889 for ; Wed, 29 Oct 2008 09:46:05 -0700 (PDT) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m9TGkxbx020031; Wed, 29 Oct 2008 11:46:59 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 11:45:55 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 17:45:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 29 Oct 2008 17:45:52 +0100 Message-ID: <5D1A7985295922448D5550C94DE291800245BF90@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] Thread-Index: Ack5SBiCLvEz4WEASv+qUWxrTVHfXwAnNcGQ References: <385b0c950810030631m10a6e47ehd07dc417700fa528@mail.gmail.com><0913B6CD18F370498CD65864CF254E9006BFCF94@zharhxm1.corp.nortel.com><019801c9256a$cd661430$68323c90$@net><8C837214C95C864C9F34F3635C2A65750B199F92@SEA-EXCHVS-2.telecomsys.com><0913B6CD18F370498CD65864CF254E90071648FD@zharhxm1.corp.nortel.com><385b0c950810271223j70fc5fb4l76c0801c615587e8@mail.gmail.com> From: "DRAGE, Keith \(Keith\)" To: "Ted Hardie" , "John-Luc Bakker" , "Milan Patel" X-OriginalArrivalTime: 29 Oct 2008 16:45:53.0585 (UTC) FILETIME=[CEC17A10:01C939E5] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: ECRIT Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org RFC 3969 defines: 3. Use of the Registry SIP and SIPS URI parameters and values for these parameters MUST be documented in a standards-track RFC in order to be registered by IANA. This documentation MUST fully explain the syntax, intended usage, and semantics of the parameter. The intent of this requirement is to assure interoperability between independent implementations, and to prevent accidental namespace collisions between implementations of dissimilar features. 4.2. Registration Policy for SIP and SIPS URI Parameters As per the terminology in RFC 2434 [4], the registration policy for SIP and SIPS URI parameters shall be "Specification Required". For the purposes of this registry, the parameter for which IANA registration is requested MUST be defined by a standards-track RFC. http://tools.ietf.org/html/draft-peterson-rai-rfc3427bis-00 defines: RFC3969 [4] stipulates that the (original) RFC2434 rule of "Specification Required" applies to registrations of new SIP URI parameters; however Section 3 of that same document mandates that a standards action is required to register new parameters with the IANA. This contradiction arose from a misunderstanding of the nature of the RFC2434 categories; the intention was for the IANA Considerations to mandate that Standards Action is required. A standards track RFC must be done by a group that is chartered to do it, or be AD sponsored - that does not mean it has to be the SIP group unless we establish such a policy. Regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Ted Hardie > Sent: Tuesday, October 28, 2008 9:57 PM > To: John-Luc Bakker; Milan Patel > Cc: ECRIT > Subject: Re: [Ecrit] [Fwd: I-D > Action:draft-patel-ecrit-sos-parameter-00.txt] > > I think it would be useful to have a working group > discussion of this draft in Minneapolis, and maybe even some > time prior to that for informal discussion. A couple of > process questions: > > Since this is a SIP URI parameter, it is governed by 3969. > That means this must be in a standards-track RFC. Is it also > governed by a SIP change process the means SIP has to bless it? > > If so, has it been seen by SIP and discussed there? Can I > assume it should be discussed in parallel, if this is > required, given the timelines Milan has put forward? > > On the technical front, I'm not sure I yet understand what > John-Luc is suggesting. Is there a set off diffs or a > proposed addition that we can point to? (RFC Editor note > style, for example) > > As a suggestion for content for the presentation, can I ask > that Milan write up a brief summary of the other methods that > were considered and rejected here, along with the reasoning? > I have the suspicion that we could play "name your favorite > alternate method" for some time on this one, and > short-cutting that with pointers to discussions that have > already completed might help. > > regards, > Ted > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 29 14:03:19 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB4383A6B42; Wed, 29 Oct 2008 14:03:19 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72383A6B5D for ; Wed, 29 Oct 2008 14:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YCZK9IzdFxz for ; Wed, 29 Oct 2008 14:03:17 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id ADC673A6B3F for ; Wed, 29 Oct 2008 14:03:17 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KvGLu-0007zk-Bz; Wed, 29 Oct 2008 14:05:10 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'ECRIT'" References: <018201c939d1$a9dc3960$fd94ac20$@net> <569CC9EB-681E-408B-89E1-3E1A4AD23841@cs.columbia.edu> In-Reply-To: <569CC9EB-681E-408B-89E1-3E1A4AD23841@cs.columbia.edu> Date: Wed, 29 Oct 2008 15:05:05 -0400 Message-ID: <00c501c939f9$4378a5f0$ca69f1d0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack5223Tlt0nUXasTjmdqlxml+hW+gAG4ntg Content-language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" Subject: Re: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org First of all, I don't object to changing authors on requirements. I do think I can faithfully record consensus, but if chairs want someone else, I'm fine with handing over the xml file. I believe the "reconnect" is the time from when the user picks back up from attempting to disconnect, so his reaction time is not counted. We certainly could attempt to more carefully define what we are talking about In most network designs I am aware of, the reaction to call congestion is admission control. Calls in progress stay up, new calls are refused. I would like this mechanism to not get caught by that. There are no guarantees. While I'm sympathetic to the generalized notion that users retain control, I'm persuaded by people who actually have experience that it actually works better to have the PSAP in control. As we have said before, there is no way to really hold the call up; you can always rip the wire out of the wall, pull out the battery, etc. Whether there should be some form of override, and what that should be, is certainly something we can discuss further, and I'm fully prepared to lose that argument. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Wednesday, October 29, 2008 11:12 AM To: ECRIT Cc: Tschofenig, Hannes (NSN - FI/Espoo); Brian Rosen Subject: Re: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt Brian, I realize you are pushing a certain solution, so the discussion is largely pointless, but let's try. I think it would be much more helpful if the requirements draft, given the controversy, were to be edited by somebody without a horse in the race. On Oct 29, 2008, at 10:21 AM, Brian Rosen wrote: > > This seems to assume that a regular call-back is insufficient. Are > there > some timing requirements? >
Well, the notion is no noticeable delay from the user's point > of view: > he attempts to disconnect, the phone alerts, he picks up the "call" > -- the > call taker should be able to immediately speak to him again. I > guess we > could put a time limit on it if you insist. ?1 second? > Any human reaction is going to take time, even if the alerting is instantaneous, particularly since the user will be startled by the alerting (they are not expecting a call and won't know how this mechanism works). Thus, a few seconds aren't going to make any real difference. > > > PD-3 Reconnecting the caller must work reasonably reliably under > congestion conditions. > Rationale: PSAPs require robust mechanisms to perform their > tasks. > > Unless you have end-to-end QoS mechanisms in place this will not work. > Since we don't have them it will not work >
This requirement is probably best met by NOT dropping the > signaling or > media sessions. If the mechanism assumes they are dropped, and then > an > attempt is made to re-establish, it's unlikely to work in congestion > conditions. On the other hand, calls that are up tend to stay up in > most > network designs. Of course, without QoS, you can't guarantee it, > which is > why "reasonably reliably" is appropriate. I don't know what difference it makes to the delivery probability of IP packets whether a call has been up for ten minutes or ten seconds. Or are you talking about gateway resources? > > > > PD-5 When PD-1 is enforced,the caller must not be able to place > another call until the PSAP allows the call to be released. > Rationale: Priority must be given to the PSAP until such time the > call taker determines the call can be terminated. > > Isn't there a chance to leave orphan state around that leaves the end > host unusable? >
Well, indeed, some proposed mechanisms (such as just not sending > BYE) > have the capability to "brick" the phone. The later proposals don't > do > that. We had already discussed and achieved, I thought, rough consensus (minus Brian) that this is not an acceptable requirement since it does not leave final control with the user. I strongly object to the requirement. > > PD-6 All Media and signaling streams flowing between the caller and > call taker must be maintained to the extent needed for rapid > reconnection. > Rationale: Media and signaling resources must be available as > soon > as the user re-answers. > > This essentially means that one should not tear-down the session. > Would > dummy media packets flow? >
I suppose that requires some discussion. Phonebcp says to disable > silence suppression. I suppose that means packets flow with silence. This is a bogus requirement with no technical rationale, except some strange notion of keeping the pipes warm. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 29 18:55:44 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416B53A68B3; Wed, 29 Oct 2008 18:55:44 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821A93A68B3 for ; Wed, 29 Oct 2008 18:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6DallIpzpZ3 for ; Wed, 29 Oct 2008 18:55:42 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A05BF3A63EC for ; Wed, 29 Oct 2008 18:55:42 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9J00GSO40SXU@szxga04-in.huawei.com> for ecrit@ietf.org; Thu, 30 Oct 2008 09:55:40 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9J00C8J40SG5@szxga04-in.huawei.com> for ecrit@ietf.org; Thu, 30 Oct 2008 09:55:40 +0800 (CST) Received: from [127.0.0.1] ([10.85.202.251]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K9J001L540RGV@szxml05-in.huawei.com> for ecrit@ietf.org; Thu, 30 Oct 2008 09:55:40 +0800 (CST) Date: Thu, 30 Oct 2008 09:55:40 +0800 From: Robins George To: ECRIT IETF , Sun Qian , HENNING SCHULZRINNE Message-id: <4909141C.9030900@huawei.com> Organization: Huawei Tech MIME-version: 1.0 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Subject: [Ecrit] draft-sun-ecrit-shelter-service-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robinsg@huawei.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1392648716==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============1392648716== Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT 
Hi All,

We have modified this draft based on the feedback from mailing list and 
offline discussions. The new version of the draft can be found here.
http://www.ietf.org/internet-drafts/draft-sun-ecrit-shelter-service-01.txt

 
Comments are appreciated.

Regards,
Robins


----

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Shelter Service And Classification
	Author(s)       : Q. Sun, et al.
	Filename        : draft-sun-ecrit-shelter-service-01.txt
	Pages           : 9
	Date            : 2008-10-29

This document defines and registers a new service 'shelter', for the
service URN to find, what instances of shelter service are closest to
the user's location.  The Location-to-Service Translation (LoST)
protocol can provide these information for a geographical region.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sun-ecrit-shelter-service-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--

--===============1392648716== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1392648716==-- From ecrit-bounces@ietf.org Wed Oct 29 19:49:20 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776B23A6DA2; Wed, 29 Oct 2008 19:49:20 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4451F3A6DA2 for ; Wed, 29 Oct 2008 19:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.072 X-Spam-Level: X-Spam-Status: No, score=-3.072 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wue1RFFBIOPY for ; Wed, 29 Oct 2008 19:49:18 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 408D33A6DA1 for ; Wed, 29 Oct 2008 19:49:18 -0700 (PDT) Received: from [156.152.12.172] ([156.152.12.172]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9U2n9nA011822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Oct 2008 22:49:11 -0400 (EDT) Message-Id: <5F949D07-8641-4A09-9EA0-2F5BEE99D77B@cs.columbia.edu> From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <00c501c939f9$4378a5f0$ca69f1d0$@net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 29 Oct 2008 22:45:06 -0400 References: <018201c939d1$a9dc3960$fd94ac20$@net> <569CC9EB-681E-408B-89E1-3E1A4AD23841@cs.columbia.edu> <00c501c939f9$4378a5f0$ca69f1d0$@net> X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , 'ECRIT' Subject: Re: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Oct 29, 2008, at 3:05 PM, Brian Rosen wrote: > > In most network designs I am aware of, the reaction to call > congestion is > admission control. Calls in progress stay up, new calls are > refused. I > would like this mechanism to not get caught by that. There are no > guarantees. I don't understand the admission control bit. Who is doing admission control here? I assume you are not talking RSVP here and I'm not aware of SIP proxies doing admission control. This just seems to be a way to bias the requirements towards a particular solution. > > > While I'm sympathetic to the generalized notion that users retain > control, > I'm persuaded by people who actually have experience that it > actually works > better to have the PSAP in control. As we have said before, there > is no > way to really hold the call up; you can always rip the wire out of > the wall, > pull out the battery, etc. Whether there should be some form of > override, > and what that should be, is certainly something we can discuss > further, and > I'm fully prepared to lose that argument. I admit that I see this as a non-negotiable position on my part. The interests of the caller and the PSAP are not always aligned. In reporting an emergency, possibly to help somebody else, I'm not giving up my rights to my device or my Internet connection. In a free society, citizens have a right to be left alone, even by a well- meaning PSAP. I'd feel much better about the process if we could make some rough- consensus calls soon on these fundamental issues soon, so that we can avoid cycling back to the same old issues. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 29 19:50:41 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37AD28C3A1; Wed, 29 Oct 2008 19:50:41 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D9328C3A1 for ; Wed, 29 Oct 2008 19:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.222 X-Spam-Level: X-Spam-Status: No, score=-3.222 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovyN09Pvn28M for ; Wed, 29 Oct 2008 19:50:40 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 2E8CE3A6DA1 for ; Wed, 29 Oct 2008 19:50:40 -0700 (PDT) Received: from [156.152.12.172] ([156.152.12.172]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9U2oaMN011971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Oct 2008 22:50:37 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <00c501c939f9$4378a5f0$ca69f1d0$@net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 29 Oct 2008 22:50:36 -0400 References: <018201c939d1$a9dc3960$fd94ac20$@net> <569CC9EB-681E-408B-89E1-3E1A4AD23841@cs.columbia.edu> <00c501c939f9$4378a5f0$ca69f1d0$@net> X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , 'ECRIT' Subject: Re: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Oct 29, 2008, at 3:05 PM, Brian Rosen wrote: > > In most network designs I am aware of, the reaction to call > congestion is > admission control. Calls in progress stay up, new calls are > refused. I > would like this mechanism to not get caught by that. There are no > guarantees. I don't understand the admission control bit. Who is doing admission control here? I assume you are not talking RSVP here and I'm not aware of SIP proxies doing admission control. This just seems to be a way to bias the requirements towards a particular solution. > > > While I'm sympathetic to the generalized notion that users retain > control, > I'm persuaded by people who actually have experience that it > actually works > better to have the PSAP in control. As we have said before, there > is no > way to really hold the call up; you can always rip the wire out of > the wall, > pull out the battery, etc. Whether there should be some form of > override, > and what that should be, is certainly something we can discuss > further, and > I'm fully prepared to lose that argument. In reporting an emergency, possibly to help somebody else, I'm not giving up my rights to my device or my Internet connection. In a free society, citizens have a right to be left alone, even by a well- meaning PSAP. I think we'd make more progress if we could make some rough-consensus calls soon on these fundamental issues soon, so that we can avoid cycling back to the same old issues where we clearly have different opinions and make different trade-offs. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 29 21:40:53 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28E903A680F; Wed, 29 Oct 2008 21:40:53 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314333A680F for ; Wed, 29 Oct 2008 21:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0QU0jsVBySH for ; Wed, 29 Oct 2008 21:40:51 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id C133C3A67FB for ; Wed, 29 Oct 2008 21:40:50 -0700 (PDT) Received: from [10.71.0.132] (ip-64-139-9-115.dsl.sca.megapath.net [64.139.9.115]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9U4eXoa023706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Oct 2008 00:40:45 -0400 (EDT) Message-Id: <8C0FC05F-5F21-498C-9D50-0EF90AB7A43B@cs.columbia.edu> From: Henning Schulzrinne To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 30 Oct 2008 00:40:18 -0400 References: X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: ECRIT Subject: Re: [Ecrit] Service Classification X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I don't have a good answer. Based on the subject matter, the best approach would be to declare both to be experimental. I don't know if there's an override on the 'standards-action' part that doesn't require writing an rfc5031bis document. As we have seen from the SIP P- header experience, creating some kind of x- registry is counterproductive. Any suggestions? Henning On Oct 12, 2008, at 5:36 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi all, > > I wanted to figure out how to proceed with the following two > documents: > http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.txt > http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-00.txt > > The IANA consideration section of RFC 5031 > http://www.ietf.org/rfc/rfc5031.txt says: > " > Services and sub-services are identified by labels managed by IANA, > according to the processes outlined in [RFC2434] in a new registry > called "Service URN Labels". Thus, creating a new service requires > IANA action. The policy for adding top-level service labels is > 'Standards Action'. (This document defines the top-level services > 'sos' and 'counseling'.) The policy for assigning labels to sub- > services may differ for each top-level service designation and MUST > be defined by the document describing the top-level service. > " > > Unfortunately, both documents define top-level services. As such, we > would have to pick them up as WG item in order to advance them. > I don't like that approach too much. > > So, I would like to hear from the authors on how they think these type > of documents should be progressed through the IETF. > > Ciao > Hannes > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 29 21:50:53 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0EA3A6852; Wed, 29 Oct 2008 21:50:52 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623693A6852 for ; Wed, 29 Oct 2008 21:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANQEHkLV-UIc for ; Wed, 29 Oct 2008 21:50:50 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 5281B3A680F for ; Wed, 29 Oct 2008 21:50:49 -0700 (PDT) Received: from [10.71.0.132] (ip-64-139-9-115.dsl.sca.megapath.net [64.139.9.115]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9U4o2GX028616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Oct 2008 00:50:46 -0400 (EDT) Message-Id: <01E42119-7212-4622-8ED8-0592FCB91674@cs.columbia.edu> From: Henning Schulzrinne To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 30 Oct 2008 00:49:58 -0400 References: X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: ECRIT Subject: Re: [Ecrit] draft-ietf-ecrit-mapping-arch: Discuss by Russ X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Can the WG chairs please convey this to the AD/Russ Housley? I suspect their opinion carries more weight than the author's... On Oct 12, 2008, at 7:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > https://datatracker.ietf.org/idtracker/draft-ietf-ecrit-mapping-arch/com > ment/78013/ > > ----------------- > > Commented by: Russ Housley > Comment: > Looking at http://www.ietf.org/u/ietfchair/info-exp.html > (especially Guideline 3), I wonder why this is not Experimental. > > ----------------- > > When reading that document then the document status should be > experimental. When considering how people would typically perceive an > experimental document then it should be informal. I fear that nobody > knows nor has ever read the above-mentioned document. > > I suggest to leave it informational. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 29 22:15:34 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AC283A69E3; Wed, 29 Oct 2008 22:15:34 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D59503A69E3 for ; Wed, 29 Oct 2008 22:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65tlGrHG6BlL for ; Wed, 29 Oct 2008 22:15:32 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id E7AEF3A6873 for ; Wed, 29 Oct 2008 22:15:31 -0700 (PDT) Received: from [10.71.0.132] (ip-64-139-9-115.dsl.sca.megapath.net [64.139.9.115]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9U5FSJc002044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Oct 2008 01:15:30 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 30 Oct 2008 01:15:27 -0400 References: X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: ECRIT Subject: Re: [Ecrit] draft-ietf-ecrit-mapping-arch: Discuss #2 by Cullen X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I've changed this to just refer to the LoST specification and named circles and polygons as examples. On Oct 12, 2008, at 7:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > https://datatracker.ietf.org/idtracker/draft-ietf-ecrit-mapping-arch/com > ment/78860/ > > ----------------- > > > Commented by: Cullen Jennings > Comment: My understanding is the queries supported here need to > match the queries possible in LOST. If this is incorrect, please let > me > know. Right now this document does not allow the Polygon, Circle, > Ellipse, ArcBand that are allowed in Lost. > > ----------------- > > This document largely describes LoST protocol deployment. I wouldn't > find additional aspects that could get out of sync between LoST and > this > document (beyond what I commented in my previous mail). > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 30 01:36:57 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012663A68F8; Thu, 30 Oct 2008 01:36:57 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 334253A68F8 for ; Thu, 30 Oct 2008 01:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.223 X-Spam-Level: X-Spam-Status: No, score=-5.223 tagged_above=-999 required=5 tests=[AWL=1.376, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGljwdslV1r9 for ; Thu, 30 Oct 2008 01:36:55 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 181F13A686B for ; Thu, 30 Oct 2008 01:36:54 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9U8agUa014997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Oct 2008 09:36:42 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9U8aeEj027518; Thu, 30 Oct 2008 09:36:42 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 09:36:04 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 09:36:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 10:36:04 +0200 Message-ID: In-Reply-To: <8C0FC05F-5F21-498C-9D50-0EF90AB7A43B@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Service Classification Thread-Index: Ack6SbPCd0l3V4jAT3y7WzDADPcmqwAIB6Kw References: <8C0FC05F-5F21-498C-9D50-0EF90AB7A43B@cs.columbia.edu> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Henning Schulzrinne" X-OriginalArrivalTime: 30 Oct 2008 08:36:04.0555 (UTC) FILETIME=[8BF121B0:01C93A6A] Cc: ECRIT Subject: Re: [Ecrit] Service Classification X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I do see two ways forward: A) Issue a RFC 5031bis to change the policy B) Submit the two drafts as Standards Track documents. I prefer (A) and submit the drafts as experimental with expert review from ECRIT. >-----Original Message----- >From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >Sent: 30 October, 2008 06:40 >To: Tschofenig, Hannes (NSN - FI/Espoo) >Cc: ECRIT >Subject: Re: [Ecrit] Service Classification > >I don't have a good answer. Based on the subject matter, the >best approach would be to declare both to be experimental. I >don't know if there's an override on the 'standards-action' >part that doesn't require writing an rfc5031bis document. As >we have seen from the SIP P- header experience, creating some >kind of x- registry is counterproductive. > >Any suggestions? > >Henning > >On Oct 12, 2008, at 5:36 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >> Hi all, >> >> I wanted to figure out how to proceed with the following two >> documents: >> >http://tools.ietf.org/id/draft-forte-ecrit-service-classification-00.t >> xt http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-00.txt >> >> The IANA consideration section of RFC 5031 >> http://www.ietf.org/rfc/rfc5031.txt says: >> " >> Services and sub-services are identified by labels managed by IANA, >> according to the processes outlined in [RFC2434] in a new registry >> called "Service URN Labels". Thus, creating a new service requires >> IANA action. The policy for adding top-level service labels is >> 'Standards Action'. (This document defines the top-level services >> 'sos' and 'counseling'.) The policy for assigning labels to sub- >> services may differ for each top-level service designation and MUST >> be defined by the document describing the top-level service. >> " >> >> Unfortunately, both documents define top-level services. As such, we >> would have to pick them up as WG item in order to advance them. >> I don't like that approach too much. >> >> So, I would like to hear from the authors on how they think >these type >> of documents should be progressed through the IETF. >> >> Ciao >> Hannes >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 30 01:51:27 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B2F33A6AB1; Thu, 30 Oct 2008 01:51:27 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F33603A6AB1 for ; Thu, 30 Oct 2008 01:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.286 X-Spam-Level: X-Spam-Status: No, score=-3.286 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFRSzi3JAuc0 for ; Thu, 30 Oct 2008 01:51:26 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id EF3E63A6A91 for ; Thu, 30 Oct 2008 01:51:25 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9U8pFGv008160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Oct 2008 09:51:15 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9U8pBuE023860; Thu, 30 Oct 2008 09:51:15 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 09:50:50 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 09:50:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 10:49:29 +0200 Message-ID: In-Reply-To: <01E42119-7212-4622-8ED8-0592FCB91674@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-mapping-arch: Discuss by Russ Thread-Index: Ack6Sxmz3zXFMHsMQl+G5CgA+F5B2wAH422A References: <01E42119-7212-4622-8ED8-0592FCB91674@cs.columbia.edu> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 30 Oct 2008 08:50:49.0104 (UTC) FILETIME=[9B2C9900:01C93A6C] Cc: ECRIT Subject: Re: [Ecrit] draft-ietf-ecrit-mapping-arch: Discuss by Russ X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Russ, I wonder whether you had a strong opinion about your DISCUSS. We would like to stay with the document type of informational rather than switching to experimental. While many of us in the group do not have a strong opinion about the document type (information vs. experimental) the chairs believe that labeling a document as experimental in this space of emergency services might give the audience from other organizations that are not so familiar with the details of the IETF process a very different perception, namely one that this stuff is by no means ready for deployment. Ciao Hannes >Can the WG chairs please convey this to the AD/Russ HousleyI >suspect their opinion carries more weight than the author's... > >On Oct 12, 2008, at 7:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >> >https://datatracker.ietf.org/idtracker/draft-ietf-ecrit-mapping-arch/c >> om >> ment/78013/ >> >> ----------------- >> >> Commented by: Russ Housley >> Comment: >> Looking at http://www.ietf.org/u/ietfchair/info-exp.html >> (especially Guideline 3), I wonder why this is not Experimental. >> >> ----------------- >> >> When reading that document then the document status should be >> experimental. When considering how people would typically >perceive an >> experimental document then it should be informal. I fear that nobody >> knows nor has ever read the above-mentioned document. >> >> I suggest to leave it informational. >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 30 03:17:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05A2428C20B; Thu, 30 Oct 2008 03:17:43 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A624028C127; Thu, 30 Oct 2008 03:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.256 X-Spam-Level: X-Spam-Status: No, score=-5.256 tagged_above=-999 required=5 tests=[AWL=1.343, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-0wXKY31P+8; Thu, 30 Oct 2008 03:17:40 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id E81B228C175; Thu, 30 Oct 2008 03:17:39 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9UAHZIn010445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Oct 2008 11:17:35 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9UAHZAh023734; Thu, 30 Oct 2008 11:17:35 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 11:17:35 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 11:17:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C93A78.B94AA84A" Date: Thu, 30 Oct 2008 12:17:30 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PROTO Writeup for draft-ietf-ecrit-specifying-holes-01.txt Thread-Index: Ack6eLdujzyq7CJvTAGzvt5yz/PXLQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "Jon Peterson" , X-OriginalArrivalTime: 30 Oct 2008 10:17:34.0381 (UTC) FILETIME=[B9C2D5D0:01C93A78] Cc: ECRIT , iesg@ietf.org Subject: [Ecrit] PROTO Writeup for draft-ietf-ecrit-specifying-holes-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C93A78.B94AA84A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The ECRIT working group would like to publish draft-ietf-ecrit-specifying-holes-01.txt. The PROTO writeup is attached. Ciao Hannes=20 ------_=_NextPart_001_01C93A78.B94AA84A Content-Type: text/plain; name="draft-ietf-ecrit-specifying-holes-01_PROTO.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-ecrit-specifying-holes-01_PROTO.txt Content-Disposition: attachment; filename="draft-ietf-ecrit-specifying-holes-01_PROTO.txt" UFJPVE8gV1JJVEVVUCBmb3IgZHJhZnQtaWV0Zi1lY3JpdC1zcGVjaWZ5aW5nLWhvbGVzLTAxLnR4 dAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09CgogICAoMS5hKSAgV2hvIGlzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBmb3IgdGhpcyBkb2N1 bWVudD8gIEhhcyB0aGUKICAgICAgICAgIERvY3VtZW50IFNoZXBoZXJkIHBlcnNvbmFsbHkgcmV2 aWV3ZWQgdGhpcyB2ZXJzaW9uIG9mIHRoZQogICAgICAgICAgZG9jdW1lbnQgYW5kLCBpbiBwYXJ0 aWN1bGFyLCBkb2VzIGhlIG9yIHNoZSBiZWxpZXZlIHRoaXMKICAgICAgICAgIHZlcnNpb24gaXMg cmVhZHkgZm9yIGZvcndhcmRpbmcgdG8gdGhlIElFU0cgZm9yIHB1YmxpY2F0aW9uPwoKICAgICAg RG9jdW1lbnQgU2hlcGhlcmQgaXMgSGFubmVzIFRzY2hvZmVuaWcuCiAgICAgIFRoZSBkb2N1bWVu dCBpcyByZWFkeSBmb3IgcHVibGljYXRpb25zIGFuZCBJIGhhdmUgcmV2aWV3ZWQgdGhlIAogICAg ICBkb2N1bWVudCBwZXJzb25hbGx5LgoKICAgKDEuYikgIEhhcyB0aGUgZG9jdW1lbnQgaGFkIGFk ZXF1YXRlIHJldmlldyBib3RoIGZyb20ga2V5IFdHIG1lbWJlcnMKICAgICAgICAgIGFuZCBmcm9t IGtleSBub24tV0cgbWVtYmVycz8gIERvZXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhhdmUKICAg ICAgICAgIGFueSBjb25jZXJucyBhYm91dCB0aGUgZGVwdGggb3IgYnJlYWR0aCBvZiB0aGUgcmV2 aWV3cyB0aGF0CiAgICAgICAgICBoYXZlIGJlZW4gcGVyZm9ybWVkPwoJCSAgCgkgIFRoaXMgZG9j dW1lbnQgaXMgYW4gaW5mb3JtYXRpdmUgY2xhcmlmaWNhdGlvbiBvbiBob3cgdG8gCiAgICAgIGRl c2NyaWJlcyBob2xlcyBpbiBzZXJ2aWNlIGJvdW5kYXJpZXMuIAoKCSAgQ2FybCBSZWVkIGZyb20g dGhlIE9HQyBoYXMgcGVyZm9ybWVkIGEgcmV2aWV3IG9mIHRoZSAKCSAgZG9jdW1lbnQuIAoKCSAg VGhlcmUgYXJlIG5vIGNvbmNlcm5zIGFib3V0IHRoZSBkZXB0aCBhbmQgdGhlIGJyZWFkdGggb2Yg dGhlIHJldmlld3MuIAoKICAgKDEuYykgIERvZXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhhdmUg Y29uY2VybnMgdGhhdCB0aGUgZG9jdW1lbnQKICAgICAgICAgIG5lZWRzIG1vcmUgcmV2aWV3IGZy b20gYSBwYXJ0aWN1bGFyIG9yIGJyb2FkZXIgcGVyc3BlY3RpdmUsCiAgICAgICAgICBlLmcuLCBz ZWN1cml0eSwgb3BlcmF0aW9uYWwgY29tcGxleGl0eSwgc29tZW9uZSBmYW1pbGlhciB3aXRoCiAg ICAgICAgICBBQUEsIGludGVybmF0aW9uYWxpemF0aW9uLCBvciBYTUw/CiAgICAgICAgICAKICAg ICAgVGhlIGRvY3VtZW50IGNvbnRhaW5zIFhNTCBzbmlwcGV0cy4gCgkgIFRoZSBYTUwgc25pcHBl dHMgbWFrZSB1c2Ugb2YgdGhlIGRlc2NyaXB0aW9uIHByb3ZpZGVkIGluIAoJICBodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWdlb3ByaXYtcGRpZi1sby1wcm9m aWxlLTEzLnR4dAoKCSAgQWRkaXRpb25hbCByZXZpZXdzIG9mIHRoZSBYTUwgaW5zdGFuY2UgZG9j dW1lbnRzIGlzIG5vdCBuZWNlc3NhcnkuICAKCSAgCiAgICgxLmQpICBEb2VzIHRoZSBEb2N1bWVu dCBTaGVwaGVyZCBoYXZlIGFueSBzcGVjaWZpYyBjb25jZXJucyBvcgogICAgICAgICAgaXNzdWVz IHdpdGggdGhpcyBkb2N1bWVudCB0aGF0IHRoZSBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yCiAg ICAgICAgICBhbmQvb3IgdGhlIElFU0cgc2hvdWxkIGJlIGF3YXJlIG9mPyAgRm9yIGV4YW1wbGUs IHBlcmhhcHMgaGUKICAgICAgICAgIG9yIHNoZSBpcyB1bmNvbWZvcnRhYmxlIHdpdGggY2VydGFp biBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQsIG9yCiAgICAgICAgICBoYXMgY29uY2VybnMgd2hldGhl ciB0aGVyZSByZWFsbHkgaXMgYSBuZWVkIGZvciBpdC4gIEluIGFueQogICAgICAgICAgZXZlbnQs IGlmIHRoZSBXRyBoYXMgZGlzY3Vzc2VkIHRob3NlIGlzc3VlcyBhbmQgaGFzIGluZGljYXRlZAog ICAgICAgICAgdGhhdCBpdCBzdGlsbCB3aXNoZXMgdG8gYWR2YW5jZSB0aGUgZG9jdW1lbnQsIGRl dGFpbCB0aG9zZQogICAgICAgICAgY29uY2VybnMgaGVyZS4gIEhhcyBhbiBJUFIgZGlzY2xvc3Vy ZSByZWxhdGVkIHRvIHRoaXMgZG9jdW1lbnQKICAgICAgICAgIGJlZW4gZmlsZWQ/ICBJZiBzbywg cGxlYXNlIGluY2x1ZGUgYSByZWZlcmVuY2UgdG8gdGhlCiAgICAgICAgICBkaXNjbG9zdXJlIGFu ZCBzdW1tYXJpemUgdGhlIFdHIGRpc2N1c3Npb24gYW5kIGNvbmNsdXNpb24gb24KICAgICAgICAg IHRoaXMgaXNzdWUuCgogICAgICBUaGVyZSBhcmUgbm8gY29uY2VybnMuIAoJICAKICAgKDEuZSkg IEhvdyBzb2xpZCBpcyB0aGUgV0cgY29uc2Vuc3VzIGJlaGluZCB0aGlzIGRvY3VtZW50PyAgRG9l cyBpdAogICAgICAgICAgcmVwcmVzZW50IHRoZSBzdHJvbmcgY29uY3VycmVuY2Ugb2YgYSBmZXcg aW5kaXZpZHVhbHMsIHdpdGgKICAgICAgICAgIG90aGVycyBiZWluZyBzaWxlbnQsIG9yIGRvZXMg dGhlIFdHIGFzIGEgd2hvbGUgdW5kZXJzdGFuZCBhbmQKICAgICAgICAgIGFncmVlIHdpdGggaXQ/ CiAgICAgICAgICAKICAgICAgVGhlcmUgaXMgY29uc2Vuc3VzIGJlaGluZCB0aGlzIGRvY3VtZW50 LgogICAgICAKICAgKDEuZikgIEhhcyBhbnlvbmUgdGhyZWF0ZW5lZCBhbiBhcHBlYWwgb3Igb3Ro ZXJ3aXNlIGluZGljYXRlZCBleHRyZW1lCiAgICAgICAgICBkaXNjb250ZW50PyAgSWYgc28sIHBs ZWFzZSBzdW1tYXJpemUgdGhlIGFyZWFzIG9mIGNvbmZsaWN0IGluCiAgICAgICAgICBzZXBhcmF0 ZSBlbWFpbCBtZXNzYWdlcyB0byB0aGUgUmVzcG9uc2libGUgQXJlYSBEaXJlY3Rvci4gIChJdAog ICAgICAgICAgc2hvdWxkIGJlIGluIGEgc2VwYXJhdGUgZW1haWwgYmVjYXVzZSB0aGlzIHF1ZXN0 aW9ubmFpcmUgaXMKICAgICAgICAgIGVudGVyZWQgaW50byB0aGUgSUQgVHJhY2tlci4pCiAgICAg ICAgICAKICAgICAgVGhlcmUgYXJlIG5vIGNvbmNlcm5zIHdpdGggdGhpcyBkb2N1bWVudC4gCgog ICAoMS5nKSAgSGFzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBwZXJzb25hbGx5IHZlcmlmaWVkIHRo YXQgdGhlCiAgICAgICAgICBkb2N1bWVudCBzYXRpc2ZpZXMgYWxsIElEIG5pdHM/ICAoU2VlCiAg ICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL0lELUNoZWNrbGlzdC5odG1sIGFuZAogICAgICAg ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL2lkbml0cy8uKSAgQm9pbGVycGxhdGUgY2hl Y2tzIGFyZQogICAgICAgICAgbm90IGVub3VnaDsgdGhpcyBjaGVjayBuZWVkcyB0byBiZSB0aG9y b3VnaC4gIEhhcyB0aGUgZG9jdW1lbnQKICAgICAgICAgIG1ldCBhbGwgZm9ybWFsIHJldmlldyBj cml0ZXJpYSBpdCBuZWVkcyB0bywgc3VjaCBhcyB0aGUgTUlCCiAgICAgICAgICBEb2N0b3IsIG1l ZGlhIHR5cGUsIGFuZCBVUkkgdHlwZSByZXZpZXdzPyAgSWYgdGhlIGRvY3VtZW50CiAgICAgICAg ICBkb2VzIG5vdCBhbHJlYWR5IGluZGljYXRlIGl0cyBpbnRlbmRlZCBzdGF0dXMgYXQgdGhlIHRv cCBvZgogICAgICAgICAgdGhlIGZpcnN0IHBhZ2UsIHBsZWFzZSBpbmRpY2F0ZSB0aGUgaW50ZW5k ZWQgc3RhdHVzIGhlcmUuCgogICAgICBUaGUgZG9jdW1lbnQgZG9lcyBub3QgY29udGFpbiBuaXRz LiBUaGVyZSBpcyBvbmx5IGFuIHVudXNlZCByZWZlcmVuY2UgCgkgIHRvIHRoZSBMb1NUIHN5bmNo cm9uaXphdGlvbiBkb2N1bWVudDsgdGhpcyByZWZlcmVuY2Ugd2lsbCBiZSByZW1vdmVkIAoJICBi ZWZvcmUgcHVibGljYXRpb24gb2YgdGhlIGRvY3VtZW50IGFzIGFuIFJGQy4gCgogICAoMS5oKSAg SGFzIHRoZSBkb2N1bWVudCBzcGxpdCBpdHMgcmVmZXJlbmNlcyBpbnRvIG5vcm1hdGl2ZSBhbmQK ICAgICAgICAgIGluZm9ybWF0aXZlPyAgQXJlIHRoZXJlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRv IGRvY3VtZW50cyB0aGF0CiAgICAgICAgICBhcmUgbm90IHJlYWR5IGZvciBhZHZhbmNlbWVudCBv ciBhcmUgb3RoZXJ3aXNlIGluIGFuIHVuY2xlYXIKICAgICAgICAgIHN0YXRlPyAgSWYgc3VjaCBu b3JtYXRpdmUgcmVmZXJlbmNlcyBleGlzdCwgd2hhdCBpcyB0aGUKICAgICAgICAgIHN0cmF0ZWd5 IGZvciB0aGVpciBjb21wbGV0aW9uPyAgQXJlIHRoZXJlIG5vcm1hdGl2ZSByZWZlcmVuY2VzCiAg ICAgICAgICB0aGF0IGFyZSBkb3dud2FyZCByZWZlcmVuY2VzLCBhcyBkZXNjcmliZWQgaW4gW1JG QzM5NjddPyAgSWYKICAgICAgICAgIHNvLCBsaXN0IHRoZXNlIGRvd253YXJkIHJlZmVyZW5jZXMg dG8gc3VwcG9ydCB0aGUgQXJlYQogICAgICAgICAgRGlyZWN0b3IgaW4gdGhlIExhc3QgQ2FsbCBw cm9jZWR1cmUgZm9yIHRoZW0gW1JGQzM5NjddLgoKICAgICBUaGUgZG9jdW1lbnQgaGFzIHJlZmVy ZW5jZXMgc3BsaXQgaW50byBub3JtYXRpdmUgYW5kIAogICAgIGluZm9ybWF0aXZlIHJlZmVyZW5j ZXMuIAogICAgIAogICAoMS5pKSAgSGFzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCB2ZXJpZmllZCB0 aGF0IHRoZSBkb2N1bWVudCdzIElBTkEKICAgICAgICAgIENvbnNpZGVyYXRpb25zIHNlY3Rpb24g ZXhpc3RzIGFuZCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIGJvZHkKICAgICAgICAgIG9mIHRoZSBk b2N1bWVudD8gIElmIHRoZSBkb2N1bWVudCBzcGVjaWZpZXMgcHJvdG9jb2wKICAgICAgICAgIGV4 dGVuc2lvbnMsIGFyZSByZXNlcnZhdGlvbnMgcmVxdWVzdGVkIGluIGFwcHJvcHJpYXRlIElBTkEK ICAgICAgICAgIHJlZ2lzdHJpZXM/ICBBcmUgdGhlIElBTkEgcmVnaXN0cmllcyBjbGVhcmx5IGlk ZW50aWZpZWQ/ICBJZgogICAgICAgICAgdGhlIGRvY3VtZW50IGNyZWF0ZXMgYSBuZXcgcmVnaXN0 cnksIGRvZXMgaXQgZGVmaW5lIHRoZQogICAgICAgICAgcHJvcG9zZWQgaW5pdGlhbCBjb250ZW50 cyBvZiB0aGUgcmVnaXN0cnkgYW5kIGFuIGFsbG9jYXRpb24KICAgICAgICAgIHByb2NlZHVyZSBm b3IgZnV0dXJlIHJlZ2lzdHJhdGlvbnM/ICBEb2VzIGl0IHN1Z2dlc3QgYQogICAgICAgICAgcmVh c29uYWJsZSBuYW1lIGZvciB0aGUgbmV3IHJlZ2lzdHJ5PyAgU2VlIFtSRkMyNDM0XS4gIElmIHRo ZQogICAgICAgICAgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIEV4cGVydCBSZXZpZXcgcHJvY2Vzcywg aGFzIHRoZSBEb2N1bWVudAogICAgICAgICAgU2hlcGhlcmQgY29uZmVycmVkIHdpdGggdGhlIFJl c3BvbnNpYmxlIEFyZWEgRGlyZWN0b3Igc28gdGhhdAogICAgICAgICAgdGhlIElFU0cgY2FuIGFw cG9pbnQgdGhlIG5lZWRlZCBFeHBlcnQgZHVyaW5nIElFU0cgRXZhbHVhdGlvbj8KCiAgIEFuIElB TkEgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGV4aXN0cyBidXQgdGhlcmUgYXJlIG5vdCBhY3Rpb25z IGZvciAKICAgSUFOQSBzaW5jZSB0aGlzIGlzIGEgcmVxdWlyZW1lbnRzIGRvY3VtZW50LiAKICAg CgogICAoMS5qKSAgSGFzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCB2ZXJpZmllZCB0aGF0IHNlY3Rp b25zIG9mIHRoZQogICAgICAgICAgZG9jdW1lbnQgdGhhdCBhcmUgd3JpdHRlbiBpbiBhIGZvcm1h bCBsYW5ndWFnZSwgc3VjaCBhcyBYTUwKICAgICAgICAgIGNvZGUsIEJORiBydWxlcywgTUlCIGRl ZmluaXRpb25zLCBldGMuLCB2YWxpZGF0ZSBjb3JyZWN0bHkgaW4KICAgICAgICAgIGFuIGF1dG9t YXRlZCBjaGVja2VyPwoKICAgVGhlIGRvY3VtZW50IGNvbnRhaW5zIFhNTCBzbmlwcGV0cyB0YWtl biBmcm9tIAogICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRm LWdlb3ByaXYtcGRpZi1sby1wcm9maWxlLTEzLnR4dAogICBYTUwgc25pcHBldHMgZG8gbm90IHZh bGlkYXRlIGJ1dCBoZWxwIHRvIGZvY3VzIG9uIHRoZSByZWxldmFudCBwYXJ0cyAKICAgb2YgYW4g WE1MIGluc3RhbmNlIGRvY3VtZW50LiAgICAKICAgCiAgICgxLmspICBUaGUgSUVTRyBhcHByb3Zh bCBhbm5vdW5jZW1lbnQgaW5jbHVkZXMgYSBEb2N1bWVudAogICAgICAgICAgQW5ub3VuY2VtZW50 IFdyaXRlLVVwLiAgUGxlYXNlIHByb3ZpZGUgc3VjaCBhIERvY3VtZW50CiAgICAgICAgICBBbm5v dW5jZW1lbnQgV3JpdGUtVXAuICBSZWNlbnQgZXhhbXBsZXMgY2FuIGJlIGZvdW5kIGluIHRoZQog ICAgICAgICAgIkFjdGlvbiIgYW5ub3VuY2VtZW50cyBmb3IgYXBwcm92ZWQgZG9jdW1lbnRzLiAK CgpEb2N1bWVudCBBbm5vdW5jZW1lbnQgV3JpdGUtVXAgZm9yICJTcGVjaWZ5aW5nIEhvbGVzIGlu IExvU1QgU2VydmljZSBCb3VuZGFyaWVzIiAKKGRyYWZ0LWlldGYtZWNyaXQtc3BlY2lmeWluZy1o b2xlcy0wMS50eHQpCgogICBUZWNobmljYWwgU3VtbWFyeQoKICAgVGhlIExvU1QgcHJvdG9jb2wg bWFwcyBsb2NhdGlvbiBhbmQgc2VydmljZSBpZGVudGlmaWVycyB0byBVbmlmb3JtCiAgIFJlc291 cmNlIElkZW50aWZpZXJzIChVUklzKS4gTG9TVCBtYXkgYWRkaXRpb25hbGx5IHJldHVybiAKICAg YSBzby1jYWxsZWQgc2VydmljZSBib3VuZGFyeSwgaS5lLiwgYSByZWdpb24gd2l0aGluIHdoaWNo IGFsbCBsb2NhdGlvbnMgCiAgIG1hcCB0byB0aGUgc2FtZSBzZXJ2aWNlIFVSSSBvciBzZXQgb2Yg VVJJcyBmb3IgYSBnaXZlbiBzZXJ2aWNlLgoJICAKICAgVGhlIGdlb2RldGljIGJvdW5kYXJ5IGlz IGEgcG9seWdvbiBtYWRlIHVwIG9mIHNldHMgb2YKICAgZ2VvZGV0aWMgY29vcmRpbmF0ZXMgc3Bl Y2lmeWluZyBhbiBlbmNsb3NlZCBhcmVhLiBJbiBzb21lCiAgIGNpcmN1bXN0YW5jZXMgYW4gYXJl YSBlbmNsb3NlZCBieSBhIHBvbHlnb24sIGFsc28ga25vd24gYXMgYW4KICAgZXh0ZXJpb3IgcG9s eWdvbiwgbWF5IGNvbnRhaW4gZXhjZXB0aW9uIGFyZWFzLCBvciBob2xlcywgdGhhdCBmb3IgdGhl CiAgIHNhbWUgc2VydmljZSBtdXN0IHlpZWxkIGEgZGlmZmVyZW50IGRlc3RpbmF0aW9uIHRvIHRo YXQgZGVzY3JpYmVkIGJ5CiAgIHRoZSBsYXJnZXIgYXJlYS4gIAogICAKICAgVGhpcyBkb2N1bWVu dCBkZXNjcmliZXMgaG93IGhvbGVzIHNob3VsZCBiZSBzcGVjaWZpZWQgaW4gc2VydmljZSBib3Vu ZGFyaWVzIAogICBkZWZpbmVkIHVzaW5nIGEgR01MIGVuY29kaW5nIGZvciB0aGUgcG9seWdvbnMg YW5kIHRoZWlyIGludGVybmFsIGVsZW1lbnRzIChob2xlcykuIAogCgogICBXb3JraW5nIEdyb3Vw IFN1bW1hcnkKCiAgICAgIFRoZXJlIGlzIGNvbnNlbnN1cyBpbiB0aGUgV0cgdG8gcHVibGlzaCB0 aGlzIGRvY3VtZW50LgoKICAgRG9jdW1lbnQgUXVhbGl0eQoKICAgICAgVGhlIGRvY3VtZW50IGhh cyBiZWVuIHJldmlld2VkIGJ5IEVDUklUIHdvcmtpbmcgZ3JvdXAgbWVtYmVycwogICAgICBhbmQg ZmVlZGJhY2sgd2FzIHByb3ZpZGVkIGJ5IENhcmwgUmVlZCBmcm9tIHRoZSBPR0MuCiAgICAgIAog ICBQZXJzb25uZWwKCiAgICAgSGFubmVzIFRzY2hvZmVuaWcgaXMgdGhlIGRvY3VtZW50IHNoZXBo ZXJkIGZvciB0aGlzIGRvY3VtZW50LiAgCgo= ------_=_NextPart_001_01C93A78.B94AA84A Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C93A78.B94AA84A-- From ecrit-bounces@ietf.org Thu Oct 30 04:23:44 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1D93A68A5; Thu, 30 Oct 2008 04:23:44 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F44C3A68A5 for ; Thu, 30 Oct 2008 04:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.283 X-Spam-Level: X-Spam-Status: No, score=-3.283 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gucw6ug2SbeO for ; Thu, 30 Oct 2008 04:23:42 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 6812D3A67D0 for ; Thu, 30 Oct 2008 04:23:41 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9UBIe3T003991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Oct 2008 12:23:36 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9UAemkf021640; Thu, 30 Oct 2008 11:40:52 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 11:40:48 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 11:40:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 12:40:00 +0200 Message-ID: In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B199F92@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] Thread-Index: AcklXM0v3DWcQkerSz+0dKuGXD4ZiQAACaKAAALu2NAEvKLFUACIIz7g References: <385b0c950810030631m10a6e47ehd07dc417700fa528@mail.gmail.com><0913B6CD18F370498CD65864CF254E9006BFCF94@zharhxm1.corp.nortel.com><019801c9256a$cd661430$68323c90$@net> <8C837214C95C864C9F34F3635C2A65750B199F92@SEA-EXCHVS-2.telecomsys.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Roger Marshall" , "ECRIT" X-OriginalArrivalTime: 30 Oct 2008 10:40:44.0865 (UTC) FILETIME=[F68DDB10:01C93A7B] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081030122336-43BC6BB0-DB63046E/0-0/0-0 X-purgate-size: 8980/8319 Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I also believe that we should tackle this work in ECRIT. I do have some comments on the details of the draft. I will provide them in a separate mail. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Roger Marshall >Sent: 27 October, 2008 20:00 >To: ECRIT >Subject: Re: [Ecrit] [Fwd: I-D >Action:draft-patel-ecrit-sos-parameter-00.txt] > >My understanding, based on Milan's 3GPP status at last week's >5th Emergency Services Workshop, is that 3GPP is open to >adopting some IETF solution for call marking, so far has none, >and that the window to finalize solutions for their the >requirements is closing. It seemed that the message at the >workshop was that 3GPP will either use an IETF mechanism - or >create one of their own. > >I think that Brian has captured 4 topics that this draft (and list >discussion) is targeting: >1. Marking emergency call registration >2. Keeping the Route header containing an SOS URN to the end >3. Tagging the UA as an emergency call 4. Marking a call back >for specific call treatment > >Regardless of whether all of these issues are adequately >handled in this early draft (likely not yet), what does seem >to be clear is that 3GPP has additional requirements not >currently met by the existing marking mechanism. > >I would like to see this draft be turned into a working group item. >After that, we can work out the exact approach. I would >encourage others to weigh in on making this a wg item. > >-roger marshall. > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Brian Rosen >> Sent: Friday, October 03, 2008 8:15 AM >> To: 'Milan Patel'; 'John-Luc Bakker'; 'ECRIT' >> Subject: Re: [Ecrit] [Fwd: I-D >> Action:draft-patel-ecrit-sos-parameter-00.txt] >> >> I am still opposed to this mechanism. >> >> There seems to be four threads here: >> 1. Marking an emergency registration >> 2. Keeping the Route header with the sos urn on the call as >far as it >> needs to go 3. Making the UA aware of an emergency call when >it didn't >> recognize that itself 4. Marking a call back >> >> I recognize a need to mark an emergency registration. As >before, I'm >> not convinced this is the best solution, but there is a problem that >> needs to be solved. >> >> I see no reason why the Route header with the sos urn does >not get put >> on the call as soon as it is recognized, and remain on the >call until >> it gets to the last SIP hop (a gateway in the case that is being >> discussed, a PSAP if the call is terminated in PS). Leave the Route >> header on, and use that as the marking. >> >> The UA should recognize the emergency call. If you are planning a >> system where you know it won't, fix that. Having a backup mechanism >> is okay. The way to alert the UA is to redirect the call to >> urn:service:sos. Then the UA knows it's an emergency call. >> >> Call backs have not yet really been addressed well, but >"recognize the >> domain" works. It works for everyone: it works for the gateway, it >> works for a proxy, it works for the UA if the UA knows it was an >> emergency call. >> I will say that I would prefer a more specific marking for a call >> back. I'd prefer to have a comprehensive discussion of call >backs and >> make sure we have all the parts dealt with. I will say this: there >> are two kinds of call backs. One is immediate, when a call is lost, >> or while the call is being handled more information is needed. The >> address used for that is the Contact, not the AoR. The latter is a >> follow up call placed later, and does use AoR (or P-A-I). >The former >> needs marking, the latter doesn't. It may be that we make that the >> URI in Contact is distinguished in some way that lets us know that >> this is a call back of an emergency call. >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Milan Patel >> Sent: Friday, October 03, 2008 9:45 AM >> To: John-Luc Bakker; ECRIT >> Subject: Re: [Ecrit] [Fwd: I-D >> Action:draft-patel-ecrit-sos-parameter-00.txt] >> >> Hi John-Luc, >> >> Currently the draft only specifies that the "sos" parameter only >> conveys information that the request/response is related to an >> emergency session. But I do find your use case valid. >> I'd like to know what others think, but can propose the extension in >> version-01 if there is wider support. >> >> Best regards, >> Milan >> >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of John-Luc Bakker >> Sent: 03 October 2008 14:32 >> To: ECRIT >> Subject: Re: [Ecrit] [Fwd: I-D >> Action:draft-patel-ecrit-sos-parameter-00.txt] >> >> Milan, >> >> The proposed new URI parameter is opaque. It marks the call as an >> emergency call but fails to convey the emergency call type >even if an >> emergency call type could be deduced from the original request. >> Particularly if the Emergency Service URN in the Request-URI is >> replaced by a network entity, as you suggest, not loosing the >> emergency call type information seems useful. In some deployments, >> emergency calls are routed to PSAPs that support the requested >> emergency types. >> >> Kind regards, >> >> John-Luc >> >> On Mon, Sep 15, 2008 at 3:24 AM, Hannes Tschofenig >> wrote: >> > Please take a look at this document. Milan would like to hear some >> comments! >> > >> > Ciao >> > Hannes >> > >> > -------- Original Message -------- >> > Subject: I-D Action:draft-patel-ecrit-sos-parameter-00.txt >> > Date: Fri, 12 Sep 2008 09:45:01 -0700 (PDT) >> > From: Internet-Drafts@ietf.org >> > Reply-To: internet-drafts@ietf.org >> > To: i-d-announce@ietf.org >> > >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > >> > Title : SOS Uniform Resource Identifier (URI) >> parameter for marking of Session Initiation Protocol (SIP) requests >> related to emergency services >> > Author(s) : M. Patel >> > Filename : draft-patel-ecrit-sos-parameter-00.txt >> > Pages : 9 >> > Date : 2008-09-12 >> > >> > This memo describes requirements and protocol conventions >for a new >> > SIP (Session Initiation Protocol) URI parameter intended >> for marking >> > SIP requests and responses related to emergency services. This >> > proposal addresses issues that exist in the current 3rd Generation >> > Partnership Project IP Multimedia Subsystem (IMS) Emergency >> services >> > solution, but is not precluded from being used by other SIP-based >> > emergency services solutions. It is not intended as a >> replacement for >> > the service URN. >> > >> > A URL for this Internet-Draft is: >> > >> http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-para >> meter-00.t >> xt >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > Below is the data which will enable a MIME compliant mail reader >> > implementation to automatically retrieve the ASCII version of the >> > Internet-Draft. >> > >> > >> > _______________________________________________ >> > 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 >> _______________________________________________ >> 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 >> > >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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 30 07:19:35 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCFF93A6816; Thu, 30 Oct 2008 07:19:35 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF84D3A6816 for ; Thu, 30 Oct 2008 07:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4AxqzvRLVPF for ; Thu, 30 Oct 2008 07:19:34 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 02DDB3A67AB for ; Thu, 30 Oct 2008 07:19:33 -0700 (PDT) Received: from [10.71.0.132] (ip-64-139-9-115.dsl.sca.megapath.net [64.139.9.115]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9UEJAQJ014251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Oct 2008 10:19:23 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 30 Oct 2008 10:19:10 -0400 References: <8C0FC05F-5F21-498C-9D50-0EF90AB7A43B@cs.columbia.edu> X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: ECRIT Subject: Re: [Ecrit] Service Classification X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org (A) is fine with me. This might make for the shortest draft ever: The sentence "The policy for adding top-level service labels is Standards Action" is replaced by "The policy for adding top-level service labels is IETF Consensus". Henning On Oct 30, 2008, at 4:36 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > I do see two ways forward: > > A) Issue a RFC 5031bis to change the policy > > B) Submit the two drafts as Standards Track documents. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 31 00:24:48 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A893A6804; Fri, 31 Oct 2008 00:24:48 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71D273A6857 for ; Fri, 31 Oct 2008 00:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.258 X-Spam-Level: X-Spam-Status: No, score=-5.258 tagged_above=-999 required=5 tests=[AWL=1.341, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cB1hkAAoLxtL for ; Fri, 31 Oct 2008 00:24:45 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 58D623A67FD for ; Fri, 31 Oct 2008 00:24:45 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9V7OZ0h009420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 31 Oct 2008 08:24:35 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9V7OX8q017997; Fri, 31 Oct 2008 08:24:35 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Oct 2008 08:24:28 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Oct 2008 08:24:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 31 Oct 2008 09:24:26 +0200 Message-ID: In-Reply-To: <200810301538.m9UFcU36016213@demumfd002.nsn-inter.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-mapping-arch: Discuss by Russ Thread-Index: Ack6pZGqNnJfCtk3Qze7jPeCJt2dnAAhCEiA References: <01E42119-7212-4622-8ED8-0592FCB91674@cs.columbia.edu> <200810301538.m9UFcU36016213@demumfd002.nsn-inter.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Russ Housley" X-OriginalArrivalTime: 31 Oct 2008 07:24:27.0604 (UTC) FILETIME=[B52C3140:01C93B29] Cc: ECRIT Subject: Re: [Ecrit] draft-ietf-ecrit-mapping-arch: Discuss by Russ X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thanks. >-----Original Message----- >From: ext Russ Housley [mailto:housley@vigilsec.com] >Sent: 30 October, 2008 17:21 >To: Tschofenig, Hannes (NSN - FI/Espoo) >Cc: ECRIT; ext Henning Schulzrinne >Subject: RE: [Ecrit] draft-ietf-ecrit-mapping-arch: Discuss by Russ > >I cleared my DISCUSS on 2008-02-21. I'm quite confused by this query? > >Russ > > >At 04:49 AM 10/30/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>Hi Russ, >> >>I wonder whether you had a strong opinion about your DISCUSS. >We would >>like to stay with the document type of informational rather than >>switching to experimental. >> >>While many of us in the group do not have a strong opinion about the >>document type (information vs. experimental) the chairs believe that >>labeling a document as experimental in this space of >emergency services >>might give the audience from other organizations that are not so >>familiar with the details of the IETF process a very different >>perception, namely one that this stuff is by no means ready for >>deployment. >> >>Ciao >>Hannes >> >> >Can the WG chairs please convey this to the AD/Russ >HousleyI suspect >> >their opinion carries more weight than the author's... >> > >> >On Oct 12, 2008, at 7:12 AM, Tschofenig, Hannes (NSN - >FI/Espoo) wrote: >> > >> >> >> >>https://datatracker.ietf.org/idtracker/draft-ietf-ecrit-mapping-arch/ >> >c >> >> om >> >> ment/78013/ >> >> >> >> ----------------- >> >> >> >> Commented by: Russ Housley >> >> Comment: >> >> Looking at http://www.ietf.org/u/ietfchair/info-exp.html >> >> (especially Guideline 3), I wonder why this is not Experimental. >> >> >> >> ----------------- >> >> >> >> When reading that document then the document status should be >> >> experimental. When considering how people would typically >> >perceive an >> >> experimental document then it should be informal. I fear that >> >> nobody knows nor has ever read the above-mentioned document. >> >> >> >> I suggest to leave it informational. >> >> _______________________________________________ >> >> 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