From ecrit-bounces@ietf.org Thu Jan 1 14:26:46 2009 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 279DE3A683D; Thu, 1 Jan 2009 14:26:46 -0800 (PST) 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 030623A68C5 for ; Thu, 1 Jan 2009 14:26:45 -0800 (PST) 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 E6FUQs1h3GO3 for ; Thu, 1 Jan 2009 14:26:43 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.113]) by core3.amsl.com (Postfix) with ESMTP id 0336F3A67DA for ; Thu, 1 Jan 2009 14:26:42 -0800 (PST) Received: (qmail 16461 invoked from network); 1 Jan 2009 22:26:36 -0000 Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 1 Jan 2009 22:26:36 -0000 Received: (qmail 79587 invoked from network); 1 Jan 2009 22:26:27 -0000 Received: from h16n1fls34o265.telia.com (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[213.64.232.16]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with SMTP for ; 1 Jan 2009 22:26:27 -0000 From: "Gunnar Hellstrom" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: Date: Thu, 1 Jan 2009 23:26:39 +0100 Message-ID: <002401c96c60$03e158d0$211ea8c0@GunnarH> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclrMYhWX5h2YhMUQG6w52bdJHGgeAAuiNaw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Subject: Re: [Ecrit] PSAP Call Backs 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, I get a bit nervous when I read SP-36, and compare it with what is desired for users of relay services. USA has just put regulations and technology in place for calling via relay services to emergency services. The number that accompanies the call is intended to be usable for call-back. The call-back MUST be taken through a relay service, because the user need to use sign language or real-time text. In Sweden, we have made plans and brief trials for a system with similar goals as the one in USA, and Europe is on the same way. The relay service is invoked in a call to the end user's number by a routing evaluation that takes the call through a service instead of directly to the user. It is done in one way in USA, but there are other optional ways to do the same thing that seem to collide with the wording of som of the requirements here. The current wording of SP-36 can give the impression that that kind of routing would not be allowed for the call-back. "SP-36 Call backs to the Contact: header URI recieved within 30 minutes of an emergency call must reach the device regardless of call features or services that would normally cause the call to be routed to some other entity." I see similar risks in interpretation of this requirement, where I have picked out the dangerous requirements: "13. Disabling of features ED-70/SP-39 User Agents and proxies MUST disable outgoing call features such as -- o Call Transfer o Three Way Call -- when an emergency call is established. Also see ED-77 in Section 14. ED-71/SP-40 The emergency dial strings SHOULD NOT be permitted in Call Forward numbers or speed dial lists. ED-72/SP-41 The User Agent and Proxies SHOULD disable the following incoming call features on call backs from the PSAP: -- o Call Forward (all kinds)" -- These operations may be essential for bringing in relay services and other kind of supporting services in the call. I have raised this question before and got an answer that was meant to take my fears away, referring to that this has always been so in PSTN. I am still afraid that we make a lot of good supporting actions impossible by these statements and would like to see them deleted. Regarding SP-36, I suggest rewording to: "SP-36 Call backs to the Contact: header URI recieved within 30 minutes of an emergency call must include call features or services that would normally be included in calls routed to the device." ---- And 39 - 40 - 41 to: SP-39 User Agents and proxies MUST disable outgoing call features such as o Call Waiting o Flash hold o Outbound Call Blocking when an emergency call is established. Also see ED-77 in Section 14. SP-41 The User Agent and Proxies SHOULD disable the following incoming call features on call backs from the PSAP: o Call Waiting o Do Not Disturb I understand that there is a conflict between some traditions in this area, and the new need for invoking supporting services, and look forward to a discussion on what we lose and gain by the changes I propose. Gunnar -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Wednesday, December 31, 2008 11:21 AM To: ECRIT Subject: [Ecrit] PSAP Call Backs Hi all, In the last few months we have seen increased interest in the topic of PSAP call backs. Section 10 of http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-06 says: SP-36 Call backs to the Contact: header URI recieved within 30 minutes of an emergency call must reach the device regardless of call features or services that would normally cause the call to be routed to some other entity. More importantly, Section 13 says: ED-73 Call backs SHOULD be determined by retaining the domain of the PSAP which answers an outgoing emergency call and instantiating a timer which starts when the call is terminated. If a call is received from the same domain and within the timer period, sent to the Contact: or AoR used in the emergency call, it should be assumed to be a call back. The suggested timer period is 5 minutes. http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt proposed another solution based on marking the callback using the "sos" URI parameter. http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-local-emergency-rph-name space/ proposes another solution by utilizing the Resource Priority Header. So, here are my high-level questions: A) Do you think that you understand the requirements that lead to a need for a technical solution? B) Do you believe that more work beyond the mechanism described in Phone BCP is needed? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit __________ NOD32 3724 (20081230) 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 Fri Jan 2 11:54:57 2009 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 8D0B63A67DB; Fri, 2 Jan 2009 11:54:57 -0800 (PST) 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 F1BFB3A67DB for ; Fri, 2 Jan 2009 11:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 Z6Hpoh31avre for ; Fri, 2 Jan 2009 11:54:54 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8D5A23A67A1 for ; Fri, 2 Jan 2009 11:54:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,319,1228089600"; d="scan'208";a="222938033" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Jan 2009 19:54:44 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n02JsgVj014267; Fri, 2 Jan 2009 11:54:42 -0800 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 n02JsgX1024164; Fri, 2 Jan 2009 19:54:42 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); Fri, 2 Jan 2009 11:54:42 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.21.200]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jan 2009 11:54:41 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 02 Jan 2009 13:54:40 -0600 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "Hannes Tschofenig" , "ECRIT" From: "James M. Polk" In-Reply-To: References: <00e701c96ad9$d4af1020$0201a8c0@nsnintra.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 02 Jan 2009 19:54:41.0747 (UTC) FILETIME=[F3B79230:01C96D13] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9009; t=1230926082; x=1231790082; c=relaxed/simple; s=sjdkim2002; 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=20Status=20Update=20-=2 0December=202008=20(esnet=20=0A=20=20namespace) |Sender:=20; bh=3Ta2Z9ebD792Xee2njDvCNFwzj0uM4gE34plrtAlyG0=; b=MScbUnpQwB9CUykUaZF0FTMCUkT69Gydj/PwvFVLqwLPl4zsVNO0EemVF4 kxSYSWNDEDWlDDUC1Hn1ntq6CjgbdWknOj/hUnrjOc9rOj37AM1NAv2/UwWV VVDF8hGwnQ; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Ecrit] ECRIT Status Update - December 2008 (esnet namespace) 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 03:39 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >Hi James, > > >At 05:53 PM 12/30/2008, Hannes Tschofenig wrote: > >>8) draft-ietf-ecrit-local-emergency-rph-namespace > >> > >>We had some discussions about this document triggered by mails around > >>IETF#73 asking for the purpose and the scope. > >>I read through the e-mail exchange but I need to read through some > >>RFCs/drafts as well in order to summarize the topic. > >> > >>A few folks have provided feedback (James, Brian, Janet, Keith) but > >>more reviews from the rest of the group would be useful. > >> > >>Action item: Hannes to summarize the discussions and to draw > >a conclusion. > > > >Hannes - why are you artificially creating such a high hurdle > >for this ID to progress? > >Summarizing a discussion is not "a high hurdle". if you only said you would summarize this, then I wouldn't be writing anything here. You also include this comment above "...but more reviews from the rest of the group would be useful..." when did 6 or 7 reviewers saying one thing (in the positive) and 1 saying another thing (in the "I don't understand") mean anything other than _rough_consensus_? What we are hearing you say is "until I (Hannes) understand and agree with this, this ID will not progress". Jon admitted on the mic in Minn that he's "not the biggest fan of RP"... which is widely known, yet he decided to say into the mc in Minn that he is not going to fight this effort either. SIP has one defined way to mark the priority of a request - and that's in RFC 4412 (Resource-Priority). You have said a number of times that the To: field can be used, that the R-URI value can be used... claiming that using the RP header would add another meant of marking the priority of a request. Yet the SIP WG chair has confirmed to you in front of several others (including me, Brian, Marc (your co-chair)) that SIP has one, singular way to priority mark its requests - and that is defined by RFC 4412 (Resource-Priority). Anything else, (i.e., any other way of marking the priority of a SIP request) would in fact be an additional way SIP entities would have to be coded to perform this function. You have repeatedly refused to acknowledge that fact. I believe that is at least most of why you are resisting this ID from becoming a WG item, and are continuing to find manufactured faults with it. You are standing alone in your views, my friend - which is contrary to IETF procedures of rough consensus, and I ask that you agree with the core philosophy of the IETF that rough consensus makes decisions in the IETF, and move on. > > > >The WG hummed for this ID to become a WG item in Dublin. > >I know. Like the group did with a number of other items. >Officially, the document is not a WG item yet given that we would >require the charter to change as mentioned at the last meeting. Yeah, and that recharter - for whatever reason, didn't happen in the last 5 months since the Dublin meeting why? How long before the WG can expect this recharter? (a year?) > > > >There hasn't been one other opinion contrary to this (save for > >yours) on the list or at the Minneapolis meeting. > >Well. I raised several issues which I would like to summarize. you raised many issues, nearly all of which had the answer "this is not how SIP works", but you didn't seem to like that answer. >To pick one "PSAP callback" where there does not seem to be agreement, >referencing Brian: >http://www.ietf.org/mail-archive/web/ecrit/current/msg05686.html "PSAP Callback" - hmmmmmm..... let's see.... You have a requirement that "priority" needs to be e2e in one direction but not the other? Where's that written down? Do you believe there's a chance in heck that all SIP UAs will have the code in them to process the priority of this PSAP Callback? Funny, that's the same argument that you gave me that (paraphrasing) "because most UAs will not have RFC 4412 code in them, why are you (James) pushing this solution on ECRIT?" the sword cuts both ways. This ID doesn't have the UAC needing to set the RP within the INVITE. Nor does it prioritize the RP in the received INVITE either. Therefore PSAP Callback is pointless at this point in time for UAs at all, right? It's more for the ESNET and perhaps one admin domain out from that network. Look at figure 1 of this ID, and tell me where (i.e., which element(s) in which domain(s)) PSAP Callback is mandatory to set the priority of that Callback INVITE? > > Therefore, > >it is impossible to conclude with evidence that anyone other > >than you are delaying this progression. > >Delaying? Given that we have to change the charter first hmmm.... again... that decision was made 2 meetings ago. How much longer should the WG have to wait for this recharter? >before this >document can actually be picked up as an item (like the other documents >as well) I am not delaying anything here. ok, so who is writing the recharter (if not the WG chair) and why are they taking so long? Let me know who this other person is and I'll ask them to inform the WG themselves (directly) with the ETA on this. >Getting the new charter approved is only possible if we are able to >finish our main items, as Jon says. Despite our pushing Phone BCP and >Framework are still not finished. yet, I can't help but notice that both http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-location-hiding-req/ and http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-specifying-holes/ are recent additions to the ECRIT charter... indeed, these two IDs weren't event though about when phoneBCP and Framework were WGLCd the first time, yet they made the charter within a few months from their hum by the WG... this is inconsistent with the stance you are taking now with the esnet namespace ID, Hannes. > > > >Many have expressed in email to the list, and in person at > >Minneapolis to you that you are not understanding the topic as > >much as you believe (SIP signaling and SIP header usage, and > >this includes the SIP chair that has given you his opinion in > >front of others), and each of the rest of us (that have voiced > >an opinion) are in unison in our understanding (and have > >attempted nearly countless times to explain how you have a > >misunderstanding of SIP communications). > >Maybe I don't understand this particular item well enough. If I don't >understand it given that I am working in this space already for many >years gives me the impression that maybe I am not the only one. So, bluntly, how much do you understand about SIP signaling and headers? This is the question. WG chairs do not need to understand everything within their WG perfectly, but need to trust a select few that do understand the topics you don't. Is Keith, the SIP WG chair, not a good enough person to trust in this instance? And from the point of view of "...maybe I am not the only one..." isn't it also the burden of those that do not understand something to voice their opinions at the meeting mic or on the mailing list (else they are to be considered in agreement with a proposal)? I believe this is another IETF procedure you are not adhering to on this case. >At least >in the past I was never wrong with such an assumption. Unless there is another who says so on the public list, you have no proof this is the case here. >I don't think it can be wrong to ask questions about documents we have >in the group (even if they appear irrelevant to the authors of the >mechanism as he knows it better than anybody else). Hannes, many individuals answered your questions as "you're wrong" or "you're not understanding SIP signaling" during the threads during the Minn IETF meeting. If everyone who has responded to you is saying "you're not right in this opinion", what does it take for you to consider the possibility *each* of them is right, and you are not? > > >Furthermore - your co-chair does not agree with you, and > >believes as others do that this ID is needed, necessary and > >wants it to progress > >- including other SDOs and organizations (NENA for one) that > >want to reference this document as an RFC. > >I am actually participating in various NENA conf. calls and have >participated in discussions around resource priority for >citizen-to-authority emergency calls. I have not heard you on those >calls. not being an active participant does not mean I don't understand the issues. Besides, I trust Brian Rosen here, the NENA WG chair (since the WG formed), who is one of the ones telling you that you don't understand what you are saying wrt RP esnet namespace ID. >In short, I am not delaying -- I am trying to understand. No reason to >worry. > >Ciao >Hannes > > > > >James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 2 12:07:02 2009 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 A2A7628C11F; Fri, 2 Jan 2009 12:07:02 -0800 (PST) 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 5110728C11F for ; Fri, 2 Jan 2009 12:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[AWL=-0.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 nx9xK0cgf2HN for ; Fri, 2 Jan 2009 12:07:00 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3995728C110 for ; Fri, 2 Jan 2009 12:07:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,319,1228089600"; d="scan'208";a="124418011" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 02 Jan 2009 20:06:48 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n02K6mV4032258; Fri, 2 Jan 2009 12:06:48 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n02K6mlU015886; Fri, 2 Jan 2009 20:06:48 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jan 2009 12:06:48 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.21.200]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jan 2009 12:06:47 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 02 Jan 2009 14:06:46 -0600 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ECRIT" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 02 Jan 2009 20:06:47.0745 (UTC) FILETIME=[A4721310:01C96D15] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5800; t=1230926808; x=1231790808; 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]=20ECRIT=20WG=20RECHARTER=20(Pro posal=20Version=201) |Sender:=20; bh=oVLi9ygzomwDWYHiPKzOfT1qm7iMWOpheVPKsiy/Q3Y=; b=hvcg3Ivqepda/iHtPW/39T4tGG4kdhYhTrXMebethYOTRzzRx7RB61irZv iyCY+IaNjNPtTLmtFa8J0pvxJOPRFhRKmJlIe7P1jg+f3pxePHBGd8ShIpHy 6La9dgJY1V; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Ecrit] ECRIT WG RECHARTER (Proposal Version 1) 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 05:00 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >Here is a proposal for ECRIT rechartering. > >Please let me know if you disagree with something or if something is >missing > >Note that I was not quite sure whether it would be necessary to actually >include the following two items in the charter at all after the change >to the Service URN RFC has been made: >* draft-forte-ecrit-service-classification >* draft-sun-ecrit-shelter-service IMO, these are just new milestones - and don't need to be added to the text of the charter >I believe they could be sent directly to the RFC editor and then the >review would be done by the ECRIT working group. >Please provide me feedback on this issue. > >Ciao >Hannes > >---------------- > >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. >Explicitly outside the scope of this group is the question of >pre-emption or prioritization of emergency services traffic. 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. > >The group will maintain and extend the Location to Service Translation >(LoST) protocol for emergency services related aspects but also for >usage outside the emergency services context. Additionally, the group >is chartered to work on descriptions and extensions regarding >citizen-to- >authority services (such as defining a Resource Priority header for >usage with emergency services). thanks for including this text >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. > >This working group cares about privacy and security concerns, and will >address them within its documents. > >Goals and Milestones: > >Done Submit "Requirements for Emergency Context Resolution with >Internet Technologies" to the IESG for consideration as an Informational >RFC >Done Submit "Security Threats and Requirements for Emergency Call >Marking and Mapping" to the IESG for consideration as an Informational >RFC >Done Submit "A Uniform Resource Name (URN) for Emergency and Other >Well-Known Services" to the IESG for consideration as a Standards Track >RFC >Done Submit "LoST: A Location-to-Service Translation Protocol" to >the IESG for consideration as a Standards Track RFC >Done Submit "Discovering LoST Servers Using DHCP" to the IESG for >consideration as Informational RFC >Done Submit "Location-to-URL Mapping Architecture and Framework" to >the IESG for consideration as an Informational RFC >Done Submit "Location Hiding: Problem Statement and Requirements" to >the IESG for consideration as an Informational RFC >Done Submit "Specifying Holes in LoST Service Boundaries" to the >IESG for consideration as a BCP RFC >Feb 2009 Submit "Synchronizing Location-to-Service Translation (LoST) >Servers" to the IESG for consideration as a Standards Track RFC >Feb 2009 Submit "Best Current Practice for Communications Services in >support of Emergency Calling" to the IESG for consideration as a BCP RFC >Feb 2009 Submit "Framework for Emergency Calling using Internet >Multimedia" to the IESG for consideration as a Standards Track RFC >Mar 2009 Submit "IANA Registering a SIP RPH Namespace for Local >Emergency Communications" to the IESG for consideration as a Standards >Track RFC >Mar 2009 Submit "RFC 5031bis" to the IESG for consideration as a >Standards Track RFC >Apr 2009 Submit "Using Imprecise Location for Emergency Context >Resolution" to the IESG for consideration as an Informational RFC >May 2009 Submit "Location-to-Service Translation Protocol (LoST) >Extensions" to the IESG for consideration as an Informational RFC >May 2009 Submit "LoST Classification of Location-based Services" to the >IESG for consideration as an Experimental RFC >May 2009 Submit "LoST Usage for discovering Shelter Services" to the >IESG for consideration as an Experimental RFC >_______________________________________________ >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 Jan 2 12:15:30 2009 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 586D83A6A25; Fri, 2 Jan 2009 12:15:30 -0800 (PST) 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 807913A6A25 for ; Fri, 2 Jan 2009 12:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.932 X-Spam-Level: X-Spam-Status: No, score=-6.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 WqpNRWinKm3n for ; Fri, 2 Jan 2009 12:15:28 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A902E3A6A20 for ; Fri, 2 Jan 2009 12:15:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,319,1228089600"; d="scan'208";a="222945846" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 02 Jan 2009 20:15:16 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n02KFGhD005648; Fri, 2 Jan 2009 12:15:16 -0800 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 n02KFG7m002866; Fri, 2 Jan 2009 20:15:16 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jan 2009 12:15:16 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.21.200]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jan 2009 12:15:16 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 02 Jan 2009 14:15:15 -0600 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ECRIT" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 02 Jan 2009 20:15:16.0195 (UTC) FILETIME=[D3816330:01C96D16] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2570; t=1230927316; x=1231791316; 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]=20PSAP=20Call=20Backs |Sender:=20; bh=stSsDM7H736yoeU9B5yYwwwoPxEMwA9KBrQXlz2ukoY=; b=EPOPo4kc9Lrh+o14EII1Cvi1DWJ6mXmrQKsHTOszuAx7DlqYr1F5HGCQzA o5sTPUXaP1dTJucxzeo3GfIgHQvS23Rs9TrPheK2x23fPRx0AG2B9d+phwgA vaUBYLfidE; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Ecrit] PSAP Call Backs 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 04:21 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >Hi all, > >In the last few months we have seen increased interest in the topic of >PSAP call backs. > >Section 10 of http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-06 >says: > > SP-36 Call backs to the Contact: header URI recieved within 30 > minutes of an emergency call must reach the device regardless of call > features or services that would normally cause the call to be routed > to some other entity. > >More importantly, Section 13 says: > > ED-73 Call backs SHOULD be determined by retaining the domain of the > PSAP which answers an outgoing emergency call and instantiating a > timer which starts when the call is terminated. If a call is > received from the same domain and within the timer period, sent to > the Contact: or AoR used in the emergency call, it should be assumed > to be a call back. The suggested timer period is 5 minutes. > >http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt proposed >another solution based on marking the callback using the "sos" URI >parameter. > >http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-local-emergency-rph-name >space/ proposes another solution by utilizing the Resource Priority >Header. within the namespace ID, the total thought (for PSAP callback) is here: This namespace will also be used for communications between emergency authorities, and MAY be used for emergency authorities calling public citizens. An example of the later is a PSAP operator calling back someone who previously called 9111/112/999 and the communication was terminated before it should have been (in the operator's judgment). Notice this is all based on the MAY in the first sentence, therefore it can be considered an afterthought, i.e., something that can be utilized/specified later. the "sos" parameter solution is more definitive, yet it should identify a priority marking (in SIP), given that there is already a defined way to do that in SIP, and a second way shouldn't be defined - as it will only lead to interoperability issues. >So, here are my high-level questions: > >A) Do you think that you understand the requirements that lead to a need >for a technical solution? > >B) Do you believe that more work beyond the mechanism described in Phone >BCP is needed? > >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 Sat Jan 3 06:15:27 2009 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 778D53A68AA; Sat, 3 Jan 2009 06:15:27 -0800 (PST) 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 5E2143A6894 for ; Sat, 3 Jan 2009 06:15:26 -0800 (PST) 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 eHqFfYV8oytB for ; Sat, 3 Jan 2009 06:15:22 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 626733A67AD for ; Sat, 3 Jan 2009 06:15:22 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LJ7HH-0001Eb-RU; Sat, 03 Jan 2009 08:15:00 -0600 From: "Brian Rosen" To: "'James M. Polk'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: In-Reply-To: Date: Sat, 3 Jan 2009 09:15:01 -0500 Message-ID: <020301c96dad$ac9b52c0$05d1f840$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcltFtBoAR/rs731RPegjSFg+aEm3QAlaXxA 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] PSAP Call Backs 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 Couple of thoughts here: In the past several months, I have been involved with a couple of instances where call backs turned out to be very difficult because they are not marked (in the PSTN). Gunnar cited one: A relay provider handles an emergency call. The PSAP calls the deaf caller back. Relay providers often have a queue of calls waiting for an available interpreter. US regulation now (as of last week) says emergency calls and call backs should get priority on the queue. How does the relay provider know that an incoming call is a call back? Another one is a telephony service with incoming call restrictions. An example is a phone for a child where the parent controls who can call the child. The child makes an emergency call. A callback is needed. The call restrictions would bar the call unless it was known that it was an emergency call. Besides marking, there needs to be some other phonebcp-like text. For example, a callback should not normally be diverted (call forwarding). T may (needs some discussion) need to get through if do not disturb is enabled (for example, inadvertently). As with incoming calls, some minimum standards are needed on the signaling. I also want to point out that resource priority marking is NOT a good choice for an overall callback mark, the same way that the Route header sos urn is not a good choice for a resource priority mark. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: Friday, January 02, 2009 3:15 PM To: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT Subject: Re: [Ecrit] PSAP Call Backs At 04:21 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >Hi all, > >In the last few months we have seen increased interest in the topic of >PSAP call backs. > >Section 10 of http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-06 >says: > > SP-36 Call backs to the Contact: header URI recieved within 30 > minutes of an emergency call must reach the device regardless of call > features or services that would normally cause the call to be routed > to some other entity. > >More importantly, Section 13 says: > > ED-73 Call backs SHOULD be determined by retaining the domain of the > PSAP which answers an outgoing emergency call and instantiating a > timer which starts when the call is terminated. If a call is > received from the same domain and within the timer period, sent to > the Contact: or AoR used in the emergency call, it should be assumed > to be a call back. The suggested timer period is 5 minutes. > >http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt proposed >another solution based on marking the callback using the "sos" URI >parameter. > >http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-local-emergency-rph-name >space/ proposes another solution by utilizing the Resource Priority >Header. within the namespace ID, the total thought (for PSAP callback) is here: This namespace will also be used for communications between emergency authorities, and MAY be used for emergency authorities calling public citizens. An example of the later is a PSAP operator calling back someone who previously called 9111/112/999 and the communication was terminated before it should have been (in the operator's judgment). Notice this is all based on the MAY in the first sentence, therefore it can be considered an afterthought, i.e., something that can be utilized/specified later. the "sos" parameter solution is more definitive, yet it should identify a priority marking (in SIP), given that there is already a defined way to do that in SIP, and a second way shouldn't be defined - as it will only lead to interoperability issues. >So, here are my high-level questions: > >A) Do you think that you understand the requirements that lead to a need >for a technical solution? > >B) Do you believe that more work beyond the mechanism described in Phone >BCP is needed? > >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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 3 06:18:04 2009 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 A75693A68AA; Sat, 3 Jan 2009 06:18:04 -0800 (PST) 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 B83813A68AA for ; Sat, 3 Jan 2009 06:18:03 -0800 (PST) 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, 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 Ig073RGQjY4v for ; Sat, 3 Jan 2009 06:18:03 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 10C493A67AD for ; Sat, 3 Jan 2009 06:18:03 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LJ7Jv-0001OP-Mi; Sat, 03 Jan 2009 08:17:43 -0600 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: In-Reply-To: Date: Sat, 3 Jan 2009 09:17:45 -0500 Message-ID: <020401c96dae$0e479880$2ad6c980$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclrLVAIpzZ7YixAQam2k1f6APiSoQCgGc2g 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] HUM regarding draft-rosen-ecrit-premature-disconnect-rqmts 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 Just a note that I was requested to issue an update to this document which recasts the requirement in human observation/response language, completely avoiding any signaling wording. I have a draft which has been reviewed by NENA. They like the current version a lot more than the new one, but the new one does capture the essence of the problem. I will publish it to the IETF today. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Wednesday, December 31, 2008 4:51 AM To: ECRIT Subject: [Ecrit] HUM regarding draft-rosen-ecrit-premature-disconnect-rqmts Hi all, We had a fair amount of discussions regarding this item and, as mentioned in my status update, we would like to resolve the deadlock we currently have. We would like to get some feedback from the group. Are you OK with turning draft-rosen-ecrit-premature-disconnect-rqmts into a working group item (after rechartering) (under the assumption that the editor of the document is changed once the document is a WG item)? Deadline: 19. Jan. 2009 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 Sat Jan 3 09:48:25 2009 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 7A9393A6AAB; Sat, 3 Jan 2009 09:48:25 -0800 (PST) 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 6D1503A6AAB for ; Sat, 3 Jan 2009 09:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=0.271, 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 r+VgaFRLRKTO for ; Sat, 3 Jan 2009 09:48:23 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4B2E43A6AAA for ; Sat, 3 Jan 2009 09:48:23 -0800 (PST) Received: (qmail invoked by alias); 03 Jan 2009 17:48:09 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp058) with SMTP; 03 Jan 2009 18:48:09 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+oTpIsTBGowoG2gh5cpa+blldKG3HSvy6r2eIfYk QzJ9kf/qiRZmXy From: "Hannes Tschofenig" To: "'Brian Rosen'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'ECRIT'" References: <020401c96dae$0e479880$2ad6c980$@net> Date: Sat, 3 Jan 2009 19:48:35 +0200 Message-ID: <007401c96dcb$81a2f960$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclrLVAIpzZ7YixAQam2k1f6APiSoQCgGc2gAAduzoA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <020401c96dae$0e479880$2ad6c980$@net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Subject: Re: [Ecrit] HUM regardingdraft-rosen-ecrit-premature-disconnect-rqmts 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 is good news. Thanks, Brian. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Brian Rosen >Sent: 03 January, 2009 16:18 >To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >Subject: Re: [Ecrit] HUM >regardingdraft-rosen-ecrit-premature-disconnect-rqmts > >Just a note that I was requested to issue an update to this >document which recasts the requirement in human >observation/response language, completely avoiding any >signaling wording. I have a draft which has been reviewed by >NENA. They like the current version a lot more than the new >one, but the new one does capture the essence of the problem. >I will publish it to the IETF today. > >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >Sent: Wednesday, December 31, 2008 4:51 AM >To: ECRIT >Subject: [Ecrit] HUM regarding >draft-rosen-ecrit-premature-disconnect-rqmts > >Hi all, > >We had a fair amount of discussions regarding this item and, >as mentioned in my status update, we would like to resolve the >deadlock we currently have. > >We would like to get some feedback from the group. > >Are you OK with turning draft-rosen-ecrit-premature-disconnect-rqmts >into a working group item (after rechartering) (under the >assumption that the editor of the document is changed once the >document is a WG item)? > >Deadline: 19. Jan. 2009 > >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 Sat Jan 3 10:28:31 2009 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 707C83A679F; Sat, 3 Jan 2009 10:28:31 -0800 (PST) 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 7A6D73A679F for ; Sat, 3 Jan 2009 10:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.072 X-Spam-Level: X-Spam-Status: No, score=-1.072 tagged_above=-999 required=5 tests=[AWL=-0.773, 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 9BSjYAe1FTB5 for ; Sat, 3 Jan 2009 10:28:29 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id F29ED3A63EC for ; Sat, 3 Jan 2009 10:28:28 -0800 (PST) Received: (qmail invoked by alias); 03 Jan 2009 18:28:15 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp021) with SMTP; 03 Jan 2009 19:28:15 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19jKOMIap5jYDaczv9nso+/iTZbxxaY3tEQc8w++A ajC6RGYRX6Gk/W From: "Hannes Tschofenig" To: "'James M. Polk'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'ECRIT'" References: Date: Sat, 3 Jan 2009 20:28:41 +0200 Message-ID: <007501c96dd1$1b5ecd40$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcltFtXFMn8qyHKdSCO7B7iBHlGTAAAuajmw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Subject: Re: [Ecrit] PSAP Call Backs 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 two different aspects: A) A decision that decides whether a call back has to be marked or not B) When the decision is made that is has to be marked then how the marking is going to look like. Regarding (A): This might be a policy issues. Some PSAPs might want to use this indication and others might not. Nothing we have to worry about. Regarding (B): Here there needs to be one way todo the marking -- not multiple ways. It would just increase the implementation complexity, the number of error cases and interop problems. I am not sure to what your "MAY" statement refers to -- to (A) or (B). Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of James M. Polk >Sent: 02 January, 2009 22:15 >To: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >Subject: Re: [Ecrit] PSAP Call Backs > >At 04:21 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>Hi all, >> >>In the last few months we have seen increased interest in the >topic of >>PSAP call backs. >> >>Section 10 of http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-06 >>says: >> >> SP-36 Call backs to the Contact: header URI recieved within 30 >> minutes of an emergency call must reach the device >regardless of call >> features or services that would normally cause the call >to be routed >> to some other entity. >> >>More importantly, Section 13 says: >> >> ED-73 Call backs SHOULD be determined by retaining the >domain of the >> PSAP which answers an outgoing emergency call and instantiating a >> timer which starts when the call is terminated. If a call is >> received from the same domain and within the timer period, sent to >> the Contact: or AoR used in the emergency call, it should >be assumed >> to be a call back. The suggested timer period is 5 minutes. >> >>http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt >>proposed another solution based on marking the callback using >the "sos" >>URI parameter. >> >>http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-local-emergenc >y-rph-nam >>e space/ proposes another solution by utilizing the Resource Priority >>Header. > >within the namespace ID, the total thought (for PSAP callback) is here: > > This namespace will also be used > for communications between emergency authorities, and MAY be used > for emergency authorities calling public citizens. An example of > the later is a PSAP operator calling back someone who previously > called 9111/112/999 and the communication was terminated before it > should have been (in the operator's judgment). > >Notice this is all based on the MAY in the first sentence, >therefore it can be considered an afterthought, i.e., >something that can be utilized/specified later. > >the "sos" parameter solution is more definitive, yet it should >identify a priority marking (in SIP), given that there is >already a defined way to do that in SIP, and a second way >shouldn't be defined >- as it will only lead to interoperability issues. > > >>So, here are my high-level questions: >> >>A) Do you think that you understand the requirements that lead to a >>need for a technical solution? >> >>B) Do you believe that more work beyond the mechanism described in >>Phone BCP is needed? >> >>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 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 3 14:42:31 2009 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 BE91C3A6824; Sat, 3 Jan 2009 14:42:31 -0800 (PST) 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 D763C3A6824 for ; Sat, 3 Jan 2009 14:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.397, 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 LKI+Q6t55Kyx for ; Sat, 3 Jan 2009 14:42:29 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 03EE93A63EC for ; Sat, 3 Jan 2009 14:42:28 -0800 (PST) Received: (qmail invoked by alias); 03 Jan 2009 22:42:15 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp008) with SMTP; 03 Jan 2009 23:42:15 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+tCbNfkpWtnQXyEXmpYpOhmgebO2FhT3UtxrZMlZ s6FN/7c4oNfxDn From: "Hannes Tschofenig" To: "'James M. Polk'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'ECRIT'" References: <00e701c96ad9$d4af1020$0201a8c0@nsnintra.net> Date: Sun, 4 Jan 2009 00:42:41 +0200 Message-ID: <007d01c96df4$96f5aaa0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcltE/UPUUulwco3T7mRuTzgwGYAUQAzVduw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Subject: Re: [Ecrit] ECRIT Status Update - December 2008 (esnet namespace) 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, I understand that you are quite excited about your work and that you want to progress it as fast as possible. That's good. Marc and I, however, have to consider all the other documents as well (e.g., PhoneBCP and framework). In case you have not noticed, you are not treating me a bit unfair. I tried my best to catch up in the meanwhile and will respond to the raised issues in separate mails. Ciao Hannes >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: 02 January, 2009 21:55 >To: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; ECRIT >Subject: RE: [Ecrit] ECRIT Status Update - December 2008 >(esnet namespace) > >At 03:39 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>Hi James, >> >> >At 05:53 PM 12/30/2008, Hannes Tschofenig wrote: >> >>8) draft-ietf-ecrit-local-emergency-rph-namespace >> >> >> >>We had some discussions about this document triggered by mails >> >>around >> >>IETF#73 asking for the purpose and the scope. >> >>I read through the e-mail exchange but I need to read through some >> >>RFCs/drafts as well in order to summarize the topic. >> >> >> >>A few folks have provided feedback (James, Brian, Janet, >Keith) but >> >>more reviews from the rest of the group would be useful. >> >> >> >>Action item: Hannes to summarize the discussions and to draw >> >a conclusion. >> > >> >Hannes - why are you artificially creating such a high hurdle for >> >this ID to progress? >> >>Summarizing a discussion is not "a high hurdle". > >if you only said you would summarize this, then I wouldn't be >writing anything here. You also include this comment above > > "...but more reviews from the rest of the > group would be useful..." > >when did 6 or 7 reviewers saying one thing (in the positive) >and 1 saying another thing (in the "I don't understand") mean >anything other than _rough_consensus_? > >What we are hearing you say is "until I (Hannes) understand >and agree with this, this ID will not progress". > >Jon admitted on the mic in Minn that he's "not the biggest fan >of RP"... which is widely known, yet he decided to say into >the mc in Minn that he is not going to fight this effort either. > >SIP has one defined way to mark the priority of a request - >and that's in RFC 4412 (Resource-Priority). > >You have said a number of times that the To: field can be >used, that the R-URI value can be used... claiming that using >the RP header would add another meant of marking the priority >of a request. > >Yet the SIP WG chair has confirmed to you in front of several >others (including me, Brian, Marc (your co-chair)) that SIP >has one, singular way to priority mark its requests - and that >is defined by RFC 4412 (Resource-Priority). > >Anything else, (i.e., any other way of marking the priority of a SIP >request) would in fact be an additional way SIP entities would >have to be coded to perform this function. > >You have repeatedly refused to acknowledge that fact. I >believe that is at least most of why you are resisting this ID >from becoming a WG item, and are continuing to find >manufactured faults with it. > >You are standing alone in your views, my friend - which is >contrary to IETF procedures of rough consensus, and I ask that >you agree with the core philosophy of the IETF that rough >consensus makes decisions in the IETF, and move on. > > >> > >> >The WG hummed for this ID to become a WG item in Dublin. >> >>I know. Like the group did with a number of other items. >>Officially, the document is not a WG item yet given that we would >>require the charter to change as mentioned at the last meeting. > >Yeah, and that recharter - for whatever reason, didn't happen >in the last 5 months since the Dublin meeting why? > >How long before the WG can expect this recharter? (a year?) > > >> > >> >There hasn't been one other opinion contrary to this (save for >> >yours) on the list or at the Minneapolis meeting. >> >>Well. I raised several issues which I would like to summarize. > >you raised many issues, nearly all of which had the answer >"this is not how SIP works", but you didn't seem to like that answer. > >>To pick one "PSAP callback" where there does not seem to be >agreement, >>referencing Brian: >>http://www.ietf.org/mail-archive/web/ecrit/current/msg05686.html > >"PSAP Callback" - hmmmmmm..... let's see.... > >You have a requirement that "priority" needs to be e2e in one >direction but not the other? > >Where's that written down? > >Do you believe there's a chance in heck that all SIP UAs will >have the code in them to process the priority of this PSAP Callback? > >Funny, that's the same argument that you gave me that >(paraphrasing) "because most UAs will not have RFC 4412 code >in them, why are you >(James) pushing this solution on ECRIT?" > >the sword cuts both ways. > >This ID doesn't have the UAC needing to set the RP within the >INVITE. Nor does it prioritize the RP in the received INVITE either. > >Therefore PSAP Callback is pointless at this point in time for >UAs at all, right? It's more for the ESNET and perhaps one >admin domain out from that network. > >Look at figure 1 of this ID, and tell me where (i.e., which >element(s) in which domain(s)) PSAP Callback is mandatory to >set the priority of that Callback INVITE? > > > >> > Therefore, >> >it is impossible to conclude with evidence that anyone >other than you >> >are delaying this progression. >> >>Delaying? Given that we have to change the charter first > >hmmm.... again... that decision was made 2 meetings ago. How >much longer should the WG have to wait for this recharter? > >>before this >>document can actually be picked up as an item (like the other >documents >>as well) I am not delaying anything here. > >ok, so who is writing the recharter (if not the WG chair) and >why are they taking so long? Let me know who this other person >is and I'll ask them to inform the WG themselves (directly) >with the ETA on this. > > >>Getting the new charter approved is only possible if we are able to >>finish our main items, as Jon says. Despite our pushing Phone BCP and >>Framework are still not finished. > >yet, I can't help but notice that both >http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-location-hiding-req/ >and >http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-specifying-holes/ >are recent additions to the ECRIT charter... > >indeed, these two IDs weren't event though about when phoneBCP >and Framework were WGLCd the first time, yet they made the >charter within a few months from their hum by the WG... > >this is inconsistent with the stance you are taking now with >the esnet namespace ID, Hannes. > > >> > >> >Many have expressed in email to the list, and in person at >> >Minneapolis to you that you are not understanding the topic as >> >much as you believe (SIP signaling and SIP header usage, and >> >this includes the SIP chair that has given you his opinion in >> >front of others), and each of the rest of us (that have voiced >> >an opinion) are in unison in our understanding (and have >> >attempted nearly countless times to explain how you have a >> >misunderstanding of SIP communications). >> >>Maybe I don't understand this particular item well enough. If I don't >>understand it given that I am working in this space already for many >>years gives me the impression that maybe I am not the only one. > >So, bluntly, how much do you understand about SIP signaling >and headers? > >This is the question. WG chairs do not need to understand everything >within their WG perfectly, but need to trust a select few that do >understand the topics you don't. Is Keith, the SIP WG chair, not a >good enough person to trust in this instance? > >And from the point of view of "...maybe I am not the only one..." >isn't it also the burden of those that do not understand something to >voice their opinions at the meeting mic or on the mailing list (else >they are to be considered in agreement with a proposal)? > >I believe this is another IETF procedure you are not adhering >to on this case. > >>At least >>in the past I was never wrong with such an assumption. > >Unless there is another who says so on the public list, you have no >proof this is the case here. > > >>I don't think it can be wrong to ask questions about documents we have >>in the group (even if they appear irrelevant to the authors of the >>mechanism as he knows it better than anybody else). > >Hannes, many individuals answered your questions as "you're wrong" or >"you're not understanding SIP signaling" during the threads during >the Minn IETF meeting. If everyone who has responded to you is >saying "you're not right in this opinion", what does it take for you >to consider the possibility *each* of them is right, and you are not? > >> >> >Furthermore - your co-chair does not agree with you, and >> >believes as others do that this ID is needed, necessary and >> >wants it to progress >> >- including other SDOs and organizations (NENA for one) that >> >want to reference this document as an RFC. >> >>I am actually participating in various NENA conf. calls and have >>participated in discussions around resource priority for >>citizen-to-authority emergency calls. I have not heard you on those >>calls. > >not being an active participant does not mean I don't understand the >issues. Besides, I trust Brian Rosen here, the NENA WG chair (since >the WG formed), who is one of the ones telling you that you don't >understand what you are saying wrt RP esnet namespace ID. > > >>In short, I am not delaying -- I am trying to understand. No reason to >>worry. >> >>Ciao >>Hannes >> >> > >> >James > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 3 14:50:39 2009 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 0F7A13A688E; Sat, 3 Jan 2009 14:50:39 -0800 (PST) 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 4CA213A68E7 for ; Sat, 3 Jan 2009 14:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.387, 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 HiT2DBRgIdcG for ; Sat, 3 Jan 2009 14:50:37 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EC5173A688E for ; Sat, 3 Jan 2009 14:50:36 -0800 (PST) Received: (qmail invoked by alias); 03 Jan 2009 22:50:23 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp031) with SMTP; 03 Jan 2009 23:50:23 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19d5QoAmk5djXSNok3O+mhD6ef8FR3psONjtyIdxI dcbAudyhsDPB4d From: "Hannes Tschofenig" To: "'ECRIT'" Date: Sun, 4 Jan 2009 00:50:50 +0200 Message-ID: <007e01c96df5$ba2f31c0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aclt9blP0fFrM7T7Spy+AqFFVeqC7w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59 Subject: [Ecrit] Rechartering: Roadmap 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, In a previous mail James was "asking" why the re-charting effort is taking so long. First, the discussion we had in Dublin (last summer) was mainly to get the feedback from the group about where the group should be heading to. We got good feedback: a) we learned that the group was interested in working on early warning but that a sort-of BOF should be prepared (later that turned into a real-BOF effort lead by Steve and Brian). b) there was interest in doing non-emergency LoST extensions and c) the group gave feedback to some other emergency services related extensions. We had a lot on the table. Second, this is the important reason. Jon always told us to finish our current documents first before we pick up new work. We have also said this to the group. This is, in general, a common procedure with IETF working groups. This is also a useful advice given that we have not meet our expectations regarding PhoneBCP / Framework. I also asked Brian whether he needs help with the document (e.g., in the form of a new editor or an additional author). He said that he can handle it. We trusted him. These two documents are delayed already for a while and every time we believe we get closer to finish them we find another issue. After the IETF#72 meeting in Dublin there was essentially silence during the summer months -- everyone was on the beach, I guess. Then, in October the topic of premature disconnect indication surfaced and was blocking the progress of of Phone BCP again. We took steps to advance that work independently of Phone BCP (i.e., this is good for Phone BCP and hopefully the issues will get resolved independently; see Brian's mail). NOTE: That does not prevent us from progressing the other documents. With draft-ietf-ecrit-specifying-holes there was the question whether this is actually part of LoST sync. I asked the group for a preference. It was not clear whether it is strongly tight to LoST sync. Hence, we decided to dump it into a separate document. Jon was OK to add this documents to the group without a need to recharter because he got the impression that they fall within the scope of the group. Regarding draft-ietf-ecrit-location-hiding-req: We had a lot discussions around this topic. It later turned out that this is essentially the question on how to deal with rough location in LoST. Jon agreed that we can add this requirements document to our milestone list but for the solution document he wanted to have it included in the rechartering discussion. Makes sense to me given the controversial discussions. As some of you might know, it is not necessary to go through a re-charting step, which is typically quite lengthy, with every new document. For a number of the documents we do, however, stretch the limits of the charter. Hence, we started the rechartering investigations. When we scheduled the rechartering discussion for Dublin we thought that we are essentially done with PhoneBCP/framework (see http://www.ietf.org/mail-archive/web/ecrit/current/msg05279.html). Later it turned out that this wasn't quite true. Everyone can help to make better and faster progress: if you haven't sent a review of PhoneBCP/Framework to the list then you are essentially delaying the work. This includes reading through the document and concluding that the document is fine. Please also try to provide constructive feedback or proposal for how to resolve your comment. Make sure that your comment gets addressed -- if not complain immediately. Let me know if there are further questions. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 3 14:57:05 2009 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 50CB93A688E; Sat, 3 Jan 2009 14:57:05 -0800 (PST) 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 14A063A63EC for ; Sat, 3 Jan 2009 14:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_00=-2.599, MANGLED_SIDE=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 ydwSmF8k9kol for ; Sat, 3 Jan 2009 14:57:02 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 577AA3A6824 for ; Sat, 3 Jan 2009 14:57:01 -0800 (PST) Received: (qmail invoked by alias); 03 Jan 2009 22:56:48 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp035) with SMTP; 03 Jan 2009 23:56:48 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX192DsUzzxp2ykDfZrJdaeD3TRF5QsVNdt85ks+hbD CvpQNKVJPi6H3G From: "Hannes Tschofenig" To: "'ECRIT'" Date: Sun, 4 Jan 2009 00:57:16 +0200 Message-ID: <007f01c96df6$9fcfade0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aclt9p9TPgOdca6kQjSRx848oPqtAA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Subject: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00.txt: Scope (again) 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 time with my co-chair hat on) Hi all, I reviewed the past presentations of RPH from IETF#72, IETF#70, and IETF#67. You can listen into the audio recording yourself -- quite interesting. http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf67ch4-tue-noo n.mp3 http://limestone.uoregon.edu/ftp/pub/videolab/video/ietf70/ietf70-ch1-tue-af noon-ecrit-dime-avt.mp3 http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/ietf72-ch6-tue-no on.mp3 An essentially issue, as it appears in the entire discussion, is the question of applicability -- where should this SOS RPH mechanism be used. There are at the following possible cases: (a) UA to VSP (b) VSP to PSAP (potentially via another VSP) (c) Within the emergency services network (including PSAP to first responders) (d) PSAP callback I briefly summarize the feedback the group got at those meetings: -- IETF#67 A lot of the discussion focus on the name of the namespace, i.e. a syntactic issue. Jonathan, Henning, and Ted argue that the usage of RPH particularly for scenario (a) is not a good idea. Janet, James, and Brian like the idea of using RPH for use case (a), (b), and (c). (I am not sure about everyone's position regarding (d)). Brian Stucker believes that RPH is OK for usage for scenario (d). He argues that the authorization problem is simpler to solve with that scenario. -- IETF#70 Keith, James and Brian like the document. Brian, for example, says that it is very useful within an IP public safety communication network, i.e., scenario (c). He also thinks that it is useful outside of it in a public network. Jon, Richard, and Henning have concerns regarding the usage of RPH for things other than scenario (c). Particularly scenario (a) seems to be problematic. I also voiced my opinion during that meeting against usage of RPH for scenario (a). THIS IS IMPORTANT: At the end of the meeting James asks Henning whether he would be happy with the document if the focus is only on using SOS RPH within the emergency services network, i.e., scenario (c). Henning says that this is fine for him as it reassembles much better the intention of RPH. James promises to update the document to reflect this restricted scope. I checked subsequent draft versions: No scope change in any form. -- IETF#72 We did not really discuss the document as such. We only asked for a HUM assuming that folks were aware of the current document version. For some reason I must have had the discussions in mind that happened at IETF#70 where the scope limitation of the draft got discussed. As such, my mail to the list http://www.ietf.org/mail-archive/web/ecrit/current/msg05665.html was, I believe, not completely off topic. Although I did not recall who had raised objections in previous meetings when I wrote my ECRIT WG status update I think that as a WG co-chair it is fair to hear the opinion of those again that had previously raised concerns. Maybe they changed their mind and are now in favor of using RPH for scenario (a). Could be possible. Reading through the mail discussions, the drafts and listening to the meeting recordings helped me again to refresh my memory regarding the purpose of RPH for scenario (c). Hope that this was a useful investigation. Ciao Hannes PS: I also noticed that the justification for the work, as mentioned on the presentation slides, seems to be "Brian sez NENA wants it", see: http://www.ietf.org/proceedings/07dec/slides/ecrit-2/sld2.htm http://www.ietf.org/proceedings/06nov/slides/ecrit-7/sld3.htm It is good that our work finds excitement in other SDOs and groups. Given that NENA focuses largely on the emergency services network itself rather than on the end host to VSP exchanges, I guess it would have been nice to have a better idea what the detailed requirements are. At the IETF#70 presentation James furthermore mentions that scenario (b) could be useful in an 3GPP IMS context. I have to check whether there is interest to use RPH there and for what exactly. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 4 14:22:02 2009 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 4C38F3A69CC; Sun, 4 Jan 2009 14:22:02 -0800 (PST) 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 395343A6934 for ; Sun, 4 Jan 2009 14:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.735 X-Spam-Level: X-Spam-Status: No, score=-5.735 tagged_above=-999 required=5 tests=[AWL=-1.436, BAYES_00=-2.599, MANGLED_SIDE=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 3lcrD5BS92lA for ; Sun, 4 Jan 2009 14:22:00 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 108513A689F for ; Sun, 4 Jan 2009 14:22:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,329,1228089600"; d="scan'208";a="223580160" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 04 Jan 2009 22:21:48 +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 n04MLlfR006398; Sun, 4 Jan 2009 14:21:47 -0800 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 n04MLleG029380; Sun, 4 Jan 2009 22:21:47 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); Sun, 4 Jan 2009 14:21:47 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.16.227]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Jan 2009 14:21:47 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 04 Jan 2009 16:21:45 -0600 To: "Hannes Tschofenig" , "'ECRIT'" From: "James M. Polk" In-Reply-To: <007f01c96df6$9fcfade0$0201a8c0@nsnintra.net> References: <007f01c96df6$9fcfade0$0201a8c0@nsnintra.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 04 Jan 2009 22:21:47.0251 (UTC) FILETIME=[D4F41C30:01C96EBA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6156; t=1231107707; x=1231971707; 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]=0A=20=20draft-ietf-ecrit-local- emergency-rph-namespace-00.txt=3A=20Scope=20(again) |Sender:=20; bh=coSja+AdtG2rlWxd7ig/932a+PrEla9oKoC8i/RoiBw=; b=dRq0jL9IyTjGHDUvym5tbbmIeXGJdzpe6PuxuSyAApKyIeKlmrOHdQStzf bAwyLX56MMIYk129RFUIzhKtnwa1I/oomz751BPYqFovbGRlJF8PnNDbK9Ae DNrXh5QPqT; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00.txt: Scope (again) 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 Hannes Thanks for summarizing. draft-ietf-ecrit-local-emergency-rph-namespace-00 currently says scenario: (a) is "can be used" in Figure 1 and "MAY be included" in text. (b) is "can be used" in Figure 1 and "MAY be included" in text. (c) is to be used (when supporting this doc) in both Figure 1 and the text. (d) is "MAY be included" in text of section 3. For (a), Section 2 goes on to say that use of this namespace from UACs is likely untrustworthy, unless the UAC is directly attached to an IP managed network (such as IMS). I don't really need to remind you that MAYs (in PS RFCs) are for implementers, not configurers. These mean that a future RFC MAY make any MAY into a MUST, SHOULD, MUST NOT or SHOULD NOT. The reason I still have "can be used" in Figure 1 and "MAY be included" in text is that to omit these is to implicitly forbid its use in a), b) and d) -- which, after IETF#67, I was asked explicitly not to do this for (b) - which you note below (in IMS). I'm willing to change the text around scenario (a) to something like "...it is NOT RECOMMENDED (or SHOULD NOT be used), but a specification in the future MAY recommend or mandate the usage of this namespace...". Reality applies here too, given that I do not believe any ESInet will interconnect to any public network without an SBC (or B2BUA), thus any RP namespace received by this SBC will likely be ignored and not passed on to the ESInet's interior elements. I'm equally open to changing scenario (d) to say the same thing as I offered to write about (a). Either MAY being changed to SHOULD or MUST would (most) likely be based on implementation experience. What do you think about both these suggestions? James At 04:57 PM 1/3/2009, Hannes Tschofenig wrote: >(this time with my co-chair hat on) > >Hi all, > >I reviewed the past presentations of RPH from IETF#72, IETF#70, and IETF#67. >You can listen into the audio recording yourself -- quite interesting. >http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf67ch4-tue-noo >n.mp3 >http://limestone.uoregon.edu/ftp/pub/videolab/video/ietf70/ietf70-ch1-tue-af >noon-ecrit-dime-avt.mp3 >http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/ietf72-ch6-tue-no >on.mp3 > >An essentially issue, as it appears in the entire discussion, is the >question of applicability -- where should this SOS RPH mechanism be used. >There are at the following possible cases: > > (a) UA to VSP > (b) VSP to PSAP (potentially via another VSP) > (c) Within the emergency services network (including PSAP to first >responders) > (d) PSAP callback > >I briefly summarize the feedback the group got at those meetings: > > -- IETF#67 > >A lot of the discussion focus on the name of the namespace, i.e. a syntactic >issue. >Jonathan, Henning, and Ted argue that the usage of RPH particularly for >scenario (a) is not a good idea. > >Janet, James, and Brian like the idea of using RPH for use case (a), (b), >and (c). (I am not sure about everyone's position regarding (d)). > >Brian Stucker believes that RPH is OK for usage for scenario (d). He argues >that the authorization problem is simpler to solve with that scenario. > > -- IETF#70 > >Keith, James and Brian like the document. Brian, for example, says that it >is very useful within an IP public safety communication network, i.e., >scenario (c). He also thinks that it is useful outside of it in a public >network. > >Jon, Richard, and Henning have concerns regarding the usage of RPH for >things other than scenario (c). Particularly scenario (a) seems to be >problematic. I also voiced my opinion during that meeting against usage of >RPH for scenario (a). > >THIS IS IMPORTANT: At the end of the meeting James asks Henning whether he >would be happy with the document if the focus is only on using SOS RPH >within the emergency services network, i.e., scenario (c). Henning says that >this is fine for him as it reassembles much better the intention of RPH. >James promises to update the document to reflect this restricted scope. I >checked subsequent draft versions: No scope change in any form. > > -- IETF#72 > >We did not really discuss the document as such. We only asked for a HUM >assuming that folks were aware of the current document version. > > >For some reason I must have had the discussions in mind that happened at >IETF#70 where the scope limitation of the draft got discussed. As such, my >mail to the list >http://www.ietf.org/mail-archive/web/ecrit/current/msg05665.html was, I >believe, not completely off topic. > >Although I did not recall who had raised objections in previous meetings >when I wrote my ECRIT WG status update I think that as a WG co-chair it is >fair to hear the opinion of those again that had previously raised concerns. >Maybe they changed their mind and are now in favor of using RPH for scenario >(a). Could be possible. > >Reading through the mail discussions, the drafts and listening to the >meeting recordings helped me again to refresh my memory regarding the >purpose of RPH for scenario (c). > >Hope that this was a useful investigation. > >Ciao >Hannes > >PS: I also noticed that the justification for the work, as mentioned on the >presentation slides, seems to be "Brian sez NENA wants it", see: >http://www.ietf.org/proceedings/07dec/slides/ecrit-2/sld2.htm >http://www.ietf.org/proceedings/06nov/slides/ecrit-7/sld3.htm > >It is good that our work finds excitement in other SDOs and groups. Given >that NENA focuses largely on the emergency services network itself rather >than on the end host to VSP exchanges, I guess it would have been nice to >have a better idea what the detailed requirements are. At the IETF#70 >presentation James furthermore mentions that scenario (b) could be useful in >an 3GPP IMS context. I have to check whether there is interest to use RPH >there and for what exactly. > >_______________________________________________ >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 Jan 4 14:25:49 2009 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 AB1163A6A98; Sun, 4 Jan 2009 14:25:49 -0800 (PST) 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 CCC6E3A6A98 for ; Sun, 4 Jan 2009 14:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.705 X-Spam-Level: X-Spam-Status: No, score=-6.705 tagged_above=-999 required=5 tests=[AWL=-0.106, 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 Wb5gVuVTXRFA for ; Sun, 4 Jan 2009 14:25:46 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C9FA13A689F for ; Sun, 4 Jan 2009 14:25:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,329,1228089600"; d="scan'208";a="223580976" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 04 Jan 2009 22:25:34 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n04MPYCS014523; Sun, 4 Jan 2009 14:25:34 -0800 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 n04MPYiU000374; Sun, 4 Jan 2009 22:25:34 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); Sun, 4 Jan 2009 14:25:34 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.16.227]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Jan 2009 14:25:33 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 04 Jan 2009 16:25:32 -0600 To: "Brian Rosen" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" From: "James M. Polk" In-Reply-To: <020301c96dad$ac9b52c0$05d1f840$@net> References: <020301c96dad$ac9b52c0$05d1f840$@net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 04 Jan 2009 22:25:33.0984 (UTC) FILETIME=[5C18D200:01C96EBB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3575; t=1231107934; x=1231971934; 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]=20PSAP=20Call=20Backs |Sender:=20; bh=Kvc3NnQ1UAwzFc3nl3KMuKmFJ4s2VX3Py9jURJWpNwk=; b=IUURUygXcd8rBds1G0mvHofsO7oFcLtqiQ5/WOvDEuGJQWsWs0t2iNUkn2 6pxQ3H7e2FnqdffYIPnyhpOhoXm/omtT0IsqnUuOilWSVYBi+uAjsEV+I514 w7HL5tsW8TMdLI+1IBbwlV7Io899gsxc2K4yUF9u5wpE8rTdux/Qk=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] PSAP Call Backs 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:15 AM 1/3/2009, Brian Rosen wrote: >As with incoming calls, some minimum standards are needed on the signaling. > >I also want to point out that resource priority marking is NOT a good choice >for an overall callback mark, I'd like to second this view, and offer that callback marking text be removed from draft-ietf-ecrit-local-emergency-rph-namespace. Comments? James >the same way that the Route header sos urn is >not a good choice for a resource priority mark. > >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >James M. Polk >Sent: Friday, January 02, 2009 3:15 PM >To: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >Subject: Re: [Ecrit] PSAP Call Backs > >At 04:21 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >Hi all, > > > >In the last few months we have seen increased interest in the topic of > >PSAP call backs. > > > >Section 10 of http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-06 > >says: > > > > SP-36 Call backs to the Contact: header URI recieved within 30 > > minutes of an emergency call must reach the device regardless of call > > features or services that would normally cause the call to be routed > > to some other entity. > > > >More importantly, Section 13 says: > > > > ED-73 Call backs SHOULD be determined by retaining the domain of the > > PSAP which answers an outgoing emergency call and instantiating a > > timer which starts when the call is terminated. If a call is > > received from the same domain and within the timer period, sent to > > the Contact: or AoR used in the emergency call, it should be assumed > > to be a call back. The suggested timer period is 5 minutes. > > > >http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt proposed > >another solution based on marking the callback using the "sos" URI > >parameter. > > > >http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-local-emergency-rph-name > >space/ proposes another solution by utilizing the Resource Priority > >Header. > >within the namespace ID, the total thought (for PSAP callback) is here: > > This namespace will also be used > for communications between emergency authorities, and MAY be used > for emergency authorities calling public citizens. An example of > the later is a PSAP operator calling back someone who previously > called 9111/112/999 and the communication was terminated before it > should have been (in the operator's judgment). > >Notice this is all based on the MAY in the first sentence, therefore >it can be considered an afterthought, i.e., something that can be >utilized/specified later. > >the "sos" parameter solution is more definitive, yet it should >identify a priority marking (in SIP), given that there is already a >defined way to do that in SIP, and a second way shouldn't be defined >- as it will only lead to interoperability issues. > > > >So, here are my high-level questions: > > > >A) Do you think that you understand the requirements that lead to a need > >for a technical solution? > > > >B) Do you believe that more work beyond the mechanism described in Phone > >BCP is needed? > > > >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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jan 4 14:39:47 2009 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 B9A563A68A6; Sun, 4 Jan 2009 14:39:47 -0800 (PST) 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 21F8D3A6885 for ; Sun, 4 Jan 2009 14:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.543 X-Spam-Level: X-Spam-Status: No, score=-5.543 tagged_above=-999 required=5 tests=[AWL=-1.244, 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 zPyTgq6PCLGP for ; Sun, 4 Jan 2009 14:39:44 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id CCC2F3A6A90 for ; Sun, 4 Jan 2009 14:39:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,329,1228089600"; d="scan'208";a="126515026" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 04 Jan 2009 22:39:32 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n04MdWO0017419; Sun, 4 Jan 2009 14:39:32 -0800 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 n04MdWfA023104; Sun, 4 Jan 2009 22:39:32 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); Sun, 4 Jan 2009 14:39:32 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.16.227]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Jan 2009 14:39:31 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 04 Jan 2009 16:39:30 -0600 To: "Hannes Tschofenig" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'ECRIT'" From: "James M. Polk" In-Reply-To: <007501c96dd1$1b5ecd40$0201a8c0@nsnintra.net> References: <007501c96dd1$1b5ecd40$0201a8c0@nsnintra.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 04 Jan 2009 22:39:31.0729 (UTC) FILETIME=[4F6E9010:01C96EBD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4806; t=1231108772; x=1231972772; c=relaxed/simple; s=sjdkim2002; 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]=20PSAP=20Call=20Backs |Sender:=20; bh=nfuIXR1469Q/OXGy5e3l+PkpE9szjB24Y+1NirdbF0M=; b=WA69Mg090wU8918Hxc5zX1xH+40Z4NrPpE9Kc3EhX43BMmNwhhUx9ZitB4 QWhjAIKFr9WR5kign+vkrVIOSjBt1JHmyWkBP+l4fOR8HlSc0WC/BV8nfPJD x6KfhUpTOs; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Ecrit] PSAP Call Backs 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:28 PM 1/3/2009, Hannes Tschofenig wrote: >There are two different aspects: > >A) A decision that decides whether a call back has to be marked or not > >B) When the decision is made that is has to be marked then how the marking >is going to look like. > >Regarding (A): This might be a policy issues. Some PSAPs might want to use >this indication and others might not. Nothing we have to worry about. > >Regarding (B): Here there needs to be one way todo the marking -- not >multiple ways. It would just increase the implementation complexity, the >number of error cases and interop problems. > >I am not sure to what your "MAY" statement refers to -- to (A) or (B). MAY means not prohibited, and can be specified in a future doc. Regarding your questions A and B, I'm not a fan of using an RP namespace to do callbacks, given that I don't believe we can be sure or the signaling path in the reverse direction (i.e., from the PSAP back to the original UAC caller), so I'm not sure how we can believe any marking indication is going to work even 50% of the time (if that). Remember, you personally don't trust the UAC to set a correct esnet namespace, so how can you trust the UAC to correctly receive this same esnet namespace and do the right things about that SIP INVITE? I believe the same applies to the sos-parameter draft. How do we know it'll be only used during emergency callback, and not used to prevent call forwarding or otherwise disable features the UA endpoint normally wants applied to any inbound call attempt? >Ciao >Hannes > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of James M. Polk > >Sent: 02 January, 2009 22:15 > >To: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > >Subject: Re: [Ecrit] PSAP Call Backs > > > >At 04:21 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >>Hi all, > >> > >>In the last few months we have seen increased interest in the > >topic of > >>PSAP call backs. > >> > >>Section 10 of http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-06 > >>says: > >> > >> SP-36 Call backs to the Contact: header URI recieved within 30 > >> minutes of an emergency call must reach the device > >regardless of call > >> features or services that would normally cause the call > >to be routed > >> to some other entity. > >> > >>More importantly, Section 13 says: > >> > >> ED-73 Call backs SHOULD be determined by retaining the > >domain of the > >> PSAP which answers an outgoing emergency call and instantiating a > >> timer which starts when the call is terminated. If a call is > >> received from the same domain and within the timer period, sent to > >> the Contact: or AoR used in the emergency call, it should > >be assumed > >> to be a call back. The suggested timer period is 5 minutes. > >> > >>http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt > >>proposed another solution based on marking the callback using > >the "sos" > >>URI parameter. > >> > >>http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-local-emergenc > >y-rph-nam > >>e space/ proposes another solution by utilizing the Resource Priority > >>Header. > > > >within the namespace ID, the total thought (for PSAP callback) is here: > > > > This namespace will also be used > > for communications between emergency authorities, and MAY be used > > for emergency authorities calling public citizens. An example of > > the later is a PSAP operator calling back someone who previously > > called 9111/112/999 and the communication was terminated before it > > should have been (in the operator's judgment). > > > >Notice this is all based on the MAY in the first sentence, > >therefore it can be considered an afterthought, i.e., > >something that can be utilized/specified later. > > > >the "sos" parameter solution is more definitive, yet it should > >identify a priority marking (in SIP), given that there is > >already a defined way to do that in SIP, and a second way > >shouldn't be defined > >- as it will only lead to interoperability issues. > > > > > >>So, here are my high-level questions: > >> > >>A) Do you think that you understand the requirements that lead to a > >>need for a technical solution? > >> > >>B) Do you believe that more work beyond the mechanism described in > >>Phone BCP is needed? > >> > >>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 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 5 07:47:17 2009 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 6BA413A6922; Mon, 5 Jan 2009 07:47:17 -0800 (PST) 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 A8D603A6922 for ; Mon, 5 Jan 2009 07:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=-0.108, 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 2JcYuyrTLNxP for ; Mon, 5 Jan 2009 07:47:14 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id D40C83A67A5 for ; Mon, 5 Jan 2009 07:47:14 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LJrfK-00080k-LA for ecrit@ietf.org; Mon, 05 Jan 2009 09:46:55 -0600 From: "Brian Rosen" To: "'ECRIT'" Date: Mon, 5 Jan 2009 10:46:57 -0500 Message-ID: <041401c96f4c$d8fac300$8af04900$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0415_01C96F22.F024BB00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclvTIjLTeaE55m5RQueCuKCdvI2EAAACaqQ 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: [Ecrit] FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.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 multipart message in MIME format. ------=_NextPart_000_0415_01C96F22.F024BB00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is the version with a user focus only on the requirements. I ask that this be considered a work group item. Brian -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, January 05, 2009 10:45 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for handling abandoned calls and premature disconnects in emergency calls on the Internet Author(s) : B. Rosen Filename : draft-rosen-ecrit-premature-disconnect-rqmts-02.txt Pages : 6 Date : 2009-01-05 The -phonebcp draft currently requires endpoints to disable sending a BYE on an emergency call. Insufficient justification and lack of attention to the entire problem has caused comment on that section of the document. This document attempts to define the problem and the requirements to controlling disconnect on emergency calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosen-ecrit-premature-disconnect-r qmts-02.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_000_0415_01C96F22.F024BB00 Content-Type: Message/External-body; name="draft-rosen-ecrit-premature-disconnect-rqmts-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-rosen-ecrit-premature-disconnect-rqmts-02.txt" Content-Type: text/plain Content-ID: <2009-01-05074458.I-D@ietf.org> ------=_NextPart_000_0415_01C96F22.F024BB00 Content-Type: text/plain; name="ATT01042.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT01042.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_0415_01C96F22.F024BB00 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_000_0415_01C96F22.F024BB00-- From ecrit-bounces@ietf.org Mon Jan 5 07:47:40 2009 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 8EA743A67AB; Mon, 5 Jan 2009 07:47:40 -0800 (PST) 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 005CB3A67AB for ; Mon, 5 Jan 2009 07:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.438 X-Spam-Level: X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[AWL=-1.139, 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 e3DRalsYvFlB for ; Mon, 5 Jan 2009 07:47:38 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id F018E3A67A5 for ; Mon, 5 Jan 2009 07:47:37 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LJrfg-00081q-Tx; Mon, 05 Jan 2009 09:47:17 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'James M. Polk'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: <007501c96dd1$1b5ecd40$0201a8c0@nsnintra.net> In-Reply-To: <007501c96dd1$1b5ecd40$0201a8c0@nsnintra.net> Date: Mon, 5 Jan 2009 10:47:19 -0500 Message-ID: <041801c96f4c$e63c29f0$b2b47dd0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcltFtXFMn8qyHKdSCO7B7iBHlGTAAAuajmwAFtIfkA= 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] PSAP Call Backs 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 would have said that we decide if callbacks should have special treatment of any kind. If we decide that they should, then we decide how we will mark them, and then what the behavior is for that marking. Please do not confuse the resource priority marking and behavior with this discussion. As with the emergency call marking (urn:service:sos in Route), and the associated behaviors in PhoneBCP, the RPH is an independent marking and behavior specification. If we mark call backs, it won't be with RPH. A callback MAY also have an RPH marking, and there could be behavior associated with that with respect to priority handling within a network. Similarly, the packets of a callback could have a DiffServ marking, and behavior associates with that marking within a network. I think we should have a call back marking, and we should specify behaviors for that marking. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Saturday, January 03, 2009 1:29 PM To: 'James M. Polk'; Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' Subject: Re: [Ecrit] PSAP Call Backs There are two different aspects: A) A decision that decides whether a call back has to be marked or not B) When the decision is made that is has to be marked then how the marking is going to look like. Regarding (A): This might be a policy issues. Some PSAPs might want to use this indication and others might not. Nothing we have to worry about. Regarding (B): Here there needs to be one way todo the marking -- not multiple ways. It would just increase the implementation complexity, the number of error cases and interop problems. I am not sure to what your "MAY" statement refers to -- to (A) or (B). Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of James M. Polk >Sent: 02 January, 2009 22:15 >To: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >Subject: Re: [Ecrit] PSAP Call Backs > >At 04:21 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>Hi all, >> >>In the last few months we have seen increased interest in the >topic of >>PSAP call backs. >> >>Section 10 of http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-06 >>says: >> >> SP-36 Call backs to the Contact: header URI recieved within 30 >> minutes of an emergency call must reach the device >regardless of call >> features or services that would normally cause the call >to be routed >> to some other entity. >> >>More importantly, Section 13 says: >> >> ED-73 Call backs SHOULD be determined by retaining the >domain of the >> PSAP which answers an outgoing emergency call and instantiating a >> timer which starts when the call is terminated. If a call is >> received from the same domain and within the timer period, sent to >> the Contact: or AoR used in the emergency call, it should >be assumed >> to be a call back. The suggested timer period is 5 minutes. >> >>http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt >>proposed another solution based on marking the callback using >the "sos" >>URI parameter. >> >>http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-local-emergenc >y-rph-nam >>e space/ proposes another solution by utilizing the Resource Priority >>Header. > >within the namespace ID, the total thought (for PSAP callback) is here: > > This namespace will also be used > for communications between emergency authorities, and MAY be used > for emergency authorities calling public citizens. An example of > the later is a PSAP operator calling back someone who previously > called 9111/112/999 and the communication was terminated before it > should have been (in the operator's judgment). > >Notice this is all based on the MAY in the first sentence, >therefore it can be considered an afterthought, i.e., >something that can be utilized/specified later. > >the "sos" parameter solution is more definitive, yet it should >identify a priority marking (in SIP), given that there is >already a defined way to do that in SIP, and a second way >shouldn't be defined >- as it will only lead to interoperability issues. > > >>So, here are my high-level questions: >> >>A) Do you think that you understand the requirements that lead to a >>need for a technical solution? >> >>B) Do you believe that more work beyond the mechanism described in >>Phone BCP is needed? >> >>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 > _______________________________________________ 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 Jan 5 07:56:46 2009 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 F0DBB3A6AF8; Mon, 5 Jan 2009 07:56:45 -0800 (PST) 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 9E3B73A6AF8 for ; Mon, 5 Jan 2009 07:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.383 X-Spam-Level: X-Spam-Status: No, score=-1.383 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_00=-2.599, MANGLED_SIDE=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 iiBmB6IprOX1 for ; Mon, 5 Jan 2009 07:56:43 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 637EB3A67A5 for ; Mon, 5 Jan 2009 07:56:43 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LJroU-0000Go-Jv; Mon, 05 Jan 2009 09:56:23 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ECRIT'" References: <007f01c96df6$9fcfade0$0201a8c0@nsnintra.net> In-Reply-To: <007f01c96df6$9fcfade0$0201a8c0@nsnintra.net> Date: Mon, 5 Jan 2009 10:56:25 -0500 Message-ID: <042d01c96f4e$2bca24d0$835e6e70$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aclt9p9TPgOdca6kQjSRx848oPqtAABVqniA 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-local-emergency-rph-namespace-00.txt: Scope (again) 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 is very little downside to allowing the marking to be used in any network. It's the behaviors that are implied by the marking that you care about. In a public network, there may not be any behaviors associated with the marking, while in an Emergency Services IP Network, there most certainly will be. The document in question doesn't really address behavior, and it shouldn't. NENA would specify behaviors within the networks it standardizes, and is in a much better position to do that. What we need is a namespace. You can qualify it if you want: "MAY" is good enough in the origination network and the interconnect between the origination network and the Emergency Services IP network. I don't want to see it prohibited. I think it IS a good idea to give emergency calls signaling priority in both the UA to proxy and proxy to ESInet legs. However, whether those networks do that is up to them. It's certainly not wrong for the UAC to ask for priority. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Saturday, January 03, 2009 5:57 PM To: 'ECRIT' Subject: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00.txt: Scope (again) (this time with my co-chair hat on) Hi all, I reviewed the past presentations of RPH from IETF#72, IETF#70, and IETF#67. You can listen into the audio recording yourself -- quite interesting. http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf67ch4-tue-noo n.mp3 http://limestone.uoregon.edu/ftp/pub/videolab/video/ietf70/ietf70-ch1-tue-af noon-ecrit-dime-avt.mp3 http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/ietf72-ch6-tue-no on.mp3 An essentially issue, as it appears in the entire discussion, is the question of applicability -- where should this SOS RPH mechanism be used. There are at the following possible cases: (a) UA to VSP (b) VSP to PSAP (potentially via another VSP) (c) Within the emergency services network (including PSAP to first responders) (d) PSAP callback I briefly summarize the feedback the group got at those meetings: -- IETF#67 A lot of the discussion focus on the name of the namespace, i.e. a syntactic issue. Jonathan, Henning, and Ted argue that the usage of RPH particularly for scenario (a) is not a good idea. Janet, James, and Brian like the idea of using RPH for use case (a), (b), and (c). (I am not sure about everyone's position regarding (d)). Brian Stucker believes that RPH is OK for usage for scenario (d). He argues that the authorization problem is simpler to solve with that scenario. -- IETF#70 Keith, James and Brian like the document. Brian, for example, says that it is very useful within an IP public safety communication network, i.e., scenario (c). He also thinks that it is useful outside of it in a public network. Jon, Richard, and Henning have concerns regarding the usage of RPH for things other than scenario (c). Particularly scenario (a) seems to be problematic. I also voiced my opinion during that meeting against usage of RPH for scenario (a). THIS IS IMPORTANT: At the end of the meeting James asks Henning whether he would be happy with the document if the focus is only on using SOS RPH within the emergency services network, i.e., scenario (c). Henning says that this is fine for him as it reassembles much better the intention of RPH. James promises to update the document to reflect this restricted scope. I checked subsequent draft versions: No scope change in any form. -- IETF#72 We did not really discuss the document as such. We only asked for a HUM assuming that folks were aware of the current document version. For some reason I must have had the discussions in mind that happened at IETF#70 where the scope limitation of the draft got discussed. As such, my mail to the list http://www.ietf.org/mail-archive/web/ecrit/current/msg05665.html was, I believe, not completely off topic. Although I did not recall who had raised objections in previous meetings when I wrote my ECRIT WG status update I think that as a WG co-chair it is fair to hear the opinion of those again that had previously raised concerns. Maybe they changed their mind and are now in favor of using RPH for scenario (a). Could be possible. Reading through the mail discussions, the drafts and listening to the meeting recordings helped me again to refresh my memory regarding the purpose of RPH for scenario (c). Hope that this was a useful investigation. Ciao Hannes PS: I also noticed that the justification for the work, as mentioned on the presentation slides, seems to be "Brian sez NENA wants it", see: http://www.ietf.org/proceedings/07dec/slides/ecrit-2/sld2.htm http://www.ietf.org/proceedings/06nov/slides/ecrit-7/sld3.htm It is good that our work finds excitement in other SDOs and groups. Given that NENA focuses largely on the emergency services network itself rather than on the end host to VSP exchanges, I guess it would have been nice to have a better idea what the detailed requirements are. At the IETF#70 presentation James furthermore mentions that scenario (b) could be useful in an 3GPP IMS context. I have to check whether there is interest to use RPH there and for what exactly. _______________________________________________ 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 Jan 5 09:00:24 2009 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 072853A6856; Mon, 5 Jan 2009 09:00:24 -0800 (PST) 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 305713A6856 for ; Mon, 5 Jan 2009 09:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.419 X-Spam-Level: X-Spam-Status: No, score=-5.419 tagged_above=-999 required=5 tests=[AWL=-1.120, 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 OFd106FPfJrx for ; Mon, 5 Jan 2009 09:00:22 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 18F3F3A63D2 for ; Mon, 5 Jan 2009 09:00:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,332,1228089600"; d="scan'208";a="119726784" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 05 Jan 2009 17:00:09 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n05H093J013674; Mon, 5 Jan 2009 09:00:09 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n05H09xI011399; Mon, 5 Jan 2009 17:00:09 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, 5 Jan 2009 09:00:09 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.17.209]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 09:00:08 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 05 Jan 2009 11:00:07 -0600 To: "Brian Rosen" , "'Hannes Tschofenig'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" From: "James M. Polk" In-Reply-To: <041801c96f4c$e63c29f0$b2b47dd0$@net> References: <007501c96dd1$1b5ecd40$0201a8c0@nsnintra.net> <041801c96f4c$e63c29f0$b2b47dd0$@net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 05 Jan 2009 17:00:08.0875 (UTC) FILETIME=[10A35FB0:01C96F57] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5699; t=1231174809; x=1232038809; c=relaxed/simple; s=sjdkim2002; 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]=20PSAP=20Call=20Backs |Sender:=20; bh=HQGJFbWo3H0cfW/Vtwz6KHctef+flj+P0Vevds/+s9o=; b=xl9hJItAxzOoSaKQSPkrWaGhkXpvlCeYHPFDFMqOolC3Fil5LDaaGn5Jzk yBqceNY0FndhQ7IADwU7LU74oku28AaMHArg6HmNPou72YLKND2NmvhRAMPv 2jeshb1al2; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Ecrit] PSAP Call Backs 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 09:47 AM 1/5/2009, Brian Rosen wrote: >I would have said that we decide if callbacks should have special treatment >of any kind. > >If we decide that they should, then we decide how we will mark them, and >then what the behavior is for that marking. > >Please do not confuse the resource priority marking and behavior with this >discussion. As with the emergency call marking (urn:service:sos in Route), >and the associated behaviors in PhoneBCP, the RPH is an independent marking >and behavior specification. If we mark call backs, it won't be with RPH. A >callback MAY also have an RPH marking, and there could be behavior >associated with that with respect to priority handling within a network. >Similarly, the packets of a callback could have a DiffServ marking, and >behavior associates with that marking within a network. I (again) agree with all of the above (which has been said over and over again). >I think we should have a call back marking, and we should specify behaviors >for that marking. I'm on the fence about callback marking, mostly because I believe there is an unpredictable path back to the original UAC, and even if marked, do we know the receiving proxies or UAC will have any awareness of this marking? If not, why have this discussion and complexity attempting to elicit a marking and associated behavior that falls on deaf ears? >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >Hannes Tschofenig >Sent: Saturday, January 03, 2009 1:29 PM >To: 'James M. Polk'; Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' >Subject: Re: [Ecrit] PSAP Call Backs > >There are two different aspects: > >A) A decision that decides whether a call back has to be marked or not > >B) When the decision is made that is has to be marked then how the marking >is going to look like. > >Regarding (A): This might be a policy issues. Some PSAPs might want to use >this indication and others might not. Nothing we have to worry about. > >Regarding (B): Here there needs to be one way todo the marking -- not >multiple ways. It would just increase the implementation complexity, the >number of error cases and interop problems. > >I am not sure to what your "MAY" statement refers to -- to (A) or (B). > >Ciao >Hannes > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of James M. Polk > >Sent: 02 January, 2009 22:15 > >To: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > >Subject: Re: [Ecrit] PSAP Call Backs > > > >At 04:21 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >>Hi all, > >> > >>In the last few months we have seen increased interest in the > >topic of > >>PSAP call backs. > >> > >>Section 10 of http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-06 > >>says: > >> > >> SP-36 Call backs to the Contact: header URI recieved within 30 > >> minutes of an emergency call must reach the device > >regardless of call > >> features or services that would normally cause the call > >to be routed > >> to some other entity. > >> > >>More importantly, Section 13 says: > >> > >> ED-73 Call backs SHOULD be determined by retaining the > >domain of the > >> PSAP which answers an outgoing emergency call and instantiating a > >> timer which starts when the call is terminated. If a call is > >> received from the same domain and within the timer period, sent to > >> the Contact: or AoR used in the emergency call, it should > >be assumed > >> to be a call back. The suggested timer period is 5 minutes. > >> > >>http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt > >>proposed another solution based on marking the callback using > >the "sos" > >>URI parameter. > >> > >>http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-local-emergenc > >y-rph-nam > >>e space/ proposes another solution by utilizing the Resource Priority > >>Header. > > > >within the namespace ID, the total thought (for PSAP callback) is here: > > > > This namespace will also be used > > for communications between emergency authorities, and MAY be used > > for emergency authorities calling public citizens. An example of > > the later is a PSAP operator calling back someone who previously > > called 9111/112/999 and the communication was terminated before it > > should have been (in the operator's judgment). > > > >Notice this is all based on the MAY in the first sentence, > >therefore it can be considered an afterthought, i.e., > >something that can be utilized/specified later. > > > >the "sos" parameter solution is more definitive, yet it should > >identify a priority marking (in SIP), given that there is > >already a defined way to do that in SIP, and a second way > >shouldn't be defined > >- as it will only lead to interoperability issues. > > > > > >>So, here are my high-level questions: > >> > >>A) Do you think that you understand the requirements that lead to a > >>need for a technical solution? > >> > >>B) Do you believe that more work beyond the mechanism described in > >>Phone BCP is needed? > >> > >>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 > > > >_______________________________________________ >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 Jan 5 11:08:44 2009 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 B5C223A6A30; Mon, 5 Jan 2009 11:08:44 -0800 (PST) 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 264433A6A30 for ; Mon, 5 Jan 2009 11:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 WB3gQWzW4dxb for ; Mon, 5 Jan 2009 11:08:43 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id A0EDF3A69D1 for ; Mon, 5 Jan 2009 11:08:42 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n05J7qdM007279 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jan 2009 20:07:53 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 5 Jan 2009 20:07:52 +0100 From: "DRAGE, Keith (Keith)" To: Brian Rosen , "'Hannes Tschofenig'" , "'James M. Polk'" , "'Tschofenig, Hannes (NSN - FI/Espoo)'" , "'ECRIT'" Date: Mon, 5 Jan 2009 20:07:51 +0100 Thread-Topic: [Ecrit] PSAP Call Backs Thread-Index: AcltFtXFMn8qyHKdSCO7B7iBHlGTAAAuajmwAFtIfkAACrDqUA== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67481999F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <007501c96dd1$1b5ecd40$0201a8c0@nsnintra.net> <041801c96f4c$e63c29f0$b2b47dd0$@net> In-Reply-To: <041801c96f4c$e63c29f0$b2b47dd0$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [Ecrit] PSAP Call Backs 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 I agree with what Brian is saying here, but I would turn the statement round. We should decide what special behaviours callback calls required, and then identify the appropriate means of signalling to generate that behaviour. That means if we identify that callback calls need special treatment in the network, then RPH may be the way to do it. If we want to override incoming call bahaviour in the destination UA, then we find an appropriate way of doing that (along with a security solution to prevent misuse. I though we had decided to deal with callback issues with a separate requirements draft. As such I would support taking out callback text from all documents at the moment, not with the idea that that might not be the solution, but that we come up with a complete package of solutions in the future. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Monday, January 05, 2009 3:47 PM > To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, Hannes > (NSN - FI/Espoo)'; 'ECRIT' > Subject: Re: [Ecrit] PSAP Call Backs > > I would have said that we decide if callbacks should have > special treatment of any kind. > > If we decide that they should, then we decide how we will > mark them, and then what the behavior is for that marking. > > Please do not confuse the resource priority marking and > behavior with this discussion. As with the emergency call > marking (urn:service:sos in Route), and the associated > behaviors in PhoneBCP, the RPH is an independent marking and > behavior specification. If we mark call backs, it won't be > with RPH. A callback MAY also have an RPH marking, and there > could be behavior associated with that with respect to > priority handling within a network. > Similarly, the packets of a callback could have a DiffServ > marking, and behavior associates with that marking within a network. > > I think we should have a call back marking, and we should > specify behaviors for that marking. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Hannes Tschofenig > Sent: Saturday, January 03, 2009 1:29 PM > To: 'James M. Polk'; Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' > Subject: Re: [Ecrit] PSAP Call Backs > > There are two different aspects: > > A) A decision that decides whether a call back has to be marked or not > > B) When the decision is made that is has to be marked then > how the marking is going to look like. > > Regarding (A): This might be a policy issues. Some PSAPs > might want to use this indication and others might not. > Nothing we have to worry about. > > Regarding (B): Here there needs to be one way todo the > marking -- not multiple ways. It would just increase the > implementation complexity, the number of error cases and > interop problems. > > I am not sure to what your "MAY" statement refers to -- to > (A) or (B). > > Ciao > Hannes > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf > >Of James M. Polk > >Sent: 02 January, 2009 22:15 > >To: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > >Subject: Re: [Ecrit] PSAP Call Backs > > > >At 04:21 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >>Hi all, > >> > >>In the last few months we have seen increased interest in the > >topic of > >>PSAP call backs. > >> > >>Section 10 of > http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-06 > >>says: > >> > >> SP-36 Call backs to the Contact: header URI recieved within 30 > >> minutes of an emergency call must reach the device > >regardless of call > >> features or services that would normally cause the call > >to be routed > >> to some other entity. > >> > >>More importantly, Section 13 says: > >> > >> ED-73 Call backs SHOULD be determined by retaining the > >domain of the > >> PSAP which answers an outgoing emergency call and > instantiating a > >> timer which starts when the call is terminated. If a call is > >> received from the same domain and within the timer > period, sent to > >> the Contact: or AoR used in the emergency call, it should > >be assumed > >> to be a call back. The suggested timer period is 5 minutes. > >> > >>http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt > >>proposed another solution based on marking the callback using > >the "sos" > >>URI parameter. > >> > >>http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-local-emergenc > >y-rph-nam > >>e space/ proposes another solution by utilizing the > Resource Priority > >>Header. > > > >within the namespace ID, the total thought (for PSAP > callback) is here: > > > > This namespace will also be used > > for communications between emergency authorities, and MAY be used > > for emergency authorities calling public citizens. An example of > > the later is a PSAP operator calling back someone who previously > > called 9111/112/999 and the communication was terminated before it > > should have been (in the operator's judgment). > > > >Notice this is all based on the MAY in the first sentence, > therefore it > >can be considered an afterthought, i.e., something that can be > >utilized/specified later. > > > >the "sos" parameter solution is more definitive, yet it > should identify > >a priority marking (in SIP), given that there is already a > defined way > >to do that in SIP, and a second way shouldn't be defined > >- as it will only lead to interoperability issues. > > > > > >>So, here are my high-level questions: > >> > >>A) Do you think that you understand the requirements that lead to a > >>need for a technical solution? > >> > >>B) Do you believe that more work beyond the mechanism described in > >>Phone BCP is needed? > >> > >>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 > > > > _______________________________________________ > 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 Jan 5 11:17:46 2009 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 BEA613A6957; Mon, 5 Jan 2009 11:17:46 -0800 (PST) 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 983C53A6957 for ; Mon, 5 Jan 2009 11:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.955 X-Spam-Level: X-Spam-Status: No, score=-4.955 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_SIDE=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 9zvTN92YuAQS for ; Mon, 5 Jan 2009 11:17:44 -0800 (PST) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id DBBFB3A6937 for ; Mon, 5 Jan 2009 11:17:43 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n05JHOJB000329 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jan 2009 20:17:25 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 5 Jan 2009 20:17:24 +0100 From: "DRAGE, Keith (Keith)" To: Brian Rosen , "'Hannes Tschofenig'" , "'ECRIT'" Date: Mon, 5 Jan 2009 20:17:23 +0100 Thread-Topic: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00.txt: Scope (again) Thread-Index: Aclt9p9TPgOdca6kQjSRx848oPqtAABVqniAAAc0pNA= Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6748199A2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <007f01c96df6$9fcfade0$0201a8c0@nsnintra.net> <042d01c96f4e$2bca24d0$835e6e70$@net> In-Reply-To: <042d01c96f4e$2bca24d0$835e6e70$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00.txt: Scope (again) 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 Agree with Brian. I certainly would not want to preclude the usage in a public network, and I believe the RFC has all the words needed to cover the interoperation with the Emergency services IP network. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Monday, January 05, 2009 3:56 PM > To: 'Hannes Tschofenig'; 'ECRIT' > Subject: Re: [Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt: Scope (again) > > There is very little downside to allowing the marking to be > used in any network. It's the behaviors that are implied by > the marking that you care about. In a public network, there > may not be any behaviors associated with the marking, while > in an Emergency Services IP Network, there most certainly will be. > > The document in question doesn't really address behavior, and > it shouldn't. > NENA would specify behaviors within the networks it > standardizes, and is in a much better position to do that. > What we need is a namespace. > > You can qualify it if you want: "MAY" is good enough in the > origination network and the interconnect between the > origination network and the Emergency Services IP network. I > don't want to see it prohibited. I think it IS a good idea > to give emergency calls signaling priority in both the UA to > proxy and proxy to ESInet legs. However, whether those > networks do that is up to them. It's certainly not wrong for > the UAC to ask for priority. > > Brian > > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Hannes Tschofenig > Sent: Saturday, January 03, 2009 5:57 PM > To: 'ECRIT' > Subject: [Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt: > Scope (again) > > (this time with my co-chair hat on) > > Hi all, > > I reviewed the past presentations of RPH from IETF#72, > IETF#70, and IETF#67. > You can listen into the audio recording yourself -- quite > interesting. > http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/iet > f67ch4-tue-noo > n.mp3 > http://limestone.uoregon.edu/ftp/pub/videolab/video/ietf70/iet > f70-ch1-tue-af > noon-ecrit-dime-avt.mp3 > http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/iet > f72-ch6-tue-no > on.mp3 > > An essentially issue, as it appears in the entire discussion, > is the question of applicability -- where should this SOS RPH > mechanism be used. > There are at the following possible cases: > > (a) UA to VSP > (b) VSP to PSAP (potentially via another VSP) > (c) Within the emergency services network (including PSAP to first > responders) > (d) PSAP callback > > I briefly summarize the feedback the group got at those meetings: > > -- IETF#67 > > A lot of the discussion focus on the name of the namespace, > i.e. a syntactic issue. > Jonathan, Henning, and Ted argue that the usage of RPH > particularly for scenario (a) is not a good idea. > > Janet, James, and Brian like the idea of using RPH for use > case (a), (b), and (c). (I am not sure about everyone's > position regarding (d)). > > Brian Stucker believes that RPH is OK for usage for scenario > (d). He argues that the authorization problem is simpler to > solve with that scenario. > > -- IETF#70 > > Keith, James and Brian like the document. Brian, for example, > says that it is very useful within an IP public safety > communication network, i.e., scenario (c). He also thinks > that it is useful outside of it in a public network. > > Jon, Richard, and Henning have concerns regarding the usage > of RPH for things other than scenario (c). Particularly > scenario (a) seems to be problematic. I also voiced my > opinion during that meeting against usage of RPH for scenario (a). > > THIS IS IMPORTANT: At the end of the meeting James asks > Henning whether he would be happy with the document if the > focus is only on using SOS RPH within the emergency services > network, i.e., scenario (c). Henning says that this is fine > for him as it reassembles much better the intention of RPH. > James promises to update the document to reflect this > restricted scope. I checked subsequent draft versions: No > scope change in any form. > > -- IETF#72 > > We did not really discuss the document as such. We only asked > for a HUM assuming that folks were aware of the current > document version. > > > For some reason I must have had the discussions in mind that > happened at IETF#70 where the scope limitation of the draft > got discussed. As such, my mail to the list > http://www.ietf.org/mail-archive/web/ecrit/current/msg05665.ht > ml was, I believe, not completely off topic. > > Although I did not recall who had raised objections in > previous meetings when I wrote my ECRIT WG status update I > think that as a WG co-chair it is fair to hear the opinion of > those again that had previously raised concerns. > Maybe they changed their mind and are now in favor of using > RPH for scenario (a). Could be possible. > > Reading through the mail discussions, the drafts and > listening to the meeting recordings helped me again to > refresh my memory regarding the purpose of RPH for scenario (c). > > Hope that this was a useful investigation. > > Ciao > Hannes > > PS: I also noticed that the justification for the work, as > mentioned on the presentation slides, seems to be "Brian sez > NENA wants it", see: > http://www.ietf.org/proceedings/07dec/slides/ecrit-2/sld2.htm > http://www.ietf.org/proceedings/06nov/slides/ecrit-7/sld3.htm > > It is good that our work finds excitement in other SDOs and > groups. Given that NENA focuses largely on the emergency > services network itself rather than on the end host to VSP > exchanges, I guess it would have been nice to have a better > idea what the detailed requirements are. At the IETF#70 > presentation James furthermore mentions that scenario (b) > could be useful in an 3GPP IMS context. I have to check > whether there is interest to use RPH there and for what exactly. > > _______________________________________________ > 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 Jan 5 11:40:24 2009 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 13F653A69E0; Mon, 5 Jan 2009 11:40:24 -0800 (PST) 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 5AD553A6925 for ; Mon, 5 Jan 2009 11:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 2URyrsA1bZQY for ; Mon, 5 Jan 2009 11:40:21 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3C2CF3A68E1 for ; Mon, 5 Jan 2009 11:40:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,333,1228089600"; d="scan'208";a="58266487" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2009 19:20:19 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n05JKIma017745; Mon, 5 Jan 2009 11:20:18 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n05JKIQn022147; Mon, 5 Jan 2009 19:20:18 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, 5 Jan 2009 11:20:17 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.17.209]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 11:20:16 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 05 Jan 2009 13:20:15 -0600 To: "DRAGE, Keith (Keith)" , Brian Rosen , "'Hannes Tschofenig'" , "'Tschofenig, Hannes (NSN - FI/Espoo)'" , "'ECRIT'" From: "James M. Polk" In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D67481999F@FRMRSSXCHMBSB3.dc -m.alcatel-lucent.com> References: <007501c96dd1$1b5ecd40$0201a8c0@nsnintra.net> <041801c96f4c$e63c29f0$b2b47dd0$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67481999F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 05 Jan 2009 19:20:16.0883 (UTC) FILETIME=[A4339430:01C96F6A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7030; t=1231183219; x=1232047219; 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]=20PSAP=20Call=20Backs |Sender:=20; bh=D2mrdsDt72+d/geuLxqtrLDsGfHtgVRerMKqE0gB83s=; b=NqXVWOeAzFhZRuoWsTxWEuEcR3uR7eL2ggQVrR032jnBMnh7TQnNb54B2/ TrlYH4jW6h318on/2M9fEnCJXslOUxBCpMFvbVuffpUUpwAeQHTdbEcCA3fT lc57SeF27F3NbST5/freyC5gaB9JN+3vOWEtdaxe0NboL7vDmFJX8=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] PSAP Call Backs 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:07 PM 1/5/2009, DRAGE, Keith (Keith) wrote: >I think I agree with what Brian is saying here, but I would turn the >statement round. > >We should decide what special behaviours callback calls required, >and then identify the appropriate means of signalling to generate >that behaviour. > >That means if we identify that callback calls need special treatment >in the network, then RPH may be the way to do it. If we want to >override incoming call bahaviour in the destination UA, then we find >an appropriate way of doing that (along with a security solution to >prevent misuse. > >I though we had decided to deal with callback issues with a separate >requirements draft. As such I would support taking out callback text >from all documents at the moment, not with the idea that that might >not be the solution, but that we come up with a complete package of >solutions in the future. I think this is appropriate >regards > >Keith > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Brian Rosen > > Sent: Monday, January 05, 2009 3:47 PM > > To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, Hannes > > (NSN - FI/Espoo)'; 'ECRIT' > > Subject: Re: [Ecrit] PSAP Call Backs > > > > I would have said that we decide if callbacks should have > > special treatment of any kind. > > > > If we decide that they should, then we decide how we will > > mark them, and then what the behavior is for that marking. > > > > Please do not confuse the resource priority marking and > > behavior with this discussion. As with the emergency call > > marking (urn:service:sos in Route), and the associated > > behaviors in PhoneBCP, the RPH is an independent marking and > > behavior specification. If we mark call backs, it won't be > > with RPH. A callback MAY also have an RPH marking, and there > > could be behavior associated with that with respect to > > priority handling within a network. > > Similarly, the packets of a callback could have a DiffServ > > marking, and behavior associates with that marking within a network. > > > > I think we should have a call back marking, and we should > > specify behaviors for that marking. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Hannes Tschofenig > > Sent: Saturday, January 03, 2009 1:29 PM > > To: 'James M. Polk'; Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' > > Subject: Re: [Ecrit] PSAP Call Backs > > > > There are two different aspects: > > > > A) A decision that decides whether a call back has to be marked or not > > > > B) When the decision is made that is has to be marked then > > how the marking is going to look like. > > > > Regarding (A): This might be a policy issues. Some PSAPs > > might want to use this indication and others might not. > > Nothing we have to worry about. > > > > Regarding (B): Here there needs to be one way todo the > > marking -- not multiple ways. It would just increase the > > implementation complexity, the number of error cases and > > interop problems. > > > > I am not sure to what your "MAY" statement refers to -- to > > (A) or (B). > > > > Ciao > > Hannes > > > > > > >-----Original Message----- > > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf > > >Of James M. Polk > > >Sent: 02 January, 2009 22:15 > > >To: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > > >Subject: Re: [Ecrit] PSAP Call Backs > > > > > >At 04:21 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > >>Hi all, > > >> > > >>In the last few months we have seen increased interest in the > > >topic of > > >>PSAP call backs. > > >> > > >>Section 10 of > > http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-06 > > >>says: > > >> > > >> SP-36 Call backs to the Contact: header URI recieved within 30 > > >> minutes of an emergency call must reach the device > > >regardless of call > > >> features or services that would normally cause the call > > >to be routed > > >> to some other entity. > > >> > > >>More importantly, Section 13 says: > > >> > > >> ED-73 Call backs SHOULD be determined by retaining the > > >domain of the > > >> PSAP which answers an outgoing emergency call and > > instantiating a > > >> timer which starts when the call is terminated. If a call is > > >> received from the same domain and within the timer > > period, sent to > > >> the Contact: or AoR used in the emergency call, it should > > >be assumed > > >> to be a call back. The suggested timer period is 5 minutes. > > >> > > >>http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt > > >>proposed another solution based on marking the callback using > > >the "sos" > > >>URI parameter. > > >> > > >>http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-local-emergenc > > >y-rph-nam > > >>e space/ proposes another solution by utilizing the > > Resource Priority > > >>Header. > > > > > >within the namespace ID, the total thought (for PSAP > > callback) is here: > > > > > > This namespace will also be used > > > for communications between emergency authorities, and MAY be used > > > for emergency authorities calling public citizens. An example of > > > the later is a PSAP operator calling back someone who previously > > > called 9111/112/999 and the communication was terminated before it > > > should have been (in the operator's judgment). > > > > > >Notice this is all based on the MAY in the first sentence, > > therefore it > > >can be considered an afterthought, i.e., something that can be > > >utilized/specified later. > > > > > >the "sos" parameter solution is more definitive, yet it > > should identify > > >a priority marking (in SIP), given that there is already a > > defined way > > >to do that in SIP, and a second way shouldn't be defined > > >- as it will only lead to interoperability issues. > > > > > > > > >>So, here are my high-level questions: > > >> > > >>A) Do you think that you understand the requirements that lead to a > > >>need for a technical solution? > > >> > > >>B) Do you believe that more work beyond the mechanism described in > > >>Phone BCP is needed? > > >> > > >>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 > > > > > > > _______________________________________________ > > 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 Jan 5 12:04:34 2009 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 31A8028C115; Mon, 5 Jan 2009 12:04:34 -0800 (PST) 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 173A73A69E0; Mon, 5 Jan 2009 12:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.873 X-Spam-Level: X-Spam-Status: No, score=-4.873 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SIDE=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 ds144OMOdz8x; Mon, 5 Jan 2009 12:04:31 -0800 (PST) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by core3.amsl.com (Postfix) with ESMTP id C1A473A6822; Mon, 5 Jan 2009 12:04:30 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-6.tower-85.messagelabs.com!1231185854!4972897!3 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 9536 invoked from network); 5 Jan 2009 20:04:16 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-6.tower-85.messagelabs.com with AES256-SHA encrypted SMTP; 5 Jan 2009 20:04:16 -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 n05K4EKb026380; Mon, 5 Jan 2009 15:04:15 -0500 In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D6748199A2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Mon, 5 Jan 2009 15:04:07 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 01/05/2009 03:06:40 PM, Serialize complete at 01/05/2009 03:06:40 PM Cc: ecrit-bounces@ietf.org, 'ECRIT' Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00.txt: Scope (again) 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="===============1612643890==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1612643890== Content-Type: multipart/alternative; boundary="=_alternative 006E3EC285257535_=" This is a multipart message in MIME format. --=_alternative 006E3EC285257535_= Content-Type: text/plain; charset="US-ASCII" I also agree. There is quite a lot of text in 4412 about "passing" RPH (without providing any special behavior) across a network that "doesn't understand" that namespace to/from a network that does understand/provide special behavior to that namespace. Perhaps that could be stressed a bit more in the text of this ID. This ID does not need to go into detail about which networks are expected to "understand" and which to "ignore" the namespace. Janet ecrit-bounces@ietf.org wrote on 01/05/2009 02:17:23 PM: > Agree with Brian. > > I certainly would not want to preclude the usage in a public > network, and I believe the RFC has all the words needed to cover the > interoperation with the Emergency services IP network. > > regards > > Keith > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Brian Rosen > > Sent: Monday, January 05, 2009 3:56 PM > > To: 'Hannes Tschofenig'; 'ECRIT' > > Subject: Re: [Ecrit] > > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt: Scope (again) > > > > There is very little downside to allowing the marking to be > > used in any network. It's the behaviors that are implied by > > the marking that you care about. In a public network, there > > may not be any behaviors associated with the marking, while > > in an Emergency Services IP Network, there most certainly will be. > > > > The document in question doesn't really address behavior, and > > it shouldn't. > > NENA would specify behaviors within the networks it > > standardizes, and is in a much better position to do that. > > What we need is a namespace. > > > > You can qualify it if you want: "MAY" is good enough in the > > origination network and the interconnect between the > > origination network and the Emergency Services IP network. I > > don't want to see it prohibited. I think it IS a good idea > > to give emergency calls signaling priority in both the UA to > > proxy and proxy to ESInet legs. However, whether those > > networks do that is up to them. It's certainly not wrong for > > the UAC to ask for priority. > > > > Brian > > > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Hannes Tschofenig > > Sent: Saturday, January 03, 2009 5:57 PM > > To: 'ECRIT' > > Subject: [Ecrit] > > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt: > > Scope (again) > > > > (this time with my co-chair hat on) > > > > Hi all, > > > > I reviewed the past presentations of RPH from IETF#72, > > IETF#70, and IETF#67. > > You can listen into the audio recording yourself -- quite > > interesting. > > http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/iet > > f67ch4-tue-noo > > n.mp3 > > http://limestone.uoregon.edu/ftp/pub/videolab/video/ietf70/iet > > f70-ch1-tue-af > > noon-ecrit-dime-avt.mp3 > > http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/iet > > f72-ch6-tue-no > > on.mp3 > > > > An essentially issue, as it appears in the entire discussion, > > is the question of applicability -- where should this SOS RPH > > mechanism be used. > > There are at the following possible cases: > > > > (a) UA to VSP > > (b) VSP to PSAP (potentially via another VSP) > > (c) Within the emergency services network (including PSAP to first > > responders) > > (d) PSAP callback > > > > I briefly summarize the feedback the group got at those meetings: > > > > -- IETF#67 > > > > A lot of the discussion focus on the name of the namespace, > > i.e. a syntactic issue. > > Jonathan, Henning, and Ted argue that the usage of RPH > > particularly for scenario (a) is not a good idea. > > > > Janet, James, and Brian like the idea of using RPH for use > > case (a), (b), and (c). (I am not sure about everyone's > > position regarding (d)). > > > > Brian Stucker believes that RPH is OK for usage for scenario > > (d). He argues that the authorization problem is simpler to > > solve with that scenario. > > > > -- IETF#70 > > > > Keith, James and Brian like the document. Brian, for example, > > says that it is very useful within an IP public safety > > communication network, i.e., scenario (c). He also thinks > > that it is useful outside of it in a public network. > > > > Jon, Richard, and Henning have concerns regarding the usage > > of RPH for things other than scenario (c). Particularly > > scenario (a) seems to be problematic. I also voiced my > > opinion during that meeting against usage of RPH for scenario (a). > > > > THIS IS IMPORTANT: At the end of the meeting James asks > > Henning whether he would be happy with the document if the > > focus is only on using SOS RPH within the emergency services > > network, i.e., scenario (c). Henning says that this is fine > > for him as it reassembles much better the intention of RPH. > > James promises to update the document to reflect this > > restricted scope. I checked subsequent draft versions: No > > scope change in any form. > > > > -- IETF#72 > > > > We did not really discuss the document as such. We only asked > > for a HUM assuming that folks were aware of the current > > document version. > > > > > > For some reason I must have had the discussions in mind that > > happened at IETF#70 where the scope limitation of the draft > > got discussed. As such, my mail to the list > > http://www.ietf.org/mail-archive/web/ecrit/current/msg05665.ht > > ml was, I believe, not completely off topic. > > > > Although I did not recall who had raised objections in > > previous meetings when I wrote my ECRIT WG status update I > > think that as a WG co-chair it is fair to hear the opinion of > > those again that had previously raised concerns. > > Maybe they changed their mind and are now in favor of using > > RPH for scenario (a). Could be possible. > > > > Reading through the mail discussions, the drafts and > > listening to the meeting recordings helped me again to > > refresh my memory regarding the purpose of RPH for scenario (c). > > > > Hope that this was a useful investigation. > > > > Ciao > > Hannes > > > > PS: I also noticed that the justification for the work, as > > mentioned on the presentation slides, seems to be "Brian sez > > NENA wants it", see: > > http://www.ietf.org/proceedings/07dec/slides/ecrit-2/sld2.htm > > http://www.ietf.org/proceedings/06nov/slides/ecrit-7/sld3.htm > > > > It is good that our work finds excitement in other SDOs and > > groups. Given that NENA focuses largely on the emergency > > services network itself rather than on the end host to VSP > > exchanges, I guess it would have been nice to have a better > > idea what the detailed requirements are. At the IETF#70 > > presentation James furthermore mentions that scenario (b) > > could be useful in an 3GPP IMS context. I have to check > > whether there is interest to use RPH there and for what exactly. > > > > _______________________________________________ > > 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 --=_alternative 006E3EC285257535_= Content-Type: text/html; charset="US-ASCII"


I also agree.  There is quite a lot of text in 4412 about "passing" RPH (without providing any special behavior)  across a network that "doesn't understand" that namespace to/from a network that does understand/provide special behavior to that namespace.  Perhaps that could be stressed a bit more in the text of this ID.  This ID does not need to go into detail about which networks are expected to "understand" and which to "ignore" the namespace.

Janet

ecrit-bounces@ietf.org wrote on 01/05/2009 02:17:23 PM:

> Agree with Brian.
>
> I certainly would not want to preclude the usage in a public
> network, and I believe the RFC has all the words needed to cover the
> interoperation with the Emergency services IP network.
>
> regards
>
> Keith
>
> > -----Original Message-----
> > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]
> > On Behalf Of Brian Rosen
> > Sent: Monday, January 05, 2009 3:56 PM
> > To: 'Hannes Tschofenig'; 'ECRIT'
> > Subject: Re: [Ecrit]
> > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt: Scope (again)
> >
> > There is very little downside to allowing the marking to be
> > used in any network.  It's the behaviors that are implied by
> > the marking that you care about.  In a public network, there
> > may not be any behaviors associated with the marking, while
> > in an Emergency Services IP Network, there most certainly will be.
> >
> > The document in question doesn't really address behavior, and
> > it shouldn't.
> > NENA would specify behaviors within the networks it
> > standardizes, and is in a much better position to do that.  
> > What we need is a namespace.
> >
> > You can qualify it if you want: "MAY" is good enough in the
> > origination network and the interconnect between the
> > origination network and the Emergency Services IP network.  I
> > don't want to see it prohibited.  I think it IS a good idea
> > to give emergency calls signaling priority in both the UA to
> > proxy and proxy to ESInet legs.  However, whether those
> > networks do that is up to them.  It's certainly not wrong for
> > the UAC to ask for priority.
> >
> > Brian
> >
> >
> >
> > -----Original Message-----
> > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]
> > On Behalf Of Hannes Tschofenig
> > Sent: Saturday, January 03, 2009 5:57 PM
> > To: 'ECRIT'
> > Subject: [Ecrit]
> > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt:
> > Scope (again)
> >
> > (this time with my co-chair hat on)
> >
> > Hi all,
> >
> > I reviewed the past presentations of RPH from IETF#72,
> > IETF#70, and IETF#67.
> > You can listen into the audio recording yourself -- quite
> > interesting.
> > http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/iet
> > f67ch4-tue-noo
> > n.mp3
> > http://limestone.uoregon.edu/ftp/pub/videolab/video/ietf70/iet
> > f70-ch1-tue-af
> > noon-ecrit-dime-avt.mp3
> > http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/iet
> > f72-ch6-tue-no
> > on.mp3
> >
> > An essentially issue, as it appears in the entire discussion,
> > is the question of applicability -- where should this SOS RPH
> > mechanism be used.
> > There are at the following possible cases:
> >
> >   (a) UA to VSP
> >   (b) VSP to PSAP (potentially via another VSP)
> >   (c) Within the emergency services network (including PSAP to first
> > responders)
> >   (d) PSAP callback  
> >
> > I briefly summarize the feedback the group got at those meetings:
> >
> >  -- IETF#67
> >
> > A lot of the discussion focus on the name of the namespace,
> > i.e. a syntactic issue.
> > Jonathan, Henning, and Ted argue that the usage of RPH
> > particularly for scenario (a) is not a good idea.
> >
> > Janet, James, and Brian like the idea of using RPH for use
> > case (a), (b), and (c). (I am not sure about everyone's
> > position regarding (d)).
> >
> > Brian Stucker believes that RPH is OK for usage for scenario
> > (d). He argues that the authorization problem is simpler to
> > solve with that scenario.
> >
> >  -- IETF#70
> >
> > Keith, James and Brian like the document. Brian, for example,
> > says that it is very useful within an IP public safety
> > communication network, i.e., scenario (c). He also thinks
> > that it is useful outside of it in a public network.
> >
> > Jon, Richard, and Henning have concerns regarding the usage
> > of RPH for things other than scenario (c). Particularly
> > scenario (a) seems to be problematic. I also voiced my
> > opinion during that meeting against usage of RPH for scenario (a).
> >
> > THIS IS IMPORTANT: At the end of the meeting James asks
> > Henning whether he would be happy with the document if the
> > focus is only on using SOS RPH within the emergency services
> > network, i.e., scenario (c). Henning says that this is fine
> > for him as it reassembles much better the intention of RPH.
> > James promises to update the document to reflect this
> > restricted scope. I checked subsequent draft versions: No
> > scope change in any form.  
> >
> >  -- IETF#72
> >
> > We did not really discuss the document as such. We only asked
> > for a HUM assuming that folks were aware of the current
> > document version.
> >
> >
> > For some reason I must have had the discussions in mind that
> > happened at IETF#70 where the scope limitation of the draft
> > got discussed. As such, my mail to the list
> > http://www.ietf.org/mail-archive/web/ecrit/current/msg05665.ht
> > ml was, I believe, not completely off topic.
> >
> > Although I did not recall who had raised objections in
> > previous meetings when I wrote my ECRIT WG status update I
> > think that as a WG co-chair it is fair to hear the opinion of
> > those again that had previously raised concerns.
> > Maybe they changed their mind and are now in favor of using
> > RPH for scenario (a). Could be possible.
> >
> > Reading through the mail discussions, the drafts and
> > listening to the meeting recordings helped me again to
> > refresh my memory regarding the purpose of RPH for scenario (c).
> >
> > Hope that this was a useful investigation.
> >
> > Ciao
> > Hannes
> >
> > PS: I also noticed that the justification for the work, as
> > mentioned on the presentation slides, seems to be  "Brian sez
> > NENA wants it", see:
> > http://www.ietf.org/proceedings/07dec/slides/ecrit-2/sld2.htm
> > http://www.ietf.org/proceedings/06nov/slides/ecrit-7/sld3.htm
> >
> > It is good that our work finds excitement in other SDOs and
> > groups. Given that NENA focuses largely on the emergency
> > services network itself rather than on the end host to VSP
> > exchanges, I guess it would have been nice to have a better
> > idea what the detailed requirements are. At the IETF#70
> > presentation James furthermore mentions that scenario (b)
> > could be useful in an 3GPP IMS context. I have to check
> > whether there is interest to use RPH there and for what exactly.
> >
> > _______________________________________________
> > 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
 --=_alternative 006E3EC285257535_=-- --===============1612643890== 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 --===============1612643890==-- From ecrit-bounces@ietf.org Mon Jan 5 14:42:25 2009 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 C16203A68A5; Mon, 5 Jan 2009 14:42:25 -0800 (PST) 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 33B333A68A5 for ; Mon, 5 Jan 2009 14:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.027 X-Spam-Level: X-Spam-Status: No, score=-105.027 tagged_above=-999 required=5 tests=[AWL=1.572, 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 9RhIjWeJU9iW for ; Mon, 5 Jan 2009 14:42:24 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 3712F3A6784 for ; Mon, 5 Jan 2009 14:42:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1231195331; x=1262731331; 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<005001c96a85$a8b86060$0 201a8c0@nsnintra.net>|References:=20<005001c96a85$a8b8606 0$0201a8c0@nsnintra.net>|Date:=20Mon,=205=20Jan=202009=20 14:42:03=20-0800|To:=20Hannes=20Tschofenig=20,=20ECRIT=20|From:=20Ted =20Hardie=20|Subject:=20Re:=20[Ecrit ]=20HUM=20regarding=20draft-patel-ecrit-sos-parameter-02. txt|Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5486"=3B=20 a=3D"14395394"; bh=fnhOGmt3yJBvOPr1ypvcT7MRKGiH1c4CJws0mgoW5M4=; b=Nlt6qRLy/fLg2SyAkyACROnAa1gCxiBei1871VGsX+nvBLyDU7v9RlTj hqQa1zFtBXFHhYAnGX+Qp4dY8qgAR3Q+oEiBWEtenaB7yXS0Ky+dHNgUi jwxEpkAEQ08Z/9N9DlAHDNlwCjkO1LBhnjYwpJ9I+IbctD7j2YmZA5SCJ c=; X-IronPort-AV: E=McAfee;i="5300,2777,5486"; a="14395394" 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; 05 Jan 2009 14:42:09 -0800 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n05Mg9qK028382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Jan 2009 14:42:09 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n05Mg6AS018547 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jan 2009 14:42:06 -0800 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.336.0; Mon, 5 Jan 2009 14:42:06 -0800 Received: from [10.227.68.132] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 5 Jan 2009 14:42:05 -0800 MIME-Version: 1.0 Message-ID: In-Reply-To: <005001c96a85$a8b86060$0201a8c0@nsnintra.net> References: <005001c96a85$a8b86060$0201a8c0@nsnintra.net> Date: Mon, 5 Jan 2009 14:42:03 -0800 To: Hannes Tschofenig , ECRIT From: Ted Hardie Subject: Re: [Ecrit] HUM regarding draft-patel-ecrit-sos-parameter-02.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 5:51 AM -0800 12/30/08, Hannes Tschofenig wrote: >Hi all, > >At IETF#73 we had a discussion regarding >draft-patel-ecrit-sos-parameter-01.txt and the feedback that was provided >lead to an updated draft: >http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-02 > >This new document focuses on the "sos" registration only as described by >Milan in his recent mail to the list: >http://www.ietf.org/mail-archive/web/ecrit/current/msg05779.html > >This document is work we would be doing for the 3GPP. > >According to the meeting minutes there was positive support for working on >this document during IETF#73, see >http://www.ietf.org/proceedings/08nov/minutes/ecrit.txt. > >Please let me us know whether you have objections or whether you are in >support of this document (if you haven't stated your opinion already). > >Deadline: 16. Jan. 2009 > >Ciao >Hannes & Marc Since the document has changed, I'm not sure whether I'm already counted, so I'll chime in again: I think this is worth doing. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 5 14:50:26 2009 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 2DA9F3A6954; Mon, 5 Jan 2009 14:50:26 -0800 (PST) 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 3C3EE28C0D8 for ; Mon, 5 Jan 2009 14:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.981 X-Spam-Level: X-Spam-Status: No, score=-102.981 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 nEZEzbb6LIcV for ; Mon, 5 Jan 2009 14:50:24 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 8BB173A68A9 for ; Mon, 5 Jan 2009 14:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1231195812; x=1262731812; 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<041401c96f4c$d8fac300$8 af04900$@net>|References:=20<041401c96f4c$d8fac300$8af049 00$@net>|Date:=20Mon,=205=20Jan=202009=2014:50:07=20-0800 |To:=20Brian=20Rosen=20,=20"'ECRIT'" =20|From:=20Ted=20Hardie=20|Subject:=20Re:=20[Ecrit]=20FW:=20I-D=20=0D=0A=20A ction:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5486"=3B=20a =3D"14371118"; bh=u5TGCT+rECyaKCd9/cdurjdlSrUy1CZnmIRwG8LfmUU=; b=pZb6RFjM+WXCqaSxVt8RV0SHwestkJnLfyYe9/EmeUwx3rP7kAf+dJmF +puf2Lp4FCkcR7mvmSPH+h97ijXF5O5uLppDtsVPPx0rnaCSu98t3K0Fn 0O0HvHrod4DOi98N3TkQpghfkqQb9CICWaXxT1qncC26w00aYtatX6Tmr w=; X-IronPort-AV: E=McAfee;i="5100,188,5486"; a="14371118" 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; 05 Jan 2009 14:50:11 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n05MoBiO029468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Jan 2009 14:50:11 -0800 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n05MoAmb012937 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jan 2009 14:50:11 -0800 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 5 Jan 2009 14:50:10 -0800 Received: from [10.227.68.132] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 5 Jan 2009 14:50:09 -0800 MIME-Version: 1.0 Message-ID: In-Reply-To: <041401c96f4c$d8fac300$8af04900$@net> References: <041401c96f4c$d8fac300$8af04900$@net> Date: Mon, 5 Jan 2009 14:50:07 -0800 To: Brian Rosen , "'ECRIT'" From: Ted Hardie Subject: Re: [Ecrit] FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.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 Before my main comments, I note that the document says: The -phonebcp draft currently requires endpoints to disable sending a BYE on an emergency call. Insufficient justification and lack of attention to the entire problem has caused comment on that section of the document. That was ED-68, and it was removed in the current version of phonebcp. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 5 15:02:18 2009 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 A0CC33A6979; Mon, 5 Jan 2009 15:02:18 -0800 (PST) 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 CE0BB3A6979 for ; Mon, 5 Jan 2009 15:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.956 X-Spam-Level: X-Spam-Status: No, score=-104.956 tagged_above=-999 required=5 tests=[AWL=1.416, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, 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 R437oEPKCoZN for ; Mon, 5 Jan 2009 15:02:16 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id B7CC03A6903 for ; Mon, 5 Jan 2009 15:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1231196524; x=1262732524; 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<041401c96f4c$d8fac300$8 af04900$@net>|References:=20<041401c96f4c$d8fac300$8af049 00$@net>|Date:=20Mon,=205=20Jan=202009=2015:02:00=20-0800 |To:=20Brian=20Rosen=20,=20"'ECRIT'" =20|From:=20Ted=20Hardie=20|Subject:=20Re:=20[Ecrit]=20FW:=20I-D=20=0D=0A=20A ction:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5486"=3B=20 a=3D"14396114"; bh=Ohuj6vSgMX9vGGD3sEQPhqU2swNejrxfeUfSc0a1SAU=; b=SdBkUQaooOVrgdvLbaZJMRIePVGd6GkYCviJPekuyj2ch4AM3Nvzirj8 TIMkaJTHRW2sM30WU96LbaucjLNkxhAeo/rEuL+PmNjEF50yzykE0Dzl8 b1H6qPUhLdOKjk21M7tqAl1tGOAoqlG+I3VYiOLwUHEyEK0UDouThElVo o=; X-IronPort-AV: E=McAfee;i="5300,2777,5486"; a="14396114" 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; 05 Jan 2009 15:02:03 -0800 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n05N23VG031210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Jan 2009 15:02:03 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n05N23dU031071 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jan 2009 15:02:03 -0800 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 5 Jan 2009 15:02:02 -0800 Received: from [10.227.68.132] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 5 Jan 2009 15:02:02 -0800 MIME-Version: 1.0 Message-ID: In-Reply-To: <041401c96f4c$d8fac300$8af04900$@net> References: <041401c96f4c$d8fac300$8af04900$@net> Date: Mon, 5 Jan 2009 15:02:00 -0800 To: Brian Rosen , "'ECRIT'" From: Ted Hardie Subject: Re: [Ecrit] FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.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 The document says: The PSTN has a feature available, "Called Party Hold" (CPH) which is used in some jurisdictions to meet this requirement. It was my understanding that this feature was no longer universally available in the PSTN, not that it was universally available and not used in all jurisdictions. Have I misunderstood this? As the document notes, it is not available in wireless networks, which are the majority of initiating networks for emergency calls in at least some jurisdictions. I believe that this makes this statement: Some jurisdictions are desirous of maintaining their current PSAP call disconnect control capability, while other jurisdictions would like to regain access to those capabilities. only partly a true representation of the current situation. The document says: When PD-1 is enforced, the call taker must be able to cause alerting to the caller which has attempted to prematurely disconnect from the emergency call. Rationale: The caller believes they have disconnected. The ability to alert is needed to encourage the caller to reconnect. Previous parts of the document have described "ringback" as distinct from call back. Is this "ringback" in requirements form? I understand that the folks working on this feel strongly about this, but this document is neither complete nor persuasive. As it stands, it is missing all discussion of the negotiation phase of this, which has been pointed out repeatedly as a necessary item. Without the requirements there describing what the negotiation of this function must do, the security considerations are paper thin and the rest of it gives no real sense of the overarching system. Can a phone say "no" in this negotiation, so that the PSAP is told it is not being surrendered call control? Without answers to questions like this, the document can't be evaluated well. I also believe that to be truly persuasive the document would have to cover the UI issues and the multi-line issues which have been raised repeatedly. As it is, I read it to describe a system that could just as easily be handled entirely by UI and client side mechanisms, with no network requirements at all for abandonment. I do not support this document becoming a working group item as it currently stands. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 6 05:46:46 2009 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 D848B28C106; Tue, 6 Jan 2009 05:46:46 -0800 (PST) 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 7500728C113 for ; Tue, 6 Jan 2009 05:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.745, 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 UJ60q6WBizx5 for ; Tue, 6 Jan 2009 05:46:44 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0090E28C126 for ; Tue, 6 Jan 2009 05:46:29 -0800 (PST) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n06Dk9h00373; Tue, 6 Jan 2009 13:46:09 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jan 2009 13:46:04 -0000 Message-ID: <0913B6CD18F370498CD65864CF254E900801BC5E@zharhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PSAP Call Backs thread-index: AclvbXeidg9L0HQdS7u5Igbg22fZ8wAl4lWA References: <007501c96dd1$1b5ecd40$0201a8c0@nsnintra.net><041801c96f4c$e63c29f0$b2b47dd0$@net><28B7C3AA2A7ABA4A841F11217ABE78D67481999F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Milan Patel" To: "James M. Polk" , "DRAGE, Keith (Keith)" , "Brian Rosen" , "Hannes Tschofenig" , "Tschofenig, Hannes (NSN - FI/Espoo)" , "ECRIT" Subject: Re: [Ecrit] PSAP Call Backs 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 Keith's suggestions sound sensible to me. Regards, Milan -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: 05 January 2009 19:20 To: DRAGE, Keith (Keith); Brian Rosen; 'Hannes Tschofenig'; 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' Subject: Re: [Ecrit] PSAP Call Backs At 01:07 PM 1/5/2009, DRAGE, Keith (Keith) wrote: >I think I agree with what Brian is saying here, but I would turn the >statement round. > >We should decide what special behaviours callback calls required, and >then identify the appropriate means of signalling to generate that >behaviour. > >That means if we identify that callback calls need special treatment in >the network, then RPH may be the way to do it. If we want to override >incoming call bahaviour in the destination UA, then we find an >appropriate way of doing that (along with a security solution to >prevent misuse. > >I though we had decided to deal with callback issues with a separate >requirements draft. As such I would support taking out callback text >from all documents at the moment, not with the idea that that might not >be the solution, but that we come up with a complete package of >solutions in the future. I think this is appropriate >regards > >Keith > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > Behalf Of Brian Rosen > > Sent: Monday, January 05, 2009 3:47 PM > > To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, Hannes (NSN - > > FI/Espoo)'; 'ECRIT' > > Subject: Re: [Ecrit] PSAP Call Backs > > > > I would have said that we decide if callbacks should have special > > treatment of any kind. > > > > If we decide that they should, then we decide how we will mark them, > > and then what the behavior is for that marking. > > > > Please do not confuse the resource priority marking and behavior > > with this discussion. As with the emergency call marking > > (urn:service:sos in Route), and the associated behaviors in > > PhoneBCP, the RPH is an independent marking and behavior > > specification. If we mark call backs, it won't be with RPH. A > > callback MAY also have an RPH marking, and there could be behavior > > associated with that with respect to priority handling within a > > network. > > Similarly, the packets of a callback could have a DiffServ marking, > > and behavior associates with that marking within a network. > > > > I think we should have a call back marking, and we should specify > > behaviors for that marking. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > Behalf Of Hannes Tschofenig > > Sent: Saturday, January 03, 2009 1:29 PM > > To: 'James M. Polk'; Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT' > > Subject: Re: [Ecrit] PSAP Call Backs > > > > There are two different aspects: > > > > A) A decision that decides whether a call back has to be marked or > > not > > > > B) When the decision is made that is has to be marked then how the > > marking is going to look like. > > > > Regarding (A): This might be a policy issues. Some PSAPs might want > > to use this indication and others might not. > > Nothing we have to worry about. > > > > Regarding (B): Here there needs to be one way todo the marking -- > > not multiple ways. It would just increase the implementation > > complexity, the number of error cases and interop problems. > > > > I am not sure to what your "MAY" statement refers to -- to > > (A) or (B). > > > > Ciao > > Hannes > > > > > > >-----Original Message----- > > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf > > >Of James M. Polk > > >Sent: 02 January, 2009 22:15 > > >To: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > > >Subject: Re: [Ecrit] PSAP Call Backs > > > > > >At 04:21 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > >>Hi all, > > >> > > >>In the last few months we have seen increased interest in the > > >topic of > > >>PSAP call backs. > > >> > > >>Section 10 of > > http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-06 > > >>says: > > >> > > >> SP-36 Call backs to the Contact: header URI recieved within 30 > > >> minutes of an emergency call must reach the device > > >regardless of call > > >> features or services that would normally cause the call > > >to be routed > > >> to some other entity. > > >> > > >>More importantly, Section 13 says: > > >> > > >> ED-73 Call backs SHOULD be determined by retaining the > > >domain of the > > >> PSAP which answers an outgoing emergency call and > > instantiating a > > >> timer which starts when the call is terminated. If a call is > > >> received from the same domain and within the timer > > period, sent to > > >> the Contact: or AoR used in the emergency call, it should > > >be assumed > > >> to be a call back. The suggested timer period is 5 minutes. > > >> > > >>http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt > > >>proposed another solution based on marking the callback using > > >the "sos" > > >>URI parameter. > > >> > > >>http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-local-emergenc > > >y-rph-nam > > >>e space/ proposes another solution by utilizing the > > Resource Priority > > >>Header. > > > > > >within the namespace ID, the total thought (for PSAP > > callback) is here: > > > > > > This namespace will also be used > > > for communications between emergency authorities, and MAY be used > > > for emergency authorities calling public citizens. An example of > > > the later is a PSAP operator calling back someone who previously > > > called 9111/112/999 and the communication was terminated before it > > > should have been (in the operator's judgment). > > > > > >Notice this is all based on the MAY in the first sentence, > > therefore it > > >can be considered an afterthought, i.e., something that can be > > >utilized/specified later. > > > > > >the "sos" parameter solution is more definitive, yet it > > should identify > > >a priority marking (in SIP), given that there is already a > > defined way > > >to do that in SIP, and a second way shouldn't be defined > > >- as it will only lead to interoperability issues. > > > > > > > > >>So, here are my high-level questions: > > >> > > >>A) Do you think that you understand the requirements that lead to > > >>a need for a technical solution? > > >> > > >>B) Do you believe that more work beyond the mechanism described in > > >>Phone BCP is needed? > > >> > > >>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 > > > > > > > _______________________________________________ > > 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 Jan 6 08:14:28 2009 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 D13103A686C; Tue, 6 Jan 2009 08:14:28 -0800 (PST) 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 E50E13A686C for ; Tue, 6 Jan 2009 08:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.001, 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 KHZTJdRzVz32 for ; Tue, 6 Jan 2009 08:14:27 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id EABDE3A6405 for ; Tue, 6 Jan 2009 08:14:26 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LKEZA-000273-0c; Tue, 06 Jan 2009 10:14:06 -0600 From: "Brian Rosen" To: "'Ted Hardie'" , "'ECRIT'" References: <041401c96f4c$d8fac300$8af04900$@net> In-Reply-To: Date: Tue, 6 Jan 2009 11:14:07 -0500 Message-ID: <008801c97019$d03b99b0$70b2cd10$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclviZlOb0HVHolrR5i2DOaeNZrlvgAi8cyA 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] FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.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 Called Party Hold is no longer universally available. The statement about some jurisdictions wishing to retain their current capability and others wishing to regain it is entirely true. It is the fact that some carriers did not require Called Party Hold of their vendors that caused the loss of the feature. Wireless carriers never implemented it, despite the PSAPs desire for it to be implemented. I fail to see your point: some jurisdictions have the capability described in the requirements now and wish to keep it. Others used to have it, lost it, and want it back. Others don't think they need it, whether they had it or have it. "Alerting" is how you describe what is desired in human terms. The human is alerted. The phone "rings". Please tell me how, on the one hand, I am asked to describe the requirements in human terms only, no signaling, and yet have negotiation requirements? My best answer is PD-7, where it describes that the PSAP controls whether premature disconnect control happens on a call-by-call basis and in AC-3, where I describe that the human may notice that abandoned call hold up doesn't always happen. I probably could improve the requirements by having both a "PSAP can control" and a "User may notice" in both PD and AC requirements, but I think the point comes across that it's an enabled, and negotiated feature. Did you miss this text: When PD-1 is enforced, the caller must not be able to place another call until the PSAP allows the call to be released. This requirement is not intended to imply a user interface with multiple lines accessible independently is locked to the single line that placed the emergency call. As mistakes can be made, an override mechanism invoked by the caller must be feasible. The implementation must fail safely such that the phone cannot be locked and unable to call for help. I don't see how you could have the PSAP control the function on a call by call basis, and have it handled by UI alone. It's important to have the PSAP tell the device that it does or doesn't need the function. It's important that the PSAP control the alerting. It's important that the PSAP know the "hook state" of the call. Brian -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: Monday, January 05, 2009 6:02 PM To: Brian Rosen; 'ECRIT' Subject: Re: [Ecrit] FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt The document says: The PSTN has a feature available, "Called Party Hold" (CPH) which is used in some jurisdictions to meet this requirement. It was my understanding that this feature was no longer universally available in the PSTN, not that it was universally available and not used in all jurisdictions. Have I misunderstood this? As the document notes, it is not available in wireless networks, which are the majority of initiating networks for emergency calls in at least some jurisdictions. I believe that this makes this statement: Some jurisdictions are desirous of maintaining their current PSAP call disconnect control capability, while other jurisdictions would like to regain access to those capabilities. only partly a true representation of the current situation. The document says: When PD-1 is enforced, the call taker must be able to cause alerting to the caller which has attempted to prematurely disconnect from the emergency call. Rationale: The caller believes they have disconnected. The ability to alert is needed to encourage the caller to reconnect. Previous parts of the document have described "ringback" as distinct from call back. Is this "ringback" in requirements form? I understand that the folks working on this feel strongly about this, but this document is neither complete nor persuasive. As it stands, it is missing all discussion of the negotiation phase of this, which has been pointed out repeatedly as a necessary item. Without the requirements there describing what the negotiation of this function must do, the security considerations are paper thin and the rest of it gives no real sense of the overarching system. Can a phone say "no" in this negotiation, so that the PSAP is told it is not being surrendered call control? Without answers to questions like this, the document can't be evaluated well. I also believe that to be truly persuasive the document would have to cover the UI issues and the multi-line issues which have been raised repeatedly. As it is, I read it to describe a system that could just as easily be handled entirely by UI and client side mechanisms, with no network requirements at all for abandonment. I do not support this document becoming a working group item as it currently stands. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 6 08:40:44 2009 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 6DA603A6774; Tue, 6 Jan 2009 08:40:44 -0800 (PST) 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 3A6813A6774 for ; Tue, 6 Jan 2009 08:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.88 X-Spam-Level: X-Spam-Status: No, score=-5.88 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 eJnv41dzh+QA for ; Tue, 6 Jan 2009 08:40:42 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id E81A53A6405 for ; Tue, 6 Jan 2009 08:40:41 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n06GeQ3h015687 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Jan 2009 17:40:26 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 6 Jan 2009 17:40:26 +0100 From: "DRAGE, Keith (Keith)" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , ECRIT Date: Tue, 6 Jan 2009 17:40:24 +0100 Thread-Topic: HUM regarding draft-rosen-ecrit-premature-disconnect-rqmts Thread-Index: AclrLVAIpzZ7YixAQam2k1f6APiSoQE4A7gw Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6748579DE@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [Ecrit] HUM regarding draft-rosen-ecrit-premature-disconnect-rqmts 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 NOT OK with turning this document into a WG document. In general I believe the requirements are written too much round an existing PSTN capability, rather than getting to the root of any real requirement. It is also clear that there are jurisdictions that do not require this capability and that needs to be reflected in the document. More specifically. Section 1.1 and section 1.2: Both these sections imply that the PSTN solution is the solution in SIP, rather than providing an overal discussion of what the real objective is. I would understand that the real need of 1.1 is in ensuring that the media path between the caller and the call taker is reinstated if the caller takes any action to remove it (or indeed not removed at all). At this point (section 1) there should also be a discussion of impacts of the user disconnecting just because they have made a mistake, and having realised that mistake - cleared down. There also needs to be a discussion of the phenomenum of certain parts of the world where they use the emergency call number to test the phone is working without a valid SIM or UICC. PD-1: Not written as a requirement. User has essentially disabled the user interface of the UA - that cannot be prevented. PD-4 is about trying to get the user to reenable the user interface. Is the requirement that the existing media path must be retained between the UA and call taker, or that a media path must be provided is the user interface is reenabled? PD-2: This is essentially two requirements. One of the user disabling the user interface. One of reenabling. PD-5: This requirement is inadequately specified. The first and second sentences are contradictory. We don't know what the real requirement is as a result of the second sentence being there. If the user has more than one UA, what happens on the second UA. If the user is prepared to answer a call on the second UA, then why shouldn't the emergency call exist there? Note that release 9 of 3GPP is looking at the ability to split the media of a single call between different UAs or a UA with two access technology interfaces so the text of all the requirements needs to encompass this idea as well. PD-6: I like the idea of "converse roughly"! Typo "initialting". PD-7: PD-7 is currently specified as the call taker requirement. Needs an additional requirement from the caller perspective, i.e. that in jurisdictions where the mechanism is not required, that the caller can clear the call normally with no impact. More importantly, this is a function of the jurisdiction, and as UAs can roam between jurisdictions, this cannot be prebuilt into the phone. AC-1: There are several points in the sequence here which could be meant, and it is not clear which. For example, if the user has typed 911 into his user interface, but gets murdered by an assailant before hitting the send key, should an emergency call be made and completed? AC-2: What is the real requirement here. Appears to be a caller requirement. AC-3: Again the requirement is missing here. It would appear that the real requirement is that disconnect in not impacted in jurisdictions where the requirement is missing. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Wednesday, December 31, 2008 9:51 AM > To: ECRIT > Subject: [Ecrit] HUM regarding > draft-rosen-ecrit-premature-disconnect-rqmts > > Hi all, > > We had a fair amount of discussions regarding this item and, > as mentioned in my status update, we would like to resolve > the deadlock we currently have. > > We would like to get some feedback from the group. > > Are you OK with turning draft-rosen-ecrit-premature-disconnect-rqmts > into a working group item (after rechartering) (under the > assumption that the editor of the document is changed once > the document is a WG item)? > > Deadline: 19. Jan. 2009 > > 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 Tue Jan 6 10:10:22 2009 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 1583B3A67FC; Tue, 6 Jan 2009 10:10:22 -0800 (PST) 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 0162E3A67FC for ; Tue, 6 Jan 2009 10:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.013 X-Spam-Level: X-Spam-Status: No, score=-103.013 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 nIfJV9PgdYfw for ; Tue, 6 Jan 2009 10:10:18 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 9B96E3A63D2 for ; Tue, 6 Jan 2009 10:10:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1231265406; x=1262801406; 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<008801c97019$d03b99b0$7 0b2cd10$@net>|References:=20<041401c96f4c$d8fac300$8af049 00$@net>=0D=0A=20 =0D=0A=20<008801c97019$d03b99b0$70b2cd10$@net>|Date:=20Tu e,=206=20Jan=202009=2010:10:02=20-0800|To:=20Brian=20Rose n=20,=20"'ECRIT'"=20 |From:=20Ted=20Hardie=20|Subject:=20 RE:=20[Ecrit]=20FW:=20I-D=20=20=0D=0A=20Action:draft-rose n-ecrit-premature-disconnect-rqmts-02.txt|Content-Type: =20text/plain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20 E=3DMcAfee=3Bi=3D"5100,188,5487"=3B=20a=3D"14396614"; bh=05CnOsKSLPJxqOM5h8ioyPK9e6iT55/1+0BJ+VCoSHc=; b=XA/RkLNPjOw2Ux4EawgY/iabXd0N5mMV/lpGIKNx+Hxbp9FAc7RxDFbq Bh1nZlja9zDOlONVyrFlVG6KI+uNfmbwls6m5kHTjkdJ6wNLp7TVEDRcq pYDWsOVYJ6WS/espT/hIZa/HATXWVp1B7GM+4jUVmjXgMxGillZFW4RDO U=; X-IronPort-AV: E=McAfee;i="5100,188,5487"; a="14396614" 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; 06 Jan 2009 10:10:05 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n06IA5Td015955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Jan 2009 10:10:05 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n06IA41f008703 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Jan 2009 10:10:05 -0800 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.336.0; Tue, 6 Jan 2009 10:10:04 -0800 Received: from [10.227.68.132] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.336.0; Tue, 6 Jan 2009 10:10:03 -0800 MIME-Version: 1.0 Message-ID: In-Reply-To: <008801c97019$d03b99b0$70b2cd10$@net> References: <041401c96f4c$d8fac300$8af04900$@net> <008801c97019$d03b99b0$70b2cd10$@net> Date: Tue, 6 Jan 2009 10:10:02 -0800 To: Brian Rosen , "'ECRIT'" From: Ted Hardie Subject: Re: [Ecrit] FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.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 8:14 AM -0800 1/6/09, Brian Rosen wrote: >Called Party Hold is no longer universally available. Thanks for this clarification; it would be nice if future versions of the document noted this. >The statement about some jurisdictions wishing to retain their current >capability and others wishing to regain it is entirely true. > It is the fact >that some carriers did not require Called Party Hold of their vendors that >caused the loss of the feature. They were able to do this, presumably, because there was no regulatory requirement here, eh? >Wireless carriers never implemented it, >despite the PSAPs desire for it to be implemented. I fail to see your >point: some jurisdictions have the capability described in the requirements >now and wish to keep it. Others used to have it, lost it, and want it back. >Others don't think they need it, whether they had it or have it. I guess I wasn't clear, sorry. No jurisdiction has it now for all calls, because no calls coming from wireless devices have this capabilities. This entire document casts this as a problem of retaining or restoring a capability. The reality is that it is about creating a new one, because it requires the creation of a capability in a completely different technical and social context. In a wireline 911 context prior to this, for example, it was darned unlikely that the caller and PSAP were associated with networks in different jurisdictions. But the system we've put together here allows for someone in Toronto whose only working phone happens to tunnel back to Germany to determine the correct PSAP for their location and make an emergency call. How does that phone (or that network) treat the requirements for CPH? Those are different issues that those faced by the PSTN alone. Trying to put forth the requirements from only the PSAP perspective simply isn't adequate in this context, at least in my personal opinion. >"Alerting" is how you describe what is desired in human terms. The human is >alerted. The phone "rings". > >Please tell me how, on the one hand, I am asked to describe the requirements >in human terms only, no signaling, and yet have negotiation requirements? Perhaps by making a requirement that there is a need for agreement here between the human user and the PSAP on who should have this control? Since this isn't the same in all jurisdictions, you can have a mismatch both ways. >My best answer is PD-7, where it describes that the PSAP controls whether >premature disconnect control happens on a call-by-call basis and in AC-3, >where I describe that the human may notice that abandoned call hold up >doesn't always happen. Can you think of putting these requirements in terms of the user, rather than the PSAP's desires? > I probably could improve the requirements by having >both a "PSAP can control" and a "User may notice" in both PD and AC >requirements, but I think the point comes across that it's an enabled, and >negotiated feature. > >Did you miss this text: >When PD-1 is enforced, the caller must not be able to place another call >until the PSAP allows the call to be released. This requirement is not >intended to imply a user interface with multiple lines accessible >independently is locked to the single line that placed the emergency call. >As mistakes can be made, an override mechanism invoked by the caller must be >feasible. The implementation must fail safely such that the phone cannot be >locked and unable to call for help. No, I didn't miss it, but I'm apparently missing which part of my message you're referring to here. Sorry for being dense. >I don't see how you could have the PSAP control the function on a call by >call basis, and have it handled by UI alone. You are looking at this as PSAP call control, rather than that at the base requirement--"The user shouldn't stop talking until the call taker says it is okay to go." The UI *can* enforce that if it knows that this is the PSAP expectation. That is metadata related to the PSAP's location in your system so far (since it is jurisdictional, rather than based on call type). We have ways of informing people about that already. I am not saying that this is better than what you have in mind, but if "Don't send Bye" is agreed to by the user and enforced by the device based on metadata associated with the PSAP's location, you seem to be a long way toward where you want to be. This is a long way of saying please stop just repeating things like this: > It's important to have the >PSAP tell the device that it does or doesn't need the function. It's >important that the PSAP control the alerting. It's important that the PSAP >know the "hook state" of the call. and have the document describe what the humans need here. There are conflicts in that ("User control of the device should be absolute unless voluntarily surrendered" is in conflict with "The PSAP call taker should always end the call"), but we're not addressing those adequately with a document that is, forgive me, all over the map like this one. As I said before, I don't think this document is ready to be a working group item. I remain willing to review later iterations, and I believe that the working group should continue to do so. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 7 05:00:56 2009 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 DFDCD28C12E; Wed, 7 Jan 2009 05:00:56 -0800 (PST) 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 A96A528C12E for ; Wed, 7 Jan 2009 05:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 0qeaptT-NzQq for ; Wed, 7 Jan 2009 05:00:54 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9F69728C10C for ; Wed, 7 Jan 2009 05:00:54 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5E71721544 for ; Wed, 7 Jan 2009 14:00:28 +0100 (CET) X-AuditID: c1b4fb3e-ac06abb00000429e-22-4964a76c90e5 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 398D7200B2 for ; Wed, 7 Jan 2009 14:00:28 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jan 2009 14:00:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jan 2009 14:00:27 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Ecrit] HUM regarding draft-patel-ecrit-sos-parameter-02.txt thread-index: Aclwx+liuSI5G6nKSDaWbTUpYZgAOQ== From: "Christer Holmberg" To: X-OriginalArrivalTime: 07 Jan 2009 13:00:27.0836 (UTC) FILETIME=[E9B277C0:01C970C7] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] HUM regarding draft-patel-ecrit-sos-parameter-02.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="===============0176830901==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0176830901== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C970C7.E99FB4EA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C970C7.E99FB4EA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I support this document. Regards, Christer >Hi all, > >At IETF#73 we had a discussion regarding >draft-patel-ecrit-sos-parameter-01.txt and the feedback that was provided >lead to an updated draft: >http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-02 > >This new document focuses on the "sos" registration only as described by >Milan in his recent mail to the list: >http://www.ietf.org/mail-archive/web/ecrit/current/msg05779.html > >This document is work we would be doing for the 3GPP. > >According to the meeting minutes there was positive support for working on >this document during IETF#73, see >http://www.ietf.org/proceedings/08nov/minutes/ecrit.txt. > >Please let me us know whether you have objections or whether you are in >support of this document (if you haven't stated your opinion already). > >Deadline: 16. Jan. 2009 > >Ciao >Hannes & Marc ------_=_NextPart_001_01C970C7.E99FB4EA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] HUM regarding = draft-patel-ecrit-sos-parameter-02.txt

Hi,

I support this document.

Regards,

Christer


>Hi all,
>
>At IETF#73 we had a discussion = regarding
>draft-patel-ecrit-sos-parameter-01.txt and the = feedback that was provided
>lead to an updated draft:
>http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter= -02
>
>This new document focuses on the = "sos" registration only as described by
>Milan in his recent mail to the = list:
>http://www.ietf.org/mail-archive/web/ecrit/current/msg0577= 9.html
>
>This document is work we would be = doing for the 3GPP.
>
>According to the meeting minutes = there was positive support for working on
>this document during IETF#73, = see
>http://www.ietf.org/proceedings/08nov/minutes/ecrit.txt.
>
>Please let me us know whether you = have objections or whether you are in
>support of this document (if you = haven't stated your opinion already).
>
>Deadline: 16. Jan. 2009
>
>Ciao
>Hannes & Marc

------_=_NextPart_001_01C970C7.E99FB4EA-- --===============0176830901== 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 --===============0176830901==-- From ecrit-bounces@ietf.org Wed Jan 7 07:15:17 2009 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 633153A69A7; Wed, 7 Jan 2009 07:15:17 -0800 (PST) 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 A768A3A69A7 for ; Wed, 7 Jan 2009 07:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_05=-1.11, 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 2uiP1JwS3fQH for ; Wed, 7 Jan 2009 07:15:14 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 22D9D3A698F for ; Wed, 7 Jan 2009 07:15:13 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LKa7P-0003zN-Lx for ecrit@ietf.org; Wed, 07 Jan 2009 09:14:52 -0600 From: "Brian Rosen" To: "'ECRIT'" Date: Wed, 7 Jan 2009 10:14:53 -0500 Message-ID: <022701c970da$b36ebc10$1a4c3430$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclwKfte5CDw0DNgQCSG/3GFmzNyJAAK61HgACE/K9A= 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: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.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 managed to not reply all, sorry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, January 07, 2009 9:22 AM To: Ted Hardie Subject: RE: [Ecrit] FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt > At 8:14 AM -0800 1/6/09, Brian Rosen wrote: > >Called Party Hold is no longer universally available. > > Thanks for this clarification; it would be nice if future > versions of the document noted this. I will do so > > It is the fact > >that some carriers did not require Called Party Hold of their vendors > that > >caused the loss of the feature. > > They were able to do this, presumably, because there was no regulatory > requirement here, eh? That is correct. I was not there. I was told that there was no discussion; the feature simply disappeared. The PSAPs complained, the carriers told them, "sorry, it's gone". There have been attempts to get it back through regulation, they have not succeeded. To my knowledge, this hasn't been an actual rulemaking. > > >Wireless carriers never implemented it, > >despite the PSAPs desire for it to be implemented. I fail to see your > >point: some jurisdictions have the capability described in the > requirements > >now and wish to keep it. Others used to have it, lost it, and want it > back. > >Others don't think they need it, whether they had it or have it. > > I guess I wasn't clear, sorry. No jurisdiction has it now for all > calls, because > no calls coming from wireless devices have this capabilities. This > entire > document casts this as a problem of retaining or restoring a > capability. This is correct: it used to be there, it's not any more. In some jurisdictions, it's still there in the wireline network. The fact that it's never been implemented in the wireless network doesn't detract from the argument. The point is that the PSAPs have experience with the implementation, and it's a positive experience. There are no negative experiences that I know of. > The reality is that it is about creating a new one, because it requires > the creation of a capability in a completely different technical and > social > context. In a wireline 911 context prior to this, for example, it was > darned unlikely > that the caller and PSAP were associated with networks in different > jurisdictions. > But the system we've put together here allows for someone in Toronto > whose only working phone happens to tunnel back to Germany to determine > the correct PSAP for their location and make an emergency call. How > does > that phone (or that network) treat the requirements for CPH? There is no fundamental change in the social context. You still have stressed people making poor judgments on when to end a call, and a trained PSAP call taker better able to determine when to end the call. The networks are, certainly, more complex. The requirements, and the proposed mechanisms have always dealt with the circumstance you are describing adequately: the feature is enabled call by call at the PSAP and works across complex networks such as the ones you describe. > > Those are different issues that those faced by the PSTN alone. Trying > to put > forth the requirements from only the PSAP perspective simply isn't > adequate > in this context, at least in my personal opinion. I think, since we're restricted by your request to talking about humans, only balancing the needs and desires of the caller and the call taker. The carrier is not considered. Within that restriction, we have the situation described above. > > >"Alerting" is how you describe what is desired in human terms. The > human is > >alerted. The phone "rings". > > > >Please tell me how, on the one hand, I am asked to describe the > requirements > >in human terms only, no signaling, and yet have negotiation > requirements? > > Perhaps by making a requirement that there is a need for agreement > here between the human user and the PSAP on who should have this > control? Since this isn't the same in all jurisdictions, you can have > a mismatch both ways. But there isn't a negotiation between the caller and the PSAP. The requirement we have is that the PSAP asserts control, and the user can override. That is described. To implement that, I think signaling needs negotiation (both so the caller side knows what to do, and the PSAP knows whether it's going to be able to assert control). > > >My best answer is PD-7, where it describes that the PSAP controls > whether > >premature disconnect control happens on a call-by-call basis and in > AC-3, > >where I describe that the human may notice that abandoned call hold up > >doesn't always happen. > > Can you think of putting these requirements in terms of the user, > rather than the PSAP's desires? Isn't this the nut of the problem? We're asserting that the caller makes poor judgments in this situation. We're suggesting that it ought to be a PSAP decision, with the possibility of a user override. The user isn't going to say "oh gee, I'm stressed, you decide". She is going to hang up when she shouldn't. The PSAPs response is alert and regain the connection. You are stuck on the possibility the user actually does know better than the PSAP what is happening. Fine, that is why the override is there. The experience is that overrides aren't needed. That's over many years of lots of calls. The stress and mistakes of humans aren't related to the nature of their communications device; they make the same mistakes with wireless handsets as they do with wireline phones. Whether it's VoIP or analog TDM, the user behaves the same. Users haven't evolved to handling the stress better. The experience we have is relevant to the situation we have here. The human reactions and experiences are the same, even though the technology changed. The user terminates, the PSAP causes the phone to alert, the user (hopefully) responds, and the call continues. There isn't any PSTN bias there. No one has suggested a better interaction model. > > > I probably could improve the requirements by having > >both a "PSAP can control" and a "User may notice" in both PD and AC > >requirements, but I think the point comes across that it's an enabled, > and > >negotiated feature. > > > >Did you miss this text: > >When PD-1 is enforced, the caller must not be able to place another > call > >until the PSAP allows the call to be released. This requirement is > not > >intended to imply a user interface with multiple lines accessible > >independently is locked to the single line that placed the emergency > call. > >As mistakes can be made, an override mechanism invoked by the caller > must be > >feasible. The implementation must fail safely such that the phone > cannot be > >locked and unable to call for help. > > No, I didn't miss it, but I'm apparently missing which part of my > message > you're referring to here. Sorry for being dense. It discusses how multiline phones are handled and it's the text that explicitly requires an override, which I read your response as asking for. > > >I don't see how you could have the PSAP control the function on a call > by > >call basis, and have it handled by UI alone. > > You are looking at this as PSAP call control, rather than that at the > base > requirement--"The user shouldn't stop talking until the call taker says > it is okay to go." The UI *can* enforce that if it knows that this is > the PSAP > expectation. That is metadata related to the PSAP's location in your > system so far (since it is jurisdictional, rather than based on call > type). We have ways of informing people about that already. But that isn't the requirement, that's the problem statement. In those terms, the call taker, in some jurisdictions, in some circumstances known only to the PSAP, wants to hold up a call the user thinks he ought to terminate. The call taker needs a mechanism to alert the user and rapidly resume conversing if/when the user responds. That's the problem we're solving. The device can't know the state of the PSAP without signaling. The technology change does provide new capabilities, but it also has new problems. In this case, we have the problem that we could lose the PSAP's BYE. If the device thinks it ought to hold the call, the PSAP attempts to terminate, and the BYE is lost, we have a problem. The requirements state that should not happen. We also have more fine grained PSAP state information. For example, you don't want the feature enabled if the call is answered by an IVR. That is why the requirement has to be that its negotiated call-by-call. > > I am not saying that this is better than what you have in mind, but > if "Don't send Bye" is agreed to by the user and enforced by the > device based on metadata associated with the PSAP's location, > you seem to be a long way toward where you want to be. As above, "don't send BYE" can brick the phone. That is why we have abandoned solutions that don't send BYE. > > This is a long way of saying please stop just repeating things like > this: > > > It's important to have the > >PSAP tell the device that it does or doesn't need the function. It's > >important that the PSAP control the alerting. It's important that the > PSAP > >know the "hook state" of the call. > > and have the document describe what the humans need here. There are > conflicts in that ("User control of the device should be absolute > unless voluntarily > surrendered" is in conflict with "The PSAP call taker should always end > the > call"), but we're not addressing those adequately with a document that > is, forgive me, all over the map like this one. > > As I said before, I don't think this document is ready to be a working > group > item. I remain willing to review later iterations, and I believe that > the > working group should continue to do so. Here is my problem: I don't know how to do better what you asked for. I have tried, 3 times, to meet your objections, by fundamentally altering the document. Yet, we're still on fundamentals; we're not arguing details. You don't seem willing to solve the problem, you want me to do it, and you are adamant that you don't want this to go forward until you are satisfied. You aren't saying: "This is a bad idea, and we shouldn't do it". You have me in what seems an infinite loop of "maybe if you describe it that way, I'll accept that it's a problem we should solve". You accuse me of having an implementation in mind and cooking the requirements to meet the implementation. On the other hand, you seem to be in the same situation (you want it all device UI). NENA is pretty hot about this issue. Of course, that doesn't really matter to IETF process, but it's not just me, it's the entire North American PSAP community. I'm just the point guy. Whenever there is a new version, a NENA work group looks it over and helps me fine tune it. They are completely mystified over the fuss on this; they understand the problem, they've lived with it for many years with and without solutions, and it seems completely obvious to them that we (IETF) should specify a solution. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 7 10:19:01 2009 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 32AFA3A684A; Wed, 7 Jan 2009 10:19:01 -0800 (PST) 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 F00323A684A for ; Wed, 7 Jan 2009 10:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.008 X-Spam-Level: X-Spam-Status: No, score=-6.008 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 KDjBsh4jR+NO for ; Wed, 7 Jan 2009 10:18:59 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id CF43C3A6843 for ; Wed, 7 Jan 2009 10:18:57 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n07IIgpk017866 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 7 Jan 2009 19:18:42 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 7 Jan 2009 19:18:42 +0100 From: "DRAGE, Keith (Keith)" To: Hannes Tschofenig , ECRIT Date: Wed, 7 Jan 2009 19:18:41 +0100 Thread-Topic: [Ecrit] HUM regarding draft-patel-ecrit-sos-parameter-02.txt Thread-Index: AclqhafYuIRcumlHSuuCLaYFdmjUTQGbiBPA Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674857DAF@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <005001c96a85$a8b86060$0201a8c0@nsnintra.net> In-Reply-To: <005001c96a85$a8b86060$0201a8c0@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [Ecrit] HUM regarding draft-patel-ecrit-sos-parameter-02.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 As you might have guessed we support this going forward as a chartered milestone. One comment on the document itself, and the description of the proposed solution. The tag is attached to the contact address in the Contact header. In IETF usage of SIP (but not 3GPP usage), it is possible to have multiple Contact headers in a REGISTER request. We need to discuss and document the semantics of what might be meant if the contact address in one Contact header has the URI parameter, and another does not. We could just declare it an error, but whatever we decide, the text should cover it. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Hannes Tschofenig > Sent: Tuesday, December 30, 2008 1:51 PM > To: ECRIT > Subject: [Ecrit] HUM regarding draft-patel-ecrit-sos-parameter-02.txt > > Hi all, > > At IETF#73 we had a discussion regarding > draft-patel-ecrit-sos-parameter-01.txt and the feedback that > was provided lead to an updated draft: > http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-02 > > This new document focuses on the "sos" registration only as > described by Milan in his recent mail to the list: > http://www.ietf.org/mail-archive/web/ecrit/current/msg05779.html > > This document is work we would be doing for the 3GPP. > > According to the meeting minutes there was positive support > for working on this document during IETF#73, see > http://www.ietf.org/proceedings/08nov/minutes/ecrit.txt. > > Please let me us know whether you have objections or whether > you are in support of this document (if you haven't stated > your opinion already). > > Deadline: 16. Jan. 2009 > > 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 Wed Jan 7 11:00:26 2009 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 78E123A6843; Wed, 7 Jan 2009 11:00:26 -0800 (PST) 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 3233B3A6843 for ; Wed, 7 Jan 2009 11:00:25 -0800 (PST) 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 QV2WLSF+GGhW for ; Wed, 7 Jan 2009 11:00:24 -0800 (PST) Received: from mail70.messagelabs.com (mail70.messagelabs.com [193.109.255.115]) by core3.amsl.com (Postfix) with ESMTP id 0AF643A67ED for ; Wed, 7 Jan 2009 11:00:23 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-9.tower-70.messagelabs.com!1231354769!114177149!22 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [206.47.0.173] Received: (qmail 21703 invoked from network); 7 Jan 2009 19:00:07 -0000 Received: from srp004376srs (HELO TLS.Exchange.Bell.ca) (206.47.0.173) by server-9.tower-70.messagelabs.com with RC4-SHA encrypted SMTP; 7 Jan 2009 19:00:07 -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.291.1; Wed, 7 Jan 2009 13:59:57 -0500 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, 7 Jan 2009 13:59:55 -0500 From: To: , Date: Wed, 7 Jan 2009 13:59:53 -0500 Thread-Topic: HUM regarding draft-rosen-ecrit-premature-disconnect-rqmts Thread-Index: AclrLVAIpzZ7YixAQam2k1f6APiSoQFzH6vg Message-ID: <0FEAC1C09868B34A982F4FB40254B37C2668A45F63@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] HUM regarding draft-rosen-ecrit-premature-disconnect-rqmts 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 Just to chime in that I HUM for turning this document as a WG item so it ca= n evolve to satisfaction then. Thanks, Guy Caron, ENP -----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 : 31 d=E9cembre 2008 04:51 =C0 : ECRIT Objet : [Ecrit] HUM regarding draft-rosen-ecrit-premature-disconnect-rqmts Hi all, We had a fair amount of discussions regarding this item and, as mentioned in my status update, we would like to resolve the deadlock we currently have. We would like to get some feedback from the group. Are you OK with turning draft-rosen-ecrit-premature-disconnect-rqmts into a working group item (after rechartering) (under the assumption that the editor of the document is changed once the document is a WG item)? Deadline: 19. Jan. 2009 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 Wed Jan 7 12:49:15 2009 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 1EEC33A6801; Wed, 7 Jan 2009 12:49:15 -0800 (PST) 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 649EC3A6801 for ; Wed, 7 Jan 2009 12:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.826 X-Spam-Level: X-Spam-Status: No, score=-5.826 tagged_above=-999 required=5 tests=[AWL=0.546, 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 ecgCE5FcbXN6 for ; Wed, 7 Jan 2009 12:49:13 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 63F0C3A677D for ; Wed, 7 Jan 2009 12:49:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,227,1231113600"; d="scan'208";a="33100863" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Jan 2009 20:48:59 +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 n07KmxJU021891; Wed, 7 Jan 2009 15:48:59 -0500 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 n07KmxlT003229; Wed, 7 Jan 2009 20:48:59 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, 7 Jan 2009 15:48:59 -0500 Received: from [10.116.195.124] ([10.116.195.124]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jan 2009 15:48:58 -0500 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 07 Jan 2009 15:48:56 -0500 From: Marc Linsner To: Brian Rosen , "'ECRIT'" Message-ID: Thread-Topic: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt Thread-Index: AclwKfte5CDw0DNgQCSG/3GFmzNyJAAK61HgACE/K9AAC62Kkg== In-Reply-To: <022701c970da$b36ebc10$1a4c3430$@net> Mime-version: 1.0 X-OriginalArrivalTime: 07 Jan 2009 20:48:59.0008 (UTC) FILETIME=[5D42E800:01C97109] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=949; t=1231361339; x=1232225339; 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]=20FW=3A=20FW=3A=20I-D=0A=20Acti on=3Adraft-rosen-ecrit-premature-disconnect-rqmts-02.txt |Sender:=20 |To:=20Brian=20Rosen=20,=20=22'ECRIT'=22 =20; bh=aFoM0j8/ASeh5RzmvTSgwzeqStfVc/lqa51Tr6efSvU=; b=D9/xJtBCGu8+aBPR/iuzBg6QjNazW6qxi/Aq074AYfYxGihmOGr1U71+Ci 9f25JNVogHvcHh4F2sGmax+1h+dXJcVngP3JVHWSRgrkzqoswpew/3uNVbrU xb9Q1/hS2G; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.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 Brian, > >>> It is the fact >>> that some carriers did not require Called Party Hold of their vendors >> that >>> caused the loss of the feature. >> >> They were able to do this, presumably, because there was no regulatory >> requirement here, eh? > That is correct. I was not there. I was told that there was no discussion; > the feature simply disappeared. The PSAPs complained, the carriers told > them, "sorry, it's gone". There have been attempts to get it back through > regulation, they have not succeeded. To my knowledge, this hasn't been an > actual rulemaking. > It conversation with an old-timer PSTN type, it was hinted that the feature disappeared due to the lack of regulation and the fear of liability from bricking the caller's phone. Without the protection of regulation, the SP didn't want to take on that liability. It's somewhat surprising the PSAP wants to accept that liability. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 8 04:07:44 2009 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 AEB4D3A6A8D; Thu, 8 Jan 2009 04:07:44 -0800 (PST) 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 D57B73A6A4A for ; Thu, 8 Jan 2009 04:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 lpzCL03m3+eb for ; Thu, 8 Jan 2009 04:07:42 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 738DA3A6A8D for ; Thu, 8 Jan 2009 04:07:42 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 80D8D212B5; Thu, 8 Jan 2009 13:07:27 +0100 (CET) X-AuditID: c1b4fb3e-ab869bb00000429e-d4-4965ec7f7ced Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5E8CE2034D; Thu, 8 Jan 2009 13:07:27 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jan 2009 13:07:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jan 2009 13:07:26 +0100 Message-ID: In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D674857DAF@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM regarding draft-patel-ecrit-sos-parameter-02.txt thread-index: AclqhafYuIRcumlHSuuCLaYFdmjUTQGbiBPAACVsF4A= References: <005001c96a85$a8b86060$0201a8c0@nsnintra.net> <28B7C3AA2A7ABA4A841F11217ABE78D674857DAF@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 08 Jan 2009 12:07:27.0075 (UTC) FILETIME=[AC3A9B30:01C97189] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] HUM regarding draft-patel-ecrit-sos-parameter-02.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, One comment on the document: I think that the requirement that the document is solving should be clearly stated. Something like: REQ: It shall be possible to indicate an emergency registration ...or something like that. Regards, Christer > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of DRAGE, Keith (Keith) > Sent: 7. tammikuuta 2009 20:19 > To: Hannes Tschofenig; ECRIT > Subject: Re: [Ecrit] HUM regarding > draft-patel-ecrit-sos-parameter-02.txt > > As you might have guessed we support this going forward as a > chartered milestone. > > One comment on the document itself, and the description of > the proposed solution. > > The tag is attached to the contact address in the Contact > header. In IETF usage of SIP (but not 3GPP usage), it is > possible to have multiple Contact headers in a REGISTER request. > > We need to discuss and document the semantics of what might > be meant if the contact address in one Contact header has the > URI parameter, and another does not. We could just declare it > an error, but whatever we decide, the text should cover it. > > regards > > Keith > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Hannes Tschofenig > > Sent: Tuesday, December 30, 2008 1:51 PM > > To: ECRIT > > Subject: [Ecrit] HUM regarding > draft-patel-ecrit-sos-parameter-02.txt > > > > Hi all, > > > > At IETF#73 we had a discussion regarding > > draft-patel-ecrit-sos-parameter-01.txt and the feedback that was > > provided lead to an updated draft: > > http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-02 > > > > This new document focuses on the "sos" registration only as > described > > by Milan in his recent mail to the list: > > http://www.ietf.org/mail-archive/web/ecrit/current/msg05779.html > > > > This document is work we would be doing for the 3GPP. > > > > According to the meeting minutes there was positive support for > > working on this document during IETF#73, see > > http://www.ietf.org/proceedings/08nov/minutes/ecrit.txt. > > > > Please let me us know whether you have objections or > whether you are > > in support of this document (if you haven't stated your opinion > > already). > > > > Deadline: 16. Jan. 2009 > > > > 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 Fri Jan 9 03:27:59 2009 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 3BE1F28C111; Fri, 9 Jan 2009 03:27:59 -0800 (PST) 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 3D8F328C0E7 for ; Fri, 9 Jan 2009 03:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.542 X-Spam-Level: X-Spam-Status: No, score=-5.542 tagged_above=-999 required=5 tests=[AWL=1.057, 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 g4TDqp-TU6mk for ; Fri, 9 Jan 2009 03:27:57 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 239DD28C0D7 for ; Fri, 9 Jan 2009 03:27:56 -0800 (PST) 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 n09BRf57016578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 9 Jan 2009 12:27:41 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n09BRd9q012766 for ; Fri, 9 Jan 2009 12:27:41 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 12:27:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jan 2009 13:28:08 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Milestone Update Thread-Index: AclyTVjnJmNS9yiwQK6hjjChYcqo2w== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 09 Jan 2009 11:27:40.0299 (UTC) FILETIME=[48033DB0:01C9724D] Subject: [Ecrit] Milestone 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, I thought it might be useful to quickly update our milestones. By preparing the text I ran into a few questions: * Wasn't PhoneBCP supposed to be a BCP? The draft says Standards Track * The ECRIT framework drafts says Standards Track. Wouldn't that be an informational document? * Do we really need a Standards Track document for the synchronizing mappings? Wouldn't an informational document be sufficient? * I really didn't know what todo about the RPH document for the milestone update. If I put it there (since it is already on our page) then other draft authors would complain why there document isn't there either. ------------------- Done Informational RFC containing terminology definitions and the requirements Done An Informational document describing the threats and security considerations Done A Standards Track RFC on "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services" Done A Standards Track RFC on "Discovering LoST Servers Using DHCP" Done A Standards Track RFC describing the Location-to-Service Translation (LoST) Protocol Done An Informational document describing the Mapping Protocol Architecture Done Submit 'Location Hiding: Problem Statement and Requirements' to the IESG for consideration as an Informational RFC Done Submit 'Specifying Holes in LoST Service Boundaries' to the IESG for consideration as an Informational RFC Feb 2009 Submit 'Best Current Practice for Communications Services in support of Emergency Calling' to the IESG for consideration as an BCP RFC Feb 2009 Submit 'Framework for Emergency Calling using Internet Multimedia' to the IESG for consideration as an Informational RFC Feb 2009 Submit 'Synchronizing Location-to-Service Translation (LoST) Servers' to the IESG for consideration as an Informational RFC ------------------- Regarding the dates: When am I going to see an update of Phone BCP/Framework so that I have some reason to believe that the Feb milestone is accomplishable? Based on the changes the document has seen since the last WGLC we have todo another short one (1 week). Roger is working on the PROTO writeup for the LoST Sync document and the Feb milestone is accomplishable. Thoughts? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 9 04:45:26 2009 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 1B53B3A686E; Fri, 9 Jan 2009 04:45:26 -0800 (PST) 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 565633A67C0 for ; Fri, 9 Jan 2009 04:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.029 X-Spam-Level: X-Spam-Status: No, score=-6.029 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 imlWVYQKT3io for ; Fri, 9 Jan 2009 04:45:24 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 2E28F3A686E for ; Fri, 9 Jan 2009 04:45:23 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n09Cj5dn026396 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Jan 2009 13:45:06 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 9 Jan 2009 13:45:05 +0100 From: "DRAGE, Keith (Keith)" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , ECRIT Date: Fri, 9 Jan 2009 13:45:04 +0100 Thread-Topic: Milestone Update Thread-Index: AclyTVjnJmNS9yiwQK6hjjChYcqo2wACol8w Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67485802F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [Ecrit] Milestone 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 really didn't know what todo about the RPH document for > the milestone update. If I put it there (since it is already > on our page) then other draft authors would complain why > there document isn't there either. There is no reason for you to be considering all the candidates as a single group of documents. Either you believe there is rough consensus to move forward and ask for milestones on RPH, or you do not. If you do not, can we please know what the concerns are so they can be addressed. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Friday, January 09, 2009 11:28 AM > To: ECRIT > Subject: [Ecrit] Milestone Update > > Hi all, > > I thought it might be useful to quickly update our > milestones. By preparing the text I ran into a few questions: > > * Wasn't PhoneBCP supposed to be a BCP? The draft says Standards Track > * The ECRIT framework drafts says Standards Track. Wouldn't > that be an informational document? > * Do we really need a Standards Track document for the > synchronizing mappings? Wouldn't an informational document be > sufficient? > * I really didn't know what todo about the RPH document for > the milestone update. If I put it there (since it is already > on our page) then other draft authors would complain why > there document isn't there either. > > ------------------- > > Done Informational RFC containing terminology > definitions and > the requirements > Done An Informational document describing the threats and > security considerations > Done A Standards Track RFC on "A Uniform Resource > Name (URN) > for Emergency and Other Well-Known Services" > Done A Standards Track RFC on "Discovering LoST > Servers Using > DHCP" > Done A Standards Track RFC describing the > Location-to-Service > Translation (LoST) Protocol > Done An Informational document describing the Mapping > Protocol Architecture > Done Submit 'Location Hiding: Problem Statement and > Requirements' to the IESG for consideration as an Informational RFC > Done Submit 'Specifying Holes in LoST Service > Boundaries' to > the IESG for consideration as an Informational RFC > Feb 2009 Submit 'Best Current Practice for Communications > Services in support of Emergency Calling' to the IESG for > consideration as an BCP RFC > Feb 2009 Submit 'Framework for Emergency Calling using Internet > Multimedia' to the IESG for consideration as an Informational RFC > Feb 2009 Submit 'Synchronizing Location-to-Service Translation > (LoST) Servers' to the IESG for consideration as an Informational RFC > > ------------------- > > Regarding the dates: > > When am I going to see an update of Phone BCP/Framework so > that I have some reason to believe that the Feb milestone is > accomplishable? > Based on the changes the document has seen since the last > WGLC we have todo another short one (1 week). > > Roger is working on the PROTO writeup for the LoST Sync > document and the Feb milestone is accomplishable. > > Thoughts? > > 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 Fri Jan 9 05:04:33 2009 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 9B2ED3A69BC; Fri, 9 Jan 2009 05:04:33 -0800 (PST) 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 C65A83A6936 for ; Fri, 9 Jan 2009 05:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=-0.964, 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 5uDgTIIevINg for ; Fri, 9 Jan 2009 05:04:30 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 799643A69AA for ; Fri, 9 Jan 2009 05:04:30 -0800 (PST) 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 n09D4CTe030844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Jan 2009 14:04:12 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n09D4Cjf013415; Fri, 9 Jan 2009 14:04:12 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 14:04:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jan 2009 15:04:40 +0200 Message-ID: In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D67485802F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Milestone Update Thread-Index: AclyTVjnJmNS9yiwQK6hjjChYcqo2wACol8wAACw1eA= References: <28B7C3AA2A7ABA4A841F11217ABE78D67485802F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext DRAGE, Keith (Keith)" , "ECRIT" X-OriginalArrivalTime: 09 Jan 2009 13:04:12.0262 (UTC) FILETIME=[C44AA860:01C9725A] Subject: Re: [Ecrit] Milestone 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 guess you misunderstood my question. The decisions regarding what documents will be included in the re-chartering of the group have been made already. I am only doing a webpage update to reflect more realistic dates and text. >-----Original Message----- >From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >Sent: 09 January, 2009 14:45 >To: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >Subject: RE: Milestone Update > > > >> * I really didn't know what todo about the RPH document for the >> milestone update. If I put it there (since it is already on >our page) >> then other draft authors would complain why there document >isn't there >> either. > >There is no reason for you to be considering all the >candidates as a single group of documents. > >Either you believe there is rough consensus to move forward >and ask for milestones on RPH, or you do not. > >If you do not, can we please know what the concerns are so >they can be addressed. > >regards > >Keith > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Friday, January 09, 2009 11:28 AM >> To: ECRIT >> Subject: [Ecrit] Milestone Update >> >> Hi all, >> >> I thought it might be useful to quickly update our milestones. By >> preparing the text I ran into a few questions: >> >> * Wasn't PhoneBCP supposed to be a BCP? The draft says >Standards Track >> * The ECRIT framework drafts says Standards Track. Wouldn't >that be an >> informational document? >> * Do we really need a Standards Track document for the synchronizing >> mappings? Wouldn't an informational document be sufficient? >> * I really didn't know what todo about the RPH document for the >> milestone update. If I put it there (since it is already on >our page) >> then other draft authors would complain why there document >isn't there >> either. >> >> ------------------- >> >> Done Informational RFC containing terminology >> definitions and >> the requirements >> Done An Informational document describing the threats and >> security considerations >> Done A Standards Track RFC on "A Uniform Resource >> Name (URN) >> for Emergency and Other Well-Known Services" >> Done A Standards Track RFC on "Discovering LoST >> Servers Using >> DHCP" >> Done A Standards Track RFC describing the >> Location-to-Service >> Translation (LoST) Protocol >> Done An Informational document describing the Mapping >> Protocol Architecture >> Done Submit 'Location Hiding: Problem Statement and >> Requirements' to the IESG for consideration as an Informational RFC >> Done Submit 'Specifying Holes in LoST Service >> Boundaries' to >> the IESG for consideration as an Informational RFC >> Feb 2009 Submit 'Best Current Practice for Communications >> Services in support of Emergency Calling' to the IESG for >> consideration as an BCP RFC >> Feb 2009 Submit 'Framework for Emergency Calling >using Internet >> Multimedia' to the IESG for consideration as an Informational RFC >> Feb 2009 Submit 'Synchronizing Location-to-Service Translation >> (LoST) Servers' to the IESG for consideration as an Informational RFC >> >> ------------------- >> >> Regarding the dates: >> >> When am I going to see an update of Phone BCP/Framework so >that I have >> some reason to believe that the Feb milestone is accomplishable? >> Based on the changes the document has seen since the last >WGLC we have >> todo another short one (1 week). >> >> Roger is working on the PROTO writeup for the LoST Sync document and >> the Feb milestone is accomplishable. >> >> Thoughts? >> >> 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 Fri Jan 9 08:33:41 2009 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 CA5983A6889; Fri, 9 Jan 2009 08:33:41 -0800 (PST) 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 7B5BD3A6832 for ; Fri, 9 Jan 2009 08:33:40 -0800 (PST) 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 aL2ZFAq7yFwb for ; Fri, 9 Jan 2009 08:33:39 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 751D83A6784 for ; Fri, 9 Jan 2009 08:33:39 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LLKIP-0005IN-9v; Fri, 09 Jan 2009 10:33:17 -0600 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext DRAGE, Keith \(Keith\)'" , "'ECRIT'" References: <28B7C3AA2A7ABA4A841F11217ABE78D67485802F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Date: Fri, 9 Jan 2009 11:33:21 -0500 Message-ID: <05e201c97277$fdf33920$f9d9ab60$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclyTVjnJmNS9yiwQK6hjjChYcqo2wACol8wAACw1eAABQavsA== 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] Milestone 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 If the decisions have been made, the page should reflect them. If by "decisions made" you mean "chairs have decided, ADs have not acted yet" then the page should only reflect the current chartered items. If RPH was formerly chartered, for example, it should appear. If RPH is not chartered, and it is not decided to add it on a re-charter, then we need to know why, as it seems to me that it meets the "rough consensus" test in the WG. -framework definitely should be informational. I was never sure what I should do with phonebcp. It doesn't introduce any new protocol, feature or option, it just strings them together. However, it can hardly be called a Best CURRENT Practice. I will abide by working group consensus on the matter. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Friday, January 09, 2009 8:05 AM > To: ext DRAGE, Keith (Keith); ECRIT > Subject: Re: [Ecrit] Milestone Update > > I guess you misunderstood my question. > > The decisions regarding what documents will be included in the > re-chartering of the group have been made already. > > I am only doing a webpage update to reflect more realistic dates and > text. > > > >-----Original Message----- > >From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >Sent: 09 January, 2009 14:45 > >To: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > >Subject: RE: Milestone Update > > > > > > > >> * I really didn't know what todo about the RPH document for the > >> milestone update. If I put it there (since it is already on > >our page) > >> then other draft authors would complain why there document > >isn't there > >> either. > > > >There is no reason for you to be considering all the > >candidates as a single group of documents. > > > >Either you believe there is rough consensus to move forward > >and ask for milestones on RPH, or you do not. > > > >If you do not, can we please know what the concerns are so > >they can be addressed. > > > >regards > > > >Keith > > > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >> Of Tschofenig, Hannes (NSN - FI/Espoo) > >> Sent: Friday, January 09, 2009 11:28 AM > >> To: ECRIT > >> Subject: [Ecrit] Milestone Update > >> > >> Hi all, > >> > >> I thought it might be useful to quickly update our milestones. By > >> preparing the text I ran into a few questions: > >> > >> * Wasn't PhoneBCP supposed to be a BCP? The draft says > >Standards Track > >> * The ECRIT framework drafts says Standards Track. Wouldn't > >that be an > >> informational document? > >> * Do we really need a Standards Track document for the synchronizing > >> mappings? Wouldn't an informational document be sufficient? > >> * I really didn't know what todo about the RPH document for the > >> milestone update. If I put it there (since it is already on > >our page) > >> then other draft authors would complain why there document > >isn't there > >> either. > >> > >> ------------------- > >> > >> Done Informational RFC containing terminology > >> definitions and > >> the requirements > >> Done An Informational document describing the threats and > >> security considerations > >> Done A Standards Track RFC on "A Uniform Resource > >> Name (URN) > >> for Emergency and Other Well-Known Services" > >> Done A Standards Track RFC on "Discovering LoST > >> Servers Using > >> DHCP" > >> Done A Standards Track RFC describing the > >> Location-to-Service > >> Translation (LoST) Protocol > >> Done An Informational document describing the Mapping > >> Protocol Architecture > >> Done Submit 'Location Hiding: Problem Statement and > >> Requirements' to the IESG for consideration as an Informational RFC > >> Done Submit 'Specifying Holes in LoST Service > >> Boundaries' to > >> the IESG for consideration as an Informational RFC > >> Feb 2009 Submit 'Best Current Practice for Communications > >> Services in support of Emergency Calling' to the IESG for > >> consideration as an BCP RFC > >> Feb 2009 Submit 'Framework for Emergency Calling > >using Internet > >> Multimedia' to the IESG for consideration as an Informational RFC > >> Feb 2009 Submit 'Synchronizing Location-to-Service > Translation > >> (LoST) Servers' to the IESG for consideration as an Informational > RFC > >> > >> ------------------- > >> > >> Regarding the dates: > >> > >> When am I going to see an update of Phone BCP/Framework so > >that I have > >> some reason to believe that the Feb milestone is accomplishable? > >> Based on the changes the document has seen since the last > >WGLC we have > >> todo another short one (1 week). > >> > >> Roger is working on the PROTO writeup for the LoST Sync document and > >> the Feb milestone is accomplishable. > >> > >> Thoughts? > >> > >> 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 9 14:15:41 2009 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 8FEDC3A6933; Fri, 9 Jan 2009 14:15:41 -0800 (PST) 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 7CD463A6933 for ; Fri, 9 Jan 2009 14:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[AWL=-1.427, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, TVD_SPACED_SUBJECT_WORD3=2.412] 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 HM3p7kmG6odS for ; Fri, 9 Jan 2009 14:15:36 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4025F3A63D2 for ; Fri, 9 Jan 2009 14:15:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,241,1231113600"; d="scan'208,217";a="33339766" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Jan 2009 22:15:22 +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 n09MFMLw001239; Fri, 9 Jan 2009 17:15:22 -0500 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 n09MFIGh018948; Fri, 9 Jan 2009 22:15:22 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); Fri, 9 Jan 2009 17:15:18 -0500 Received: from [10.116.195.124] ([10.116.195.124]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jan 2009 17:14:45 -0500 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 09 Jan 2009 17:14:43 -0500 From: Marc Linsner To: "'ECRIT'" , Message-ID: Thread-Topic: PhoneBCP Thread-Index: Aclyp6wloLWunEKql0a1h1SZzyfkoQ== Mime-version: 1.0 X-OriginalArrivalTime: 09 Jan 2009 22:14:45.0676 (UTC) FILETIME=[ADBD9EC0:01C972A7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4434; t=1231539322; x=1232403322; 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:=20PhoneBCP |Sender:=20 |To:=20=22'ECRIT'=22=20,=20; bh=zu7rBfKQogpjX5LhtwNWiTfnN+/ANedUMXW6+nSiawQ=; b=UssJOKcQDKblk/CKRF2NedMhdhI3jF49xAw5R+9Ppn2bUkAcN1E3iw7Z4V FikTXyYpr58OZO/TkHhOTK9hx9Ns4rXofT6FiCGbV/8nDMGYYFTPXqBPFb/J m+U21TBVqe; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Ecrit] PhoneBCP 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="===============1150552870==" 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. --===============1150552870== Content-type: multipart/alternative; boundary="B_3314366085_1912404" > 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_3314366085_1912404 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable As we tried to complete PhoneBCP, our conversation in Minneapolis uncovered another sticking point we need to resolve. >From section 6.5. ED-21/INT-12 Devices MUST support all of: DHCP location options [RFC4776] and [RFC3825], HELD [I-D.ietf-geopriv-http-location-delivery] and LLDP-MED [LLDP-MED]. AN-12/INT-13 The access network MUST support at least one of: DHCP location options, HELD or LLDP-MED. It was suggested that IEEE802.11v is an additional mechanism that a 802.11 host could utilize to discover it=B9s location. It was suggested this mechanism should be added to the list of MUST support. Then ensued a discussion of how LLDP-MED ever made it to list and why we have/need layer 2 specific mechanisms in the list. I would offer the following text to try and make progress such that we can move this document forward: ED-21/INT-12=20 Devices MUST support all of: DHCP location options [RFC4776] and [RFC3825], HELD [I-D.ietf-geopriv-http-location-delivery]. The exception to this would be a device that deploys a specific access network interface in which that access network supports location discovery such as LLDP-MED or 802.11v. In this case, the device MUST support the additional respective access network specific location discovery mechanism. AN-12/INT-13 The access network MUST support at least one of: DHCP location options, HELD, LLDP-MED, or 802.11v. Fire away, -Marc- --B_3314366085_1912404 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable PhoneBCP As we tried to complete PhoneBCP, our conversation in Minneapolis uncovere= d another sticking point we need to resolve.

>From section 6.5.

 ED-21/INT-12 Devices MUST support all of: DHCP location op= tions
   [RFC4776] and [RFC3825], HELD
   [I-D.ietf-geopriv-http-location-= delivery] and LLDP-MED [LLDP-MED].

   AN-12/INT-13 The access network MUST support at least one= of: DHCP
   location options, HELD or LLDP-MED.


It was suggested that IEEE802.11v is an additional mechanism that a 802.11 = host could utilize to discover it’s location.  It was sugg= ested this mechanism should be added to the list of MUST support.  Then= ensued a discussion of how LLDP-MED ever made it to list  and why we h= ave/need layer 2 specific mechanisms in the list.

I would offer the following text to try and make progress such that we can = move this document forward:

    ED-21/INT-12

Devices MUST support all of: DHCP location options [<= U>RFC4776] and [RFC3825], HEL= D [I-D.ietf-geopriv-http-location-delivery].

The exception to this would be a device that deploys a specific access netw= ork interface in which that access network supports location discovery such = as LLDP-MED or 802.11v.  In this case, the device MUST support the addi= tional respective access network specific location discovery mechanism.

  AN-12/INT-13

The access network MUST support at least one of: DHCP location options, HEL= D, LLDP-MED, or 802.11v.




Fire away,

-Marc-


 --B_3314366085_1912404-- --===============1150552870== 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 --===============1150552870==-- From ecrit-bounces@ietf.org Fri Jan 9 14:25:51 2009 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 DBA843A695B; Fri, 9 Jan 2009 14:25:51 -0800 (PST) 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 54CA73A697D for ; Fri, 9 Jan 2009 14:25:50 -0800 (PST) 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 N0dJ428coEfa for ; Fri, 9 Jan 2009 14:25:49 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 44EC33A6923 for ; Fri, 9 Jan 2009 14:25:49 -0800 (PST) Received: from col-dhcp33-244-152.bbn.com ([128.33.244.152]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LLPnJ-00033S-DX; Fri, 09 Jan 2009 17:25:33 -0500 Message-ID: <4967CEDC.6000307@bbn.com> Date: Fri, 09 Jan 2009 17:25:32 -0500 From: Richard Barnes User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Marc Linsner References: In-Reply-To: Cc: 'ECRIT' Subject: Re: [Ecrit] PhoneBCP 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: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Marc, Thanks for refreshing this discussion. I would revise your text as = follows to ensure that one of the IETF protocols is always usable: -----BEGIN----- ED-21/INT-12 Devices MUST support both the DHCP location options [RFC4776] [RFC3825], and HELD [I-D.ietf-geopriv-http-location-delivery]. When devices deploys a specific access network interface in which that = access network supports location discovery such as LLDP-MED or 802.11v. = In this case, the device SHOULD support the additional respective = access network specific location discovery mechanism. AN-12/INT-13 The access network MUST support either DHCP location options or HELD. = The access network SHOULD support other location technologies that are = specific to the type of access network. -----END----- Cheers, --Richard Marc Linsner wrote: > As we tried to complete PhoneBCP, our conversation in Minneapolis = > uncovered another sticking point we need to resolve. > = >>From section 6.5. > = > ED-21/INT-12 Devices MUST support all of: DHCP location options > [_RFC4776_] and [_RFC3825_], HELD > [_I-D.ietf-geopriv-http-location-delivery_] and LLDP-MED [_LLDP-MED_]. > = > AN-12/INT-13 The access network MUST support at least one of: DHCP > location options, HELD or LLDP-MED. > = > = > It was suggested that IEEE802.11v is an additional mechanism that a = > 802.11 host *could* utilize to discover it=92s location. It was suggeste= d = > this mechanism should be added to the list of MUST support. Then ensued = > a discussion of how LLDP-MED ever made it to list and why we have/need = > layer 2 specific mechanisms in the list. > = > I would offer the following text to try and make progress such that we = > can move this document forward: > = > ED-21/INT-12 > = > Devices MUST support all of: DHCP location options [_RFC4776_] and = > [_RFC3825_], HELD [_I-D.ietf-geopriv-http-location-delivery_]. > = > The exception to this would be a device that deploys a specific access = > network interface in which that access network supports location = > discovery such as LLDP-MED or 802.11v. In this case, the device MUST = > support the additional respective access network specific location = > discovery mechanism. > = > AN-12/INT-13 > = > The access network MUST support at least one of: DHCP location options, = > HELD, LLDP-MED, or 802.11v. > = > = > = > = > Fire away, > = > -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 Fri Jan 9 14:44:54 2009 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 792FD3A68DF; Fri, 9 Jan 2009 14:44:54 -0800 (PST) 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 7B99E3A68DF for ; Fri, 9 Jan 2009 14:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.024 X-Spam-Level: X-Spam-Status: No, score=-105.024 tagged_above=-999 required=5 tests=[AWL=1.348, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, 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 pDcP60iSM4p1 for ; Fri, 9 Jan 2009 14:44:48 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 7315D3A6864 for ; Fri, 9 Jan 2009 14:44:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1231541075; x=1263077075; 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<022701c970da$b36ebc10$1 a4c3430$@net>|References:=20<022701c970da$b36ebc10$1a4c34 30$@net>|Date:=20Fri,=209=20Jan=202009=2014:44:30=20-0800 |To:=20Brian=20Rosen=20,=20"'ECRIT'" =20|From:=20Ted=20Hardie=20|Subject:=20Re:=20[Ecrit]=20FW:=20FW:=20I-D=20=0D =0A=20Action:draft-rosen-ecrit-premature-disconnect-rqmts -02.txt|Content-Type:=20text/plain=3B=20charset=3D"us-asc ii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5490"=3B =20a=3D"14536889"; bh=GylSEN7pxBToCFqxylqHFaaMRkijiWZHe4inRcXApPA=; b=ujVj7cPILfvGuxSqIab8KHQPwfMl39ZrX8rvhOlyrXzJgX45mEMaPoFX BP0uRJ8juknTDSWG5yC2jormAgA8AnD9m0h9JFxE2rdOYA/a73oi5wb3e 8jgdg3zA2fjLL1yQg/efPiqzODWLTr0FSG1oZJJbtik4qAFOjFy/4ZzOr 0=; X-IronPort-AV: E=McAfee;i="5300,2777,5490"; a="14536889" 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; 09 Jan 2009 14:44:34 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n09MiYLS010768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Jan 2009 14:44:34 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n09MiYTj009077 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Jan 2009 14:44:34 -0800 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 9 Jan 2009 14:44:33 -0800 Received: from [10.227.68.233] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 9 Jan 2009 14:44:32 -0800 MIME-Version: 1.0 Message-ID: In-Reply-To: <022701c970da$b36ebc10$1a4c3430$@net> References: <022701c970da$b36ebc10$1a4c3430$@net> Date: Fri, 9 Jan 2009 14:44:30 -0800 To: Brian Rosen , "'ECRIT'" From: Ted Hardie Subject: Re: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.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 > > But the system we've put together here allows for someone in Toronto >> whose only working phone happens to tunnel back to Germany to determine >> the correct PSAP for their location and make an emergency call. How >> does >> that phone (or that network) treat the requirements for CPH? >There is no fundamental change in the social context. >You still have >stressed people making poor judgments on when to end a call, and a trained >PSAP call taker better able to determine when to end the call. The networks >are, certainly, more complex. The requirements, and the proposed mechanisms >have always dealt with the circumstance you are describing adequately: the >feature is enabled call by call at the PSAP and works across complex >networks such as the ones you describe. I believe that the mechanisms you've described so far would only work across complex networks provided every network in the world was aware of and obedient to this signalling. The "don't tear down flows" requirement is pretty much not how things work in many networks now, and this would require all networks now to watch for signalling and keep state in a way they do not. Could we get there? With enough will, certainly. But "works across complex networks" does not seem to describe the current state of play. It is possible that I am misunderstanding the mechanisms proposed. That wouldn't be unlikely and would probably be at least partly my fault, since I've been among those asking for the requirements to be worked out prior to the mechanisms being developed. Sorry, if so. > > > > > > Perhaps by making a requirement that there is a need for agreement >> here between the human user and the PSAP on who should have this >> control? Since this isn't the same in all jurisdictions, you can have >> a mismatch both ways. >But there isn't a negotiation between the caller and the PSAP. The >requirement we have is that the PSAP asserts control, and the user can >override. That is described. To implement that, I think signaling needs >negotiation (both so the caller side knows what to do, and the PSAP knows >whether it's going to be able to assert control). And here is the crux of the matter. The PSAPs want to assert control. That will violate the principle of least surprise for at least some users who come from different jurisdictions or whose phones using other technologies do not behave this way, and it will not be desired by others even if they aren't surprised by it . > > >You are stuck on the possibility the user actually does know better than the >PSAP what is happening. I see a tension here you do not. The user should always be in control of the device, unless they surrender that control voluntarily. The extreme example of this is the one Marc mentioned: no one else should be able to brick your phone in an emergency. The other examples given have been knocked back as unlikely (the abuser/home intruder example, where the hang up *must* happen, the anonymous tip example, etc.). Maybe those are unlikely in the world these PSAPs serve. But the possibility of abuse here is also pretty scary, even if it abuse by authorities in jurisdictions different from the current users of the related feature. We have to get this right if we do it, and that means we have to treat the desires of both parties. From my way of thinking that implies a much more negotiated approach than the "PSAP desires control this" tone of the proposals to date. Absent a willingness to do that, I will move on to the position "this is a bad idea, let's not do it". You may well get rough consensus over my objections, but I would rather than you heard them and took them seriously. If I have not said so lately, let me repeat: thanks for your work on this. Please understand my comments are not meant to frustrate you or the work; they are meant to help get it right. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 13 07:45:10 2009 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 758493A67FF; Tue, 13 Jan 2009 07:45:10 -0800 (PST) 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 05D0A3A6920 for ; Tue, 13 Jan 2009 07:45:09 -0800 (PST) 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 g0NfRyw-YoNX for ; Tue, 13 Jan 2009 07:45:08 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id EAC193A67FF for ; Tue, 13 Jan 2009 07:45:07 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0DFigqf027580; Tue, 13 Jan 2009 17:44:49 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Jan 2009 17:44:42 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Jan 2009 17:44:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Jan 2009 17:44:34 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Ecrit] HUM regarding draft-patel-ecrit-sos-parameter-02.txt Thread-Index: Acl1ldVi7qg1TEBEToydgOJ4Yyc6Uw== From: To: , X-OriginalArrivalTime: 13 Jan 2009 15:44:42.0415 (UTC) FILETIME=[D9F663F0:01C97595] X-Nokia-AV: Clean Subject: Re: [Ecrit] HUM regarding draft-patel-ecrit-sos-parameter-02.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="===============1910550222==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1910550222== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97595.D9F0A425" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97595.D9F0A425 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, we support this draft to go forward. Best regards Georg (humming) ------_=_NextPart_001_01C97595.D9F0A425 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] HUM regarding = draft-patel-ecrit-sos-parameter-02.txt

Hello,

we support this draft = to go forward.

Best = regards
Georg = (humming)

------_=_NextPart_001_01C97595.D9F0A425-- --===============1910550222== 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 --===============1910550222==-- From ecrit-bounces@ietf.org Tue Jan 13 10:30:32 2009 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 09EB33A6A3A; Tue, 13 Jan 2009 10:30:32 -0800 (PST) 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 DE2C03A6A3A for ; Tue, 13 Jan 2009 10:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.026, 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 LBZN6rYaGbCq for ; Tue, 13 Jan 2009 10:30:29 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 8155F3A6994 for ; Tue, 13 Jan 2009 10:30:29 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LMo1a-0008T3-07; Tue, 13 Jan 2009 12:30:06 -0600 From: "Brian Rosen" To: "'Ted Hardie'" , "'ECRIT'" References: <022701c970da$b36ebc10$1a4c3430$@net> In-Reply-To: Date: Tue, 13 Jan 2009 13:30:07 -0500 Message-ID: <030b01c975ac$f9d0b880$ed722980$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aclyq9JM14ls2jnpRyK1atiifTXdzAC/thfQ 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] FW: FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.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'm trying to solve a problem where the user is doing the wrong thing. By definition, his opinion is that he should terminate the call. "Negotiating" with the user is not possible. We can do something and provide an override, but it doesn't work to negotiate with the user. I do understand the "intruder" problem. I'd like to be able to solve that in the best possible way. If the user really knew what was happening, they would pull the battery out of the device, because any phone can be called any time. That's not a reasonable response, and I understand that. We have a balance to strike. Of course the override could and probably should be proactive (that is, if you should be able to invoke the override before you terminate). That is also not a complete answer. It seems to me that the incidence of bad judgment causing serious problems is so much more common than the intruder's shouldn't hear alerting that we ought to compromise in a way that facilitates the former rather than the latter. Although I'm not entirely comfortable taking that position, I'm a heck of a lot more comfortable with that then any other proposed solution. I'm not at all worried about the "least surprise" issue with people coming in from other jurisdictions. Surprise is the most common reaction to people in the jurisdictions it's been implemented in, mostly because you don't make emergency calls very often. Most Canadians don't know that the PSAP can control termination on wireline calls. The current proposed mechanism is that you negotiate the feature with a full 3 way handshake. Then, normally, instead of termination, you signal hookstate. If you get stuck (the signaling of hookstate doesn't complete, or the override is triggered), you terminate. The PSAP has a way to alert. All that is required to make this work in complex networks is that the negotiation mechanism and the hookstate signaling mechanism is transparent to networks and devices other than the UAS and the UAC. If either end really does send BYE, the call terminates. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Friday, January 09, 2009 5:45 PM > To: Brian Rosen; 'ECRIT' > Subject: Re: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature- > disconnect-rqmts-02.txt > > > > But the system we've put together here allows for someone in > Toronto > >> whose only working phone happens to tunnel back to Germany to > determine > >> the correct PSAP for their location and make an emergency call. How > >> does > >> that phone (or that network) treat the requirements for CPH? > >There is no fundamental change in the social context. > >You still have > >stressed people making poor judgments on when to end a call, and a > trained > >PSAP call taker better able to determine when to end the call. The > networks > >are, certainly, more complex. The requirements, and the proposed > mechanisms > >have always dealt with the circumstance you are describing adequately: > the > >feature is enabled call by call at the PSAP and works across complex > >networks such as the ones you describe. > > I believe that the mechanisms you've described so far would only work > across complex networks provided every network in the world was aware > of and obedient to this signalling. The "don't tear down flows" > requirement > is pretty much not how things work in many networks now, and this would > require all networks now to watch for signalling and keep state in a > way > they do not. > > Could we get there? With enough will, certainly. But "works across > complex > networks" does not seem to describe the current state of play. It is > possible > that I am misunderstanding the mechanisms proposed. That wouldn't > be unlikely and would probably be at least partly my fault, since I've > been > among those asking for the requirements to be worked out prior to the > mechanisms being developed. Sorry, if so. > > > > > > > > > > Perhaps by making a requirement that there is a need for agreement > >> here between the human user and the PSAP on who should have this > >> control? Since this isn't the same in all jurisdictions, you can > have > >> a mismatch both ways. > > > > >But there isn't a negotiation between the caller and the PSAP. The > >requirement we have is that the PSAP asserts control, and the user can > >override. That is described. To implement that, I think signaling > needs > >negotiation (both so the caller side knows what to do, and the PSAP > knows > >whether it's going to be able to assert control). > > And here is the crux of the matter. The PSAPs want to assert control. > That will violate the principle of least surprise for at least some > users > who come from different jurisdictions or whose phones using other > technologies do not behave this way, and it will not be desired by > others even if they aren't surprised by it > . > > > > >You are stuck on the possibility the user actually does know better > than the > >PSAP what is happening. > > I see a tension here you do not. The user should always be in control > of the device, unless they surrender that control voluntarily. The > extreme example of this is the one Marc mentioned: no one else should > be able to brick your phone in an emergency. The other examples given > have been knocked back as unlikely (the abuser/home intruder example, > where the hang up *must* happen, the anonymous tip example, etc.). > Maybe those are unlikely in the world these PSAPs serve. But the > possibility of > abuse here is also pretty scary, even if it abuse by authorities in > jurisdictions > different from the current users of the related feature. > > We have to get this right if we do it, and that means we have to treat > the desires of both parties. From my way of thinking that implies a > much more negotiated approach than the "PSAP desires control this" > tone of the proposals to date. Absent a willingness to do that, I will > move on to the position "this is a bad idea, let's not do it". > You may well get rough consensus over my objections, but I would > rather than you heard them and took them seriously. > > If I have not said so lately, let me repeat: thanks for your work on > this. Please understand my comments are not meant to frustrate you > or the work; they are meant to help get it right. > > Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 14 05:46:47 2009 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 0188E3A6B61; Wed, 14 Jan 2009 05:46:47 -0800 (PST) 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 D0A163A6B61 for ; Wed, 14 Jan 2009 05:46:45 -0800 (PST) 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 0PdDTF+GLYXX for ; Wed, 14 Jan 2009 05:46:45 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id A9A163A6B60 for ; Wed, 14 Jan 2009 05:46:44 -0800 (PST) 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 n0EDkONZ032243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Jan 2009 14:46:24 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0EDkOtL003578; Wed, 14 Jan 2009 14:46:24 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 14:46:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jan 2009 14:46:22 +0100 Message-ID: <81D3255A15981A4B912531E3648B1E16016CB905@DEMUEXC005.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] HUM regarding draft-patel-ecrit-sos-parameter-02.txt Thread-Index: Acl1ldVi7qg1TEBEToydgOJ4Yyc6UwAsn/vw References: From: "Leis, Peter (NSN - DE/Munich)" To: X-OriginalArrivalTime: 14 Jan 2009 13:46:23.0783 (UTC) FILETIME=[7D42DB70:01C9764E] Subject: Re: [Ecrit] HUM regarding draft-patel-ecrit-sos-parameter-02.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="===============0747619240==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0747619240== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9764E.7D2C612D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9764E.7D2C612D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 we support the work on this document. =20 regards Peter =20 > -----Original Message----- > From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]=20 > On Behalf Of Hannes Tschofenig > Sent: Tuesday, December 30, 2008 1:51 PM > To: ECRIT > Subject: [Ecrit] HUM regarding draft-patel-ecrit-sos-parameter-02.txt >=20 > Hi all,=20 >=20 > At IETF#73 we had a discussion regarding=20 > draft-patel-ecrit-sos-parameter-01.txt and the feedback that=20 > was provided lead to an updated draft:=20 > http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-02 >=20 > This new document focuses on the "sos" registration only as=20 > described by Milan in his recent mail to the list:=20 > http://www.ietf.org/mail-archive/web/ecrit/current/msg05779.html >=20 > This document is work we would be doing for the 3GPP.=20 >=20 > According to the meeting minutes there was positive support=20 > for working on this document during IETF#73, see=20 > http://www.ietf.org/proceedings/08nov/minutes/ecrit.txt.=20 >=20 > Please let me us know whether you have objections or whether=20 > you are in support of this document (if you haven't stated=20 > your opinion already). >=20 > Deadline: 16. Jan. 2009 >=20 > Ciao > Hannes & Marc >=20 ------_=_NextPart_001_01C9764E.7D2C612D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] HUM regarding = draft-patel-ecrit-sos-parameter-02.txt
Hello,
 
we support the work on this = document.
 
regards
Peter
 
> -----Original Message-----
> = From:=20 ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
> On Behalf = Of Hannes=20 Tschofenig
> Sent: Tuesday, December 30, 2008 1:51 PM
> To:=20 ECRIT
> Subject: [Ecrit] HUM regarding=20 draft-patel-ecrit-sos-parameter-02.txt
>
> Hi all,
> =
> At IETF#73 we had a discussion regarding
>=20 draft-patel-ecrit-sos-parameter-01.txt and the feedback that
> = was=20 provided lead to an updated draft:
> http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter= -02
>=20
> This new document focuses on the "sos" registration only as =
>=20 described by Milan in his recent mail to the list:
> http://www.ietf.org/mail-archive/web/ecrit/current/msg0577= 9.html
>=20
> This document is work we would be doing for the 3GPP.
> =
>=20 According to the meeting minutes there was positive support
> for = working=20 on this document during IETF#73, see
> http://www.ietf.org/proceedings/08nov/minutes/ecrit.txt.=20
>
> Please let me us know whether you have objections or = whether=20
> you are in support of this document (if you haven't stated =
>=20 your opinion already).
>
> Deadline: 16. Jan. 2009
> =
>=20 Ciao
> Hannes & Marc
>
------_=_NextPart_001_01C9764E.7D2C612D-- --===============0747619240== 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 --===============0747619240==-- From ecrit-bounces@ietf.org Wed Jan 14 09:19:01 2009 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 3F8943A69FB; Wed, 14 Jan 2009 09:19:01 -0800 (PST) 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 3567F3A69FB for ; Wed, 14 Jan 2009 09:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.001 X-Spam-Level: X-Spam-Status: No, score=-6.001 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 VzsWlm4nXF6k for ; Wed, 14 Jan 2009 09:18:59 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 7B36E3A6359 for ; Wed, 14 Jan 2009 09:18:58 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n0EHIbbe022582 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 Jan 2009 18:18:37 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 14 Jan 2009 18:18:36 +0100 From: "DRAGE, Keith (Keith)" To: Brian Rosen , "'Ted Hardie'" , "'ECRIT'" Date: Wed, 14 Jan 2009 18:18:34 +0100 Thread-Topic: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt Thread-Index: Aclyq9JM14ls2jnpRyK1atiifTXdzAC/thfQADBT/iA= Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674895D3F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <022701c970da$b36ebc10$1a4c3430$@net> <030b01c975ac$f9d0b880$ed722980$@net> In-Reply-To: <030b01c975ac$f9d0b880$ed722980$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.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 the risk of backward engineering, I don't find a requirement at the moment that would lead to this being adopted as a solution. I believe I made comments to the effect that we need to deal with compatibility in my review. Keith > The current proposed mechanism is that you negotiate the > feature with a full > 3 way handshake. Then, normally, instead of termination, you > signal hookstate. If you get stuck (the signaling of > hookstate doesn't complete, or the override is triggered), > you terminate. The PSAP has a way to alert. > All that is required to make this work in complex networks is > that the negotiation mechanism and the hookstate signaling > mechanism is transparent to networks and devices other than > the UAS and the UAC. If either end really does send BYE, the > call terminates. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Tuesday, January 13, 2009 6:30 PM > To: 'Ted Hardie'; 'ECRIT' > Subject: Re: [Ecrit] FW: FW: I-D > Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt > > I'm trying to solve a problem where the user is doing the > wrong thing. By definition, his opinion is that he should > terminate the call. "Negotiating" > with the user is not possible. We can do something and > provide an override, but it doesn't work to negotiate with the user. > > I do understand the "intruder" problem. I'd like to be able > to solve that in the best possible way. If the user really > knew what was happening, they would pull the battery out of > the device, because any phone can be called any time. That's > not a reasonable response, and I understand that. We have a > balance to strike. Of course the override could and probably > should be proactive (that is, if you should be able to invoke > the override before you terminate). That is also not a > complete answer. It seems to me that the incidence of bad > judgment causing serious problems is so much more common than > the intruder's shouldn't hear alerting that we ought to > compromise in a way that facilitates the former rather than > the latter. Although I'm not entirely comfortable taking > that position, I'm a heck of a lot more comfortable with that > then any other proposed solution. > > I'm not at all worried about the "least surprise" issue with > people coming in from other jurisdictions. Surprise is the > most common reaction to people in the jurisdictions it's been > implemented in, mostly because you don't make emergency calls > very often. Most Canadians don't know that the PSAP can > control termination on wireline calls. > > The current proposed mechanism is that you negotiate the > feature with a full > 3 way handshake. Then, normally, instead of termination, you > signal hookstate. If you get stuck (the signaling of > hookstate doesn't complete, or the override is triggered), > you terminate. The PSAP has a way to alert. > All that is required to make this work in complex networks is > that the negotiation mechanism and the hookstate signaling > mechanism is transparent to networks and devices other than > the UAS and the UAC. If either end really does send BYE, the > call terminates. > > Brian > > > -----Original Message----- > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > Sent: Friday, January 09, 2009 5:45 PM > > To: Brian Rosen; 'ECRIT' > > Subject: Re: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature- > > disconnect-rqmts-02.txt > > > > > > But the system we've put together here allows for someone in > > Toronto > > >> whose only working phone happens to tunnel back to Germany to > > determine > > >> the correct PSAP for their location and make an emergency call. > > >> How does that phone (or that network) treat the requirements for > > >> CPH? > > >There is no fundamental change in the social context. > > >You still have > > >stressed people making poor judgments on when to end a call, and a > > trained > > >PSAP call taker better able to determine when to end the call. The > > networks > > >are, certainly, more complex. The requirements, and the proposed > > mechanisms > > >have always dealt with the circumstance you are describing > adequately: > > the > > >feature is enabled call by call at the PSAP and works > across complex > > >networks such as the ones you describe. > > > > I believe that the mechanisms you've described so far would > only work > > across complex networks provided every network in the world > was aware > > of and obedient to this signalling. The "don't tear down flows" > > requirement > > is pretty much not how things work in many networks now, and this > > would require all networks now to watch for signalling and > keep state > > in a way they do not. > > > > Could we get there? With enough will, certainly. But > "works across > > complex networks" does not seem to describe the current > state of play. > > It is possible that I am misunderstanding the mechanisms proposed. > > That wouldn't be unlikely and would probably be at least partly my > > fault, since I've been among those asking for the > requirements to be > > worked out prior to the mechanisms being developed. Sorry, if so. > > > > > > > > > > > > > > Perhaps by making a requirement that there is a need > for agreement > > >> here between the human user and the PSAP on who should have this > > >> control? Since this isn't the same in all jurisdictions, you can > > have > > >> a mismatch both ways. > > > > > > > > >But there isn't a negotiation between the caller and the > PSAP. The > > >requirement we have is that the PSAP asserts control, and the user > > >can override. That is described. To implement that, I think > > >signaling > > needs > > >negotiation (both so the caller side knows what to do, and the PSAP > > knows > > >whether it's going to be able to assert control). > > > > And here is the crux of the matter. The PSAPs want to > assert control. > > That will violate the principle of least surprise for at least some > > users who come from different jurisdictions or whose phones using > > other technologies do not behave this way, and it will not > be desired > > by others even if they aren't surprised by it . > > > > > > >You are stuck on the possibility the user actually does know better > > than the > > >PSAP what is happening. > > > > I see a tension here you do not. The user should always be > in control > > of the device, unless they surrender that control voluntarily. The > > extreme example of this is the one Marc mentioned: no one > else should > > be able to brick your phone in an emergency. The other > examples given > > have been knocked back as unlikely (the abuser/home > intruder example, > > where the hang up *must* happen, the anonymous tip example, etc.). > > Maybe those are unlikely in the world these PSAPs serve. But the > > possibility of abuse here is also pretty scary, even if it abuse by > > authorities in jurisdictions different from the current > users of the > > related feature. > > > > We have to get this right if we do it, and that means we > have to treat > > the desires of both parties. From my way of thinking that > implies a > > much more negotiated approach than the "PSAP desires control this" > > tone of the proposals to date. Absent a willingness to do > that, I will > > move on to the position "this is a bad idea, let's not do it". > > You may well get rough consensus over my objections, but I would > > rather than you heard them and took them seriously. > > > > If I have not said so lately, let me repeat: thanks for > your work on > > this. Please understand my comments are not meant to > frustrate you or > > the work; they are meant to help get it right. > > > > 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 Jan 14 09:24:27 2009 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 785E23A69CF; Wed, 14 Jan 2009 09:24:27 -0800 (PST) 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 403AE3A69CF for ; Wed, 14 Jan 2009 09:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.07 X-Spam-Level: X-Spam-Status: No, score=-103.07 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 Fr3Kpk7UP6C3 for ; Wed, 14 Jan 2009 09:24:25 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 4E37F3A69B8 for ; Wed, 14 Jan 2009 09:24:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1231953851; x=1263489851; 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<030b01c975ac$f9d0b880$e d722980$@net>|References:=20<022701c970da$b36ebc10$1a4c34 30$@net>=0D=0A=20 =0D=0A=20<030b01c975ac$f9d0b880$ed722980$@net>|Date:=20We d,=2014=20Jan=202009=2009:24:06=20-0800|To:=20Brian=20Ros en=20,=20"'ECRIT'"=20 |From:=20Ted=20Hardie=20|Subject:=20 RE:=20[Ecrit]=20FW:=20FW:=20I-D=20=20=0D=0A=20Action:draf t-rosen-ecrit-premature-disconnect-rqmts-02.txt |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5495"=3B=20a =3D"14625774"; bh=7kIPsM/+QNVYMpiUW1UsIryGukfaKQa1zwmWVJqCR80=; b=KwfzalYqMSBwLPOcpXN1Bs3APtv1v4GFmVZO3+ukdQcKcTOSims3nLuY FvBo4tfbVp+MgV3ng3QOAbtNM4za3OEACLIKUIKe3aTGFfPo0N4MjAEg9 ma9gzWdkAT2i7bbE1eVqdSa9lFFLUYA9ym9qyoxPLtH5cw2lgqI4i1Ack 4=; X-IronPort-AV: E=McAfee;i="5100,188,5495"; a="14625774" 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; 14 Jan 2009 09:24:10 -0800 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 n0EHO9SA004149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Jan 2009 09:24:10 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0EHO9BH000403 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 Jan 2009 09:24:09 -0800 (PST) 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.336.0; Wed, 14 Jan 2009 09:24:08 -0800 Received: from [10.227.50.125] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.336.0; Wed, 14 Jan 2009 09:24:08 -0800 MIME-Version: 1.0 Message-ID: In-Reply-To: <030b01c975ac$f9d0b880$ed722980$@net> References: <022701c970da$b36ebc10$1a4c3430$@net> <030b01c975ac$f9d0b880$ed722980$@net> Date: Wed, 14 Jan 2009 09:24:06 -0800 To: Brian Rosen , "'ECRIT'" From: Ted Hardie Subject: Re: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.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 10:30 AM -0800 1/13/09, Brian Rosen wrote: >I'm trying to solve a problem where the user is doing the wrong thing. By >definition, his opinion is that he should terminate the call. And you are substituting the PSAP call taker's judgement for the individual user's because it is statistically better. But, as the "intruder" case discussed below makes clear, there are times when you already acknowledge that the user's judgement is better. >"Negotiating" >with the user is not possible. We can do something and provide an override, >but it doesn't work to negotiate with the user. > >I do understand the "intruder" problem. I'm glad that we have at least this common ground. >I'd like to be able to solve that >in the best possible way. If the user really knew what was happening, they >would pull the battery out of the device, because any phone can be called >any time. Note that in the "abuser" version of this, it really makes a difference as to who calls (and the abused may be hurt for failing to respond to the abuser's call as well as abused for reaching out for help). >That's not a reasonable response, and I understand that. We have >a balance to strike. Of course the override could and probably should be >proactive (that is, if you should be able to invoke the override before you >terminate). Do you see it as reasonable to invoke the over-ride before the call starts? That is, start the call in a state so that the PSAP knows it would not get the right to control the ending? I would be more comfortable with this capability, as it also addresses the other concern--use/abuse of this facility by non-PSAP uses. If users can start a call in way that prevents this facility being used, users can choose to operate in this manner in contexts where they fear abuse of the facility. > That is also not a complete answer. It seems to me that the >incidence of bad judgment causing serious problems is so much more common >than the intruder's shouldn't hear alerting that we ought to compromise in a >way that facilitates the former rather than the latter. Although I'm not >entirely comfortable taking that position, I'm a heck of a lot more >comfortable with that then any other proposed solution. I would guess that you're not comfortable with it for the same reason I am not. It's hard to face someone whose situation got worse with the reasoning "well, statistically things got better". >I'm not at all worried about the "least surprise" issue with people coming >in from other jurisdictions. Surprise is the most common reaction to people >in the jurisdictions it's been implemented in, mostly because you don't make >emergency calls very often. Most Canadians don't know that the PSAP can >control termination on wireline calls. This sounds like a great way to further fluster folks who are already apparently too nervous to do the right thing. >The current proposed mechanism is that you negotiate the feature with a full >3 way handshake. So UA can simply fail to support the feature during this handshake as a form of negotiation? > Then, normally, instead of termination, you signal >hookstate. If you get stuck (the signaling of hookstate doesn't complete, >or the override is triggered), you terminate. The PSAP has a way to alert. >All that is required to make this work in complex networks is that the >negotiation mechanism and the hookstate signaling mechanism is transparent >to networks and devices other than the UAS and the UAC. If either end >really does send BYE, the call terminates. I guess I don't understand how the UA sends BYE here (and thus how this remains "either end really does send BYE). regards, Ted Hardie >Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jan 14 11:54:21 2009 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 6439628C1FA; Wed, 14 Jan 2009 11:54:21 -0800 (PST) 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 0BEE228C1FA for ; Wed, 14 Jan 2009 11:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.007, 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 xz6icnsWBfqd for ; Wed, 14 Jan 2009 11:54:18 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 03AD128C1FB for ; Wed, 14 Jan 2009 11:54:18 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LNBoE-0003iz-Qi; Wed, 14 Jan 2009 13:53:51 -0600 From: "Brian Rosen" To: "'DRAGE, Keith \(Keith\)'" , "'Ted Hardie'" , "'ECRIT'" References: <022701c970da$b36ebc10$1a4c3430$@net> <030b01c975ac$f9d0b880$ed722980$@net> <28B7C3AA2A7ABA4A841F11217ABE78D674895D3F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D674895D3F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Wed, 14 Jan 2009 14:54:01 -0500 Message-ID: <05d101c97681$dae5c5c0$90b15140$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aclyq9JM14ls2jnpRyK1atiifTXdzAC/thfQADBT/iAABUV4YA== 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] FW: FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.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 sorry to be dense, but I can't seem to connect the dots here. Compatibility with what? I have agreed to work requirements first, mechanisms later, but we all have difficulty keeping such priorities. Most of us are engineers at heart and if we don't see at least one solution, we're likely not going to be able to continue to work on the problem. That doesn't mean that better solutions won't occur to us or others. In this case, I am definitely not wedded to a particular solution, I do think the requirements are getting very fuzzy (because of the limitation to discuss it in human terms only), but I'm soldiering on. The requirement that you selectively negotiate call-by-call, that the PSAP understands the state of the device, and can control termination following negotiation, and yet fail safe, leads to the proposed solution. If you have a better idea, great. Brian > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Wednesday, January 14, 2009 12:19 PM > To: Brian Rosen; 'Ted Hardie'; 'ECRIT' > Subject: RE: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature- > disconnect-rqmts-02.txt > > At the risk of backward engineering, I don't find a requirement at the > moment that would lead to this being adopted as a solution. > > I believe I made comments to the effect that we need to deal with > compatibility in my review. > > Keith > > > The current proposed mechanism is that you negotiate the > > feature with a full > > 3 way handshake. Then, normally, instead of termination, you > > signal hookstate. If you get stuck (the signaling of > > hookstate doesn't complete, or the override is triggered), > > you terminate. The PSAP has a way to alert. > > All that is required to make this work in complex networks is > > that the negotiation mechanism and the hookstate signaling > > mechanism is transparent to networks and devices other than > > the UAS and the UAC. If either end really does send BYE, the > > call terminates. > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Brian Rosen > > Sent: Tuesday, January 13, 2009 6:30 PM > > To: 'Ted Hardie'; 'ECRIT' > > Subject: Re: [Ecrit] FW: FW: I-D > > Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt > > > > I'm trying to solve a problem where the user is doing the > > wrong thing. By definition, his opinion is that he should > > terminate the call. "Negotiating" > > with the user is not possible. We can do something and > > provide an override, but it doesn't work to negotiate with the user. > > > > I do understand the "intruder" problem. I'd like to be able > > to solve that in the best possible way. If the user really > > knew what was happening, they would pull the battery out of > > the device, because any phone can be called any time. That's > > not a reasonable response, and I understand that. We have a > > balance to strike. Of course the override could and probably > > should be proactive (that is, if you should be able to invoke > > the override before you terminate). That is also not a > > complete answer. It seems to me that the incidence of bad > > judgment causing serious problems is so much more common than > > the intruder's shouldn't hear alerting that we ought to > > compromise in a way that facilitates the former rather than > > the latter. Although I'm not entirely comfortable taking > > that position, I'm a heck of a lot more comfortable with that > > then any other proposed solution. > > > > I'm not at all worried about the "least surprise" issue with > > people coming in from other jurisdictions. Surprise is the > > most common reaction to people in the jurisdictions it's been > > implemented in, mostly because you don't make emergency calls > > very often. Most Canadians don't know that the PSAP can > > control termination on wireline calls. > > > > The current proposed mechanism is that you negotiate the > > feature with a full > > 3 way handshake. Then, normally, instead of termination, you > > signal hookstate. If you get stuck (the signaling of > > hookstate doesn't complete, or the override is triggered), > > you terminate. The PSAP has a way to alert. > > All that is required to make this work in complex networks is > > that the negotiation mechanism and the hookstate signaling > > mechanism is transparent to networks and devices other than > > the UAS and the UAC. If either end really does send BYE, the > > call terminates. > > > > Brian > > > > > -----Original Message----- > > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > > Sent: Friday, January 09, 2009 5:45 PM > > > To: Brian Rosen; 'ECRIT' > > > Subject: Re: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit- > premature- > > > disconnect-rqmts-02.txt > > > > > > > > But the system we've put together here allows for someone in > > > Toronto > > > >> whose only working phone happens to tunnel back to Germany to > > > determine > > > >> the correct PSAP for their location and make an emergency call. > > > >> How does that phone (or that network) treat the requirements for > > > >> CPH? > > > >There is no fundamental change in the social context. > > > >You still have > > > >stressed people making poor judgments on when to end a call, and a > > > trained > > > >PSAP call taker better able to determine when to end the call. > The > > > networks > > > >are, certainly, more complex. The requirements, and the proposed > > > mechanisms > > > >have always dealt with the circumstance you are describing > > adequately: > > > the > > > >feature is enabled call by call at the PSAP and works > > across complex > > > >networks such as the ones you describe. > > > > > > I believe that the mechanisms you've described so far would > > only work > > > across complex networks provided every network in the world > > was aware > > > of and obedient to this signalling. The "don't tear down flows" > > > requirement > > > is pretty much not how things work in many networks now, and this > > > would require all networks now to watch for signalling and > > keep state > > > in a way they do not. > > > > > > Could we get there? With enough will, certainly. But > > "works across > > > complex networks" does not seem to describe the current > > state of play. > > > It is possible that I am misunderstanding the mechanisms proposed. > > > That wouldn't be unlikely and would probably be at least partly my > > > fault, since I've been among those asking for the > > requirements to be > > > worked out prior to the mechanisms being developed. Sorry, if so. > > > > > > > > > > > > > > > > > > Perhaps by making a requirement that there is a need > > for agreement > > > >> here between the human user and the PSAP on who should have this > > > >> control? Since this isn't the same in all jurisdictions, you > can > > > have > > > >> a mismatch both ways. > > > > > > > > > > > > >But there isn't a negotiation between the caller and the > > PSAP. The > > > >requirement we have is that the PSAP asserts control, and the user > > > >can override. That is described. To implement that, I think > > > >signaling > > > needs > > > >negotiation (both so the caller side knows what to do, and the > PSAP > > > knows > > > >whether it's going to be able to assert control). > > > > > > And here is the crux of the matter. The PSAPs want to > > assert control. > > > That will violate the principle of least surprise for at least some > > > users who come from different jurisdictions or whose phones using > > > other technologies do not behave this way, and it will not > > be desired > > > by others even if they aren't surprised by it . > > > > > > > > >You are stuck on the possibility the user actually does know > better > > > than the > > > >PSAP what is happening. > > > > > > I see a tension here you do not. The user should always be > > in control > > > of the device, unless they surrender that control voluntarily. The > > > extreme example of this is the one Marc mentioned: no one > > else should > > > be able to brick your phone in an emergency. The other > > examples given > > > have been knocked back as unlikely (the abuser/home > > intruder example, > > > where the hang up *must* happen, the anonymous tip example, etc.). > > > Maybe those are unlikely in the world these PSAPs serve. But the > > > possibility of abuse here is also pretty scary, even if it abuse by > > > authorities in jurisdictions different from the current > > users of the > > > related feature. > > > > > > We have to get this right if we do it, and that means we > > have to treat > > > the desires of both parties. From my way of thinking that > > implies a > > > much more negotiated approach than the "PSAP desires control this" > > > tone of the proposals to date. Absent a willingness to do > > that, I will > > > move on to the position "this is a bad idea, let's not do it". > > > You may well get rough consensus over my objections, but I would > > > rather than you heard them and took them seriously. > > > > > > If I have not said so lately, let me repeat: thanks for > > your work on > > > this. Please understand my comments are not meant to > > frustrate you or > > > the work; they are meant to help get it right. > > > > > > 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 Jan 14 16:44:41 2009 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 B545A3A6A43; Wed, 14 Jan 2009 16:44:41 -0800 (PST) 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 715093A6A43 for ; Wed, 14 Jan 2009 16:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.002 X-Spam-Level: X-Spam-Status: No, score=-6.002 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Z3Z8tkEUZmru for ; Wed, 14 Jan 2009 16:44:40 -0800 (PST) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 868A73A6A39 for ; Wed, 14 Jan 2009 16:44:38 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n0F0iFKs022060 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 15 Jan 2009 01:44:15 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 15 Jan 2009 01:44:15 +0100 From: "DRAGE, Keith (Keith)" To: Brian Rosen , "'Ted Hardie'" , "'ECRIT'" Date: Thu, 15 Jan 2009 01:44:14 +0100 Thread-Topic: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt Thread-Index: Aclyq9JM14ls2jnpRyK1atiifTXdzAC/thfQADBT/iAABUV4YAAGKLlA Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674895D9A@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <022701c970da$b36ebc10$1a4c3430$@net> <030b01c975ac$f9d0b880$ed722980$@net> <28B7C3AA2A7ABA4A841F11217ABE78D674895D3F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <05d101c97681$dae5c5c0$90b15140$@net> In-Reply-To: <05d101c97681$dae5c5c0$90b15140$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.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 fault. Common fallacy of using the word in connection with only one side. What I was trying to say is that we need requirements to deal with operation with entities that want to provide the capability, and those that do not. But the key point I was making is that you are now mentioning a negotiation mechanism for which there is no underlying requirement. I would like you to express the requirement in the draft that the solution is meant to meet. regards Keith > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, January 14, 2009 7:54 PM > To: DRAGE, Keith (Keith); 'Ted Hardie'; 'ECRIT' > Subject: RE: [Ecrit] FW: FW: I-D > Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt > > I am sorry to be dense, but I can't seem to connect the dots here. > > Compatibility with what? > > I have agreed to work requirements first, mechanisms later, > but we all have difficulty keeping such priorities. Most of > us are engineers at heart and if we don't see at least one > solution, we're likely not going to be able to continue to > work on the problem. That doesn't mean that better solutions > won't occur to us or others. > > In this case, I am definitely not wedded to a particular > solution, I do think the requirements are getting very fuzzy > (because of the limitation to discuss it in human terms > only), but I'm soldiering on. The requirement that you > selectively negotiate call-by-call, that the PSAP understands > the state of the device, and can control termination > following negotiation, and yet fail safe, leads to the > proposed solution. If you have a better idea, great. > > Brian > > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: Wednesday, January 14, 2009 12:19 PM > > To: Brian Rosen; 'Ted Hardie'; 'ECRIT' > > Subject: RE: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature- > > disconnect-rqmts-02.txt > > > > At the risk of backward engineering, I don't find a > requirement at the > > moment that would lead to this being adopted as a solution. > > > > I believe I made comments to the effect that we need to deal with > > compatibility in my review. > > > > Keith > > > > > The current proposed mechanism is that you negotiate the feature > > > with a full > > > 3 way handshake. Then, normally, instead of termination, > you signal > > > hookstate. If you get stuck (the signaling of hookstate doesn't > > > complete, or the override is triggered), you terminate. The PSAP > > > has a way to alert. > > > All that is required to make this work in complex > networks is that > > > the negotiation mechanism and the hookstate signaling > mechanism is > > > transparent to networks and devices other than the UAS > and the UAC. > > > If either end really does send BYE, the call terminates. > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > > Behalf Of Brian Rosen > > > Sent: Tuesday, January 13, 2009 6:30 PM > > > To: 'Ted Hardie'; 'ECRIT' > > > Subject: Re: [Ecrit] FW: FW: I-D > > > Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt > > > > > > I'm trying to solve a problem where the user is doing the wrong > > > thing. By definition, his opinion is that he should > terminate the > > > call. "Negotiating" > > > with the user is not possible. We can do something and > provide an > > > override, but it doesn't work to negotiate with the user. > > > > > > I do understand the "intruder" problem. I'd like to be able to > > > solve that in the best possible way. If the user really > knew what > > > was happening, they would pull the battery out of the device, > > > because any phone can be called any time. That's not a > reasonable > > > response, and I understand that. We have a balance to > strike. Of > > > course the override could and probably should be > proactive (that is, > > > if you should be able to invoke the override before you > terminate). > > > That is also not a complete answer. It seems to me that the > > > incidence of bad judgment causing serious problems is so > much more > > > common than the intruder's shouldn't hear alerting that > we ought to > > > compromise in a way that facilitates the former rather than the > > > latter. Although I'm not entirely comfortable taking > that position, > > > I'm a heck of a lot more comfortable with that then any other > > > proposed solution. > > > > > > I'm not at all worried about the "least surprise" issue > with people > > > coming in from other jurisdictions. Surprise is the most common > > > reaction to people in the jurisdictions it's been implemented in, > > > mostly because you don't make emergency calls very often. Most > > > Canadians don't know that the PSAP can control termination on > > > wireline calls. > > > > > > The current proposed mechanism is that you negotiate the feature > > > with a full > > > 3 way handshake. Then, normally, instead of termination, > you signal > > > hookstate. If you get stuck (the signaling of hookstate doesn't > > > complete, or the override is triggered), you terminate. The PSAP > > > has a way to alert. > > > All that is required to make this work in complex > networks is that > > > the negotiation mechanism and the hookstate signaling > mechanism is > > > transparent to networks and devices other than the UAS > and the UAC. > > > If either end really does send BYE, the call terminates. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > > > Sent: Friday, January 09, 2009 5:45 PM > > > > To: Brian Rosen; 'ECRIT' > > > > Subject: Re: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit- > > premature- > > > > disconnect-rqmts-02.txt > > > > > > > > > > But the system we've put together here allows for someone in > > > > Toronto > > > > >> whose only working phone happens to tunnel back to Germany to > > > > determine > > > > >> the correct PSAP for their location and make an > emergency call. > > > > >> How does that phone (or that network) treat the requirements > > > > >> for CPH? > > > > >There is no fundamental change in the social context. > > > > >You still have > > > > >stressed people making poor judgments on when to end a > call, and > > > > >a > > > > trained > > > > >PSAP call taker better able to determine when to end the call. > > The > > > > networks > > > > >are, certainly, more complex. The requirements, and > the proposed > > > > mechanisms > > > > >have always dealt with the circumstance you are describing > > > adequately: > > > > the > > > > >feature is enabled call by call at the PSAP and works > > > across complex > > > > >networks such as the ones you describe. > > > > > > > > I believe that the mechanisms you've described so far would > > > only work > > > > across complex networks provided every network in the world > > > was aware > > > > of and obedient to this signalling. The "don't tear down flows" > > > > requirement > > > > is pretty much not how things work in many networks > now, and this > > > > would require all networks now to watch for signalling and > > > keep state > > > > in a way they do not. > > > > > > > > Could we get there? With enough will, certainly. But > > > "works across > > > > complex networks" does not seem to describe the current > > > state of play. > > > > It is possible that I am misunderstanding the > mechanisms proposed. > > > > That wouldn't be unlikely and would probably be at > least partly my > > > > fault, since I've been among those asking for the > > > requirements to be > > > > worked out prior to the mechanisms being developed. > Sorry, if so. > > > > > > > > > > > > > > > > > > > > > > Perhaps by making a requirement that there is a need > > > for agreement > > > > >> here between the human user and the PSAP on who should have > > > > >> this control? Since this isn't the same in all > jurisdictions, > > > > >> you > > can > > > > have > > > > >> a mismatch both ways. > > > > > > > > > > > > > > > > >But there isn't a negotiation between the caller and the > > > PSAP. The > > > > >requirement we have is that the PSAP asserts control, and the > > > > >user can override. That is described. To implement that, I > > > > >think signaling > > > > needs > > > > >negotiation (both so the caller side knows what to do, and the > > PSAP > > > > knows > > > > >whether it's going to be able to assert control). > > > > > > > > And here is the crux of the matter. The PSAPs want to > > > assert control. > > > > That will violate the principle of least surprise for at least > > > > some users who come from different jurisdictions or > whose phones > > > > using other technologies do not behave this way, and it will not > > > be desired > > > > by others even if they aren't surprised by it . > > > > > > > > > > >You are stuck on the possibility the user actually does know > > better > > > > than the > > > > >PSAP what is happening. > > > > > > > > I see a tension here you do not. The user should always be > > > in control > > > > of the device, unless they surrender that control voluntarily. > > > > The extreme example of this is the one Marc mentioned: no one > > > else should > > > > be able to brick your phone in an emergency. The other > > > examples given > > > > have been knocked back as unlikely (the abuser/home > > > intruder example, > > > > where the hang up *must* happen, the anonymous tip > example, etc.). > > > > Maybe those are unlikely in the world these PSAPs > serve. But the > > > > possibility of abuse here is also pretty scary, even if > it abuse > > > > by authorities in jurisdictions different from the current > > > users of the > > > > related feature. > > > > > > > > We have to get this right if we do it, and that means we > > > have to treat > > > > the desires of both parties. From my way of thinking that > > > implies a > > > > much more negotiated approach than the "PSAP desires > control this" > > > > tone of the proposals to date. Absent a willingness to do > > > that, I will > > > > move on to the position "this is a bad idea, let's not do it". > > > > You may well get rough consensus over my objections, > but I would > > > > rather than you heard them and took them seriously. > > > > > > > > If I have not said so lately, let me repeat: thanks for > > > your work on > > > > this. Please understand my comments are not meant to > > > frustrate you or > > > > the work; they are meant to help get it right. > > > > > > > > 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 Thu Jan 15 00:07:24 2009 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 289363A69A2; Thu, 15 Jan 2009 00:07:24 -0800 (PST) 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 DEC3D3A6924 for ; Thu, 15 Jan 2009 00:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, J_CHICKENPOX_33=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 uPdIFBNE07rm for ; Thu, 15 Jan 2009 00:07:21 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E066B3A6877 for ; Thu, 15 Jan 2009 00:07:20 -0800 (PST) Received: (qmail invoked by alias); 15 Jan 2009 08:07:04 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp042) with SMTP; 15 Jan 2009 09:07:04 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1++9SBup0S+kaO8FfGYzu1v1hVN6sTj2ONaASaw0b wmp+3r7XbGSR3C From: "Hannes Tschofenig" To: "ECRIT" , , Date: Thu, 15 Jan 2009 10:08:14 +0200 Message-ID: <000801c976e8$6c73abe0$80b5b70a@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acl2fTF8EcY7EhAkQnGtbOyw5hhCAAAAOUmgABpKSiA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Subject: [Ecrit] FW: Copyright issues affecting current Internet-Drafts 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, there are some issues with the new IPR policies outlined in RFC 5378 that I would like to bring to your attention. Please read through the writeups that other folks have provided and make your own judgement. Ciao Hannes >-----Original Message----- >From: owner-radiusext@ops.ietf.org >[mailto:owner-radiusext@ops.ietf.org] On Behalf Of Dave Nelson >Sent: 14 January, 2009 21:53 >To: radiusext@ops.ietf.org >Subject: Copyright issues affecting current Internet-Drafts > >The IETF Chair has requested that all Working Groups be >notified of an intellectual property rights / copyright >"brou-ha-ha" that is being currently discussed on the IETF >General Discussion List. > >As I understand it, there is a minor defect in RFC 5378, the >document that currently governs rights in IETF submissions and >publications. >Specifically, this has to do with rights for derivative works >outside of the IETF standards process. > >There is also ongoing discussion of a workaround for this >problem. If you are interested, please consult the IETF >General Discussion mailing list archives. Any discussion of >the issue should occur on that list. > >One potential impact to the Working Groups is that revised >boilerplate text is likely to be required for submission of >I-Ds. That revised text is expected to be in place well >before the I-D submission cut-off date prior to IETF-74. >There may be some confusion during the transition, however. > >A second potential impact is that any material that has been >derived from a document published prior to the effective date >RFC 5378 (November 11, 2008) may require special restrictions >to be listed in the boilerplate, as to rights for derivative >works outside the IETF standards process. > >The "fair use doctrine" would seem to apply to small sections >of properly quoted and cited text from older documents. The >issue arises with any modifications to such text. We have >seen such re-use of modified text proposed in recent WG list >discussions on open RADEXT Issues. > >All I-D authors need to be generally aware of this issue, and >anyone wishing to include substantial sections of text or any >sections of modified text from a "pre-5378" document need to >be particular aware. It does not appear that this issue will >impact our work, if we pay attention to the details. > >Following is the details of the issue, as summarized in an >announcement from the Trustees of the IETF Trust (the agency >that holds IETF IPR). > >--------------------------------------------------------------- >----------- > >The purpose of this message is twofold: > >1) To summarize the issues that some members of our community > have experienced since the publication of RFC 5378 in >November 2008, > and >2) To invite community review and discussion on a potential >work-around > being considered by the IETF Trustees. > >Some I-D authors are having difficulty implementing RFC 5378. >An example of the difficulty is as follows: > > - an author wants to include pre-5378 content in a new submission > or contribution to the IETF, but > - s/he is not certain that all of the author(s) of the earlier > material have agreed to license it to the IETF Trust according > to RFC 5378. > >If an I-D author includes pre-5378 material in a new document, >then s/he must represent or warrant that all of the authors >who created the >pre-5378 material have granted rights for that material to the >IETF Trust. >If s/he cannot make this assertion, then s/he has a problem. > >This situation has halted the progression of some >Internet-Drafts and interrupted the publication of some RFCs. >The Trustees of the IETF Trust are investigating ways to >implement a temporary work-around so that IETF work can >continue to progress. A permanent solution to this "pre-5378 >problem" may require an update to RFC 5378, for example new >work by the community to create a 5378-bis document. > >The remainder of this message provides an outline of the >temporary work- around being considered by the Trustees. > >RFC 5378 sections 1.j and 5.3.c provide the IETF Trust with >the authority to develop legend text for authors to use in >situations where they wish to limit the granting of rights to >modify and prepare derivatives of the documents they submit. >The Trustees used this authority in 2008 to develop and adopt >the current "Legal Provisions Relating to IETF Documents" >which are posted at: >http://trustee.ietf.org/license-info/. > >The Trustees are now considering the creation of optional new >legend text which could be used by authors experiencing the >"pre-5378 problem". > >The new legend text, if implemented, would do the following: > > a. Provide Authors and Contributors with a way to identify (to the > IETF Trust) that their contributions contain material >from pre-5378 > documents for which RFC 5378 rights to modify the material outside > the IETF standards process may not have been granted, and > > b. Provide the IETF Trust and the community with a clear indication > of every document containing pre-5378 content and having the > "pre-5378 problem". > >So, how could the creation and use of some new legend text >help people work-around the pre-5378 problem? > >The proposed answer is as follows: > > 1. Anyone having a contribution with the "pre-5378" problem >should add > new legend text to the contribution, to clearly flag that >it includes > pre-5378 material for which all of the rights needed >under RFC 5378 > may not have been granted, and > > 2. The IETF Trust will consider authors and contributors (with the > pre-5378 problem) to have met their RFC 5378 obligations if the > new legend text appears on their documents, and > > 3. Authors and contributors should only resort to adding the new > legend text to their documents (per #1) if they cannot develop > certainty that all of the author(s) of pre-5378 material in > their documents have agreed to license the pre-5378 content to > the IETF Trust according to RFC 5378. > >The proposed wording for the new legend text is now available >for your review and comments in section 6.c.iii of a draft >revision to the IETF Trust's "Legal Provisions Relating to >IETF Documents" located at >http://trustee.ietf.org/policyandprocedures.html. > >Please note that the above document also contains new text in >section 5.c dealing with "License Limitations". > >If your review and feedback on this proposed work-around is >positive, then the new text may be adopted by the Trustees in >early February 2009, and then be published as an official >revision to the Legal Provisions document. If so adopted, >Internet-Drafts with pre-5378 material may advance within the >Internet standards process and get published as RFCs where >otherwise qualified to do so. Unless covered by sections >6.c.i or 6.c.ii, authors of documents in which there is no >pre-5378 material must provide a RFC 5378 license with no >limitation on modifications outside the IETF standards process. > >The IETF Trust will not grant the right to modify or prepare >derivative works of any specific RFC or other IETF >Contribution outside the IETF standards process until RFC 5378 >rights pertaining to that document have been obtained from all >authors and after compliance by the IETF Trust with RFC 5377. >The Trustees will establish one or more mechanisms by which >authors of pre-5378 documents may grant RFC 5378 rights. > >The Trustees hereby invite your review, comments and >suggestions on this proposed work-around to the "pre-5378 >problem". The period for this review is 30 days. Microsoft >WORD and PDF versions of the proposed revisions are attached >to this message. Copies are also available on the IETF Trust >website under the heading "DRAFT Policy and Procedures Being >Developed" at: >http://trustee.ietf.org/policyandprocedures.html > >All feedback submitted before the end of February 7th will be >considered by the Trustees. A decision on whether to move >forward with this proposal will be made and communicated to >you before the end of February 15th. > >Please give this your attention. > >Regards and Happy New Year ! > >Ed Juskevicius, on behalf of the IETF Trustees edj.etc at gmail.com > > > >-- >to unsubscribe send a message to >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >a single line as the message text body. >archive: > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 15 00:14:04 2009 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 C7FE23A6ACE; Thu, 15 Jan 2009 00:14:04 -0800 (PST) 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 4C12B3A6ACD for ; Thu, 15 Jan 2009 00:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 ailAd5q6cjir for ; Thu, 15 Jan 2009 00:14:04 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B1BAC3A6ACE for ; Thu, 15 Jan 2009 00:14:03 -0800 (PST) Received: (qmail invoked by alias); 15 Jan 2009 08:07:07 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp042) with SMTP; 15 Jan 2009 09:07:07 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX183k1BDxno3E1GtDYPRHp6uandto2LK9PHQy+NcRr lIDGjEWPX/zzIb From: "Hannes Tschofenig" To: "ECRIT" , , Date: Thu, 15 Jan 2009 10:08:20 +0200 Message-ID: <000901c976e8$6edd31d0$80b5b70a@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acl2a3AtDPd3bpScQnKA0qVKoQtAZgAATX+wAAB89nAAAB01gAABhNswAAKPi7AAGgROIA== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Subject: [Ecrit] FW: RFC 5378 Implications 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 FYI Two shorter writeups from Bernard Aboba and Paul Hoffman. >-----Original Message----- >From: owner-radiusext@ops.ietf.org >[mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba >Sent: 14 January, 2009 21:50 >To: radiusext@ops.ietf.org >Subject: RFC 5378 Implications > >As some of you may know, as a result of the publication of RFC >5378, the IETF >has changed the boilerplate required for Internet-Draft submissions. > >It is important that all contributors know the terms under >which contributions are made, and to understand the >requirements imposed by RFC 5378, as well as the problems that >some people have had with it. > >Currently, a discussion is underway on the IETF Discuss >mailing list relating to the implications of RFC 5378, as well >as potential fixes to it. > >If you are a contributor or potential contributor within the >RADEXT WG, and are interested in understanding your >obligations and responsibilities under the new policies, >please consult the IETF Discussion archive: >http://www.ietf.org/mail-archive/web/ietf/current/maillist.html > >Discussion of this topic on individual Working Group mailing >lists is discouraged. > >Some recent postings on the IETF Discussion list: >IETF Trustee Request for Review: >http://www.ietf.org/mail-archive/web/ietf/current/msg54839.html >IAD statement: >http://www.ietf.org/mail-archive/web/ietf/current/msg54691.html >IETF Chair statement: >http://www.ietf.org/mail-archive/web/ietf/current/msg54502.html > > >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] >On Behalf Of Paul Hoffman >Sent: 14 January, 2009 23:25 >To: IPsecme WG >Subject: [IPsec] RFC 5378 and this WG > >Greetings again. If you are an author or contributor on in >this WG, please read >l>. It is important. > >The WG Chairs have been asked to make their WGs aware of this >issue. This is a complicated subject, but the executive >summary is that if you have an Internet-Draft that quotes >substantially from one or more older RFCs (ones with a >publication date pre-November 11, 2008), and you did not write >this earlier work yourself (or you wrote it while with another >company), you need to be aware of the likely difficulty of >obtaining RFC 5378 clearances for your new work, and also to >be aware that a work-around is on the way. The work-around >should be in place to allow submissions to the San Francisco >IETF well before the normal deadlines. See the attached text >for more details. > >There is an open question about whether or not an Internet >Draft that quotes from the WG discussion also needs clearance >from the person who proposed text in the discussion. For >example, IKEv2bis has a lot of material that has been proposed >on this mailing list. > >If you feel that you have a draft for which this will be a >problem, please contact me. > >With a chair hat on, I am not going to allow a general >discussion about RFC 5378 on this list (as it is very >off-topic). Please take such comments to the main IETF >discussion list. Questions about specific WG drafts are of >course on topic. > >--Paul Hoffman, Director >--VPN Consortium >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 15 12:48:48 2009 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 D50743A6848; Thu, 15 Jan 2009 12:48:48 -0800 (PST) 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 4D19C3A6848 for ; Thu, 15 Jan 2009 12:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.007, 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 Mko9HiTP31BM for ; Thu, 15 Jan 2009 12:48:47 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 468BC3A6842 for ; Thu, 15 Jan 2009 12:48:47 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LNZ8V-0006l6-L7; Thu, 15 Jan 2009 14:48:20 -0600 From: "Brian Rosen" To: "'Ted Hardie'" , "'ECRIT'" References: <022701c970da$b36ebc10$1a4c3430$@net> <030b01c975ac$f9d0b880$ed722980$@net> In-Reply-To: Date: Thu, 15 Jan 2009 15:48:28 -0500 Message-ID: <084101c97752$a02b5db0$e0821910$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acl2bOXBUTE2UP8RQ3SdjFV0EUb2HAAFPVRQ 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] FW: FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.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 10:30 AM -0800 1/13/09, Brian Rosen wrote: > >I'm trying to solve a problem where the user is doing the wrong thing. > By > >definition, his opinion is that he should terminate the call. > > And you are substituting the PSAP call taker's judgement for > the individual user's because it is statistically better. But, > as the "intruder" case discussed below makes clear, there are > times when you already acknowledge that the user's judgement > is better. Agree, but we're in "greater good" territory > >I do understand the "intruder" problem. > > I'm glad that we have at least this common ground. > > > >I'd like to be able to solve that > >in the best possible way. If the user really knew what was happening, > they > >would pull the battery out of the device, because any phone can be > called > >any time. > > Note that in the "abuser" version of this, it really makes a difference > as > to who calls (and the abused may be hurt for failing to respond to the > abuser's call as well as abused for reaching out for help). Yeah > > >That's not a reasonable response, and I understand that. We have > >a balance to strike. Of course the override could and probably should > be > >proactive (that is, if you should be able to invoke the override > before you > >terminate). > > Do you see it as reasonable to invoke the over-ride before the > call starts? That is, start the call in a state so that the PSAP knows > it would not get the right to control the ending? Yes, I do think it's reasonable. We would have to discuss the advice to implementers on how trivial it is to engage. It shouldn't be trivial, but it shouldn't be very hard. > > I would be more comfortable with this capability, as it also addresses > the other concern--use/abuse of this facility by non-PSAP uses. If > users > can start a call in way that prevents this facility being used, users > can > choose to operate in this manner in contexts where they fear abuse > of the facility. > > > That is also not a complete answer. It seems to me that the > >incidence of bad judgment causing serious problems is so much more > common > >than the intruder's shouldn't hear alerting that we ought to > compromise in a > >way that facilitates the former rather than the latter. Although I'm > not > >entirely comfortable taking that position, I'm a heck of a lot more > >comfortable with that then any other proposed solution. > > I would guess that you're not comfortable with it for the same reason > I am not. It's hard to face someone whose situation got worse with > the reasoning "well, statistically things got better". Well, no. I'm uncomfortable because the cost of being wrong could be high. The reason I continue to be interested in having it is that the cost of not having it is yet higher in the aggregate. We can rely on the older U.S. and Canadian experience. Despite the fact that it's not universal, it was/is implemented. The problem situation you are positing is just as possible on a Canadian wireline phone as it is on a wireless phone. There are many, many years of experience on how often it's helpful, and what kind of problems it causes. Newer technology doesn't fundamentally change anything about the scenarios we're describing. > > >I'm not at all worried about the "least surprise" issue with people > coming > >in from other jurisdictions. Surprise is the most common reaction to > people > >in the jurisdictions it's been implemented in, mostly because you > don't make > >emergency calls very often. Most Canadians don't know that the PSAP > can > >control termination on wireline calls. > > This sounds like a great way to further fluster folks who are already > apparently too nervous to do the right thing. Again, we have experience to guide us here. Yes, you get surprise, but you also get results. We don't have to guess how big a problem the surprise causes. > > >The current proposed mechanism is that you negotiate the feature with > a full > >3 way handshake. > > So UA can simply fail to support the feature during this handshake as > a form of negotiation? Yes. No protocol police. > > > Then, normally, instead of termination, you signal > >hookstate. If you get stuck (the signaling of hookstate doesn't > complete, > >or the override is triggered), you terminate. The PSAP has a way to > alert. > >All that is required to make this work in complex networks is that the > >negotiation mechanism and the hookstate signaling mechanism is > transparent > >to networks and devices other than the UAS and the UAC. If either end > >really does send BYE, the call terminates. > > I guess I don't understand how the UA sends BYE here (and thus how this > remains "either end really does send BYE). It sends BYE if: a) The override is triggered b) Signaling fails (e.g. the hookstate switch change signaling fails to complete) c) Anything else bad happens and we're in danger of bricking the phone So if the intermediate networks screw up, and the hookstate change signaling gets screwed up, the UA sends BYE and the call is terminated. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jan 15 13:07:25 2009 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 070C93A67F3; Thu, 15 Jan 2009 13:07:25 -0800 (PST) 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 0BFD63A67F3 for ; Thu, 15 Jan 2009 13:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 De9n-kfUaqL7 for ; Thu, 15 Jan 2009 13:07:23 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id B5EBF3A67AB for ; Thu, 15 Jan 2009 13:07:22 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0FL6klT005605; Thu, 15 Jan 2009 23:06:47 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 23:06:46 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 23:06:45 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 15 Jan 2009 22:06:45 +0100 From: To: , Date: Thu, 15 Jan 2009 22:06:43 +0100 Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AclyqTzN/rXI2sBuSOePxPlT8PQRBwEq4dCA Message-ID: References: <4967CEDC.6000307@bbn.com> In-Reply-To: <4967CEDC.6000307@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 15 Jan 2009 21:06:45.0694 (UTC) FILETIME=[2C5C45E0:01C97755] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: Re: [Ecrit] PhoneBCP 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 should omit the letter 'v' when mentioning about 802.11, because 802.11v is not the only amendment dealing with location and, ultimately all amendments end up being incorporated into the base standard anyway. - gabor >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >ext Richard Barnes >Sent: Friday, January 09, 2009 2:26 PM >To: Marc Linsner >Cc: 'ECRIT' >Subject: Re: [Ecrit] PhoneBCP > >Marc, > >Thanks for refreshing this discussion. I would revise your text as >follows to ensure that one of the IETF protocols is always usable: > >-----BEGIN----- > ED-21/INT-12 > >Devices MUST support both the DHCP location options [RFC4776] >[RFC3825], and HELD [I-D.ietf-geopriv-http-location-delivery]. > >When devices deploys a specific access network interface in which that >access network supports location discovery such as LLDP-MED or 802.11v. > In this case, the device SHOULD support the additional respective >access network specific location discovery mechanism. > > AN-12/INT-13 > >The access network MUST support either DHCP location options or HELD. >The access network SHOULD support other location technologies that are >specific to the type of access network. >-----END----- > >Cheers, >--Richard > > > >Marc Linsner wrote: >> As we tried to complete PhoneBCP, our conversation in Minneapolis >> uncovered another sticking point we need to resolve. >> >>>From section 6.5. >> >> ED-21/INT-12 Devices MUST support all of: DHCP location options >> [_RFC4776_] and [_RFC3825_], HELD >> [_I-D.ietf-geopriv-http-location-delivery_] and LLDP-MED [_LLDP- >MED_]. >> >> AN-12/INT-13 The access network MUST support at least one of: DHCP >> location options, HELD or LLDP-MED. >> >> >> It was suggested that IEEE802.11v is an additional mechanism that a >> 802.11 host *could* utilize to discover it's location. It was >suggested >> this mechanism should be added to the list of MUST support. Then >ensued >> a discussion of how LLDP-MED ever made it to list and why we have/need >> layer 2 specific mechanisms in the list. >> >> I would offer the following text to try and make progress such that we >> can move this document forward: >> >> ED-21/INT-12 >> >> Devices MUST support all of: DHCP location options [_RFC4776_] and >> [_RFC3825_], HELD [_I-D.ietf-geopriv-http-location-delivery_]. >> >> The exception to this would be a device that deploys a specific access >> network interface in which that access network supports location >> discovery such as LLDP-MED or 802.11v. In this case, the device MUST >> support the additional respective access network specific location >> discovery mechanism. >> >> AN-12/INT-13 >> >> The access network MUST support at least one of: DHCP location options, >> HELD, LLDP-MED, or 802.11v. >> >> >> >> >> Fire away, >> >> -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 Fri Jan 16 02:25:52 2009 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 B254828C1D4; Fri, 16 Jan 2009 02:25:52 -0800 (PST) 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 8CF3028C1C6 for ; Fri, 16 Jan 2009 02:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=-0.970, 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 8aAU0Xv882eI for ; Fri, 16 Jan 2009 02:25:50 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 09D3C28C1D4 for ; Fri, 16 Jan 2009 02:25:49 -0800 (PST) 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 n0G9WpEf007585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Jan 2009 10:32:51 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0G9Wo8p026337; Fri, 16 Jan 2009 10:32:50 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 10:32:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Jan 2009 11:29:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF#74 -- Agenda Thread-Index: Acl3vOeFuUWqQq/sTPqzyOMvVgjULA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 16 Jan 2009 09:32:50.0364 (UTC) FILETIME=[662ED7C0:01C977BD] Cc: marc.linsner@cisco.com Subject: [Ecrit] IETF#74 -- Agenda 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 requested a 2 1/2 hour slot for the next IETF meeting. Please let us know if you would like to discuss your favorite topic. Here is a copy-and-paste from the charter: * Location-to-URL Mapping Architecture and Framework I don't think we need to discuss this document again. If I recall it correctly then we had all open issues solved with it. * Best Current Practice for Communications Services in support of Emergency Calling I really, really hope that we are done with this document at IETF#74. * Location Hiding: Problem Statement and Requirements This document is done. We might hear back from the IESG. * Specifying Holes in LoST Service Boundaries Done. We might hear back from the IESG. * Synchronizing Location-to-Service Translation (LoST) Servers This should be done at the IETF#74 timeframe as well. * IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications We are going to chat about this document. Then, we have some other documents on our plate: http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnect-rqmts-02 .txt http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-02.txt RFC5031bis http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc-01.txt http://tools.ietf.org/id/draft-forte-ecrit-lost-extensions-01.txt http://tools.ietf.org/id/draft-forte-ecrit-service-classification-01.txt http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access- 04.txt http://tools.ietf.org/id/draft-sun-ecrit-shelter-service-01.txt Ciao Hannes, Marc and Roger _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jan 19 13:10:51 2009 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 998943A690D; Mon, 19 Jan 2009 13:10:51 -0800 (PST) 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 949083A68DE for ; Mon, 19 Jan 2009 13:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.003, 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 BZ6Bk3NyAFUY for ; Mon, 19 Jan 2009 13:10:48 -0800 (PST) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 06F193A6808 for ; Mon, 19 Jan 2009 13:10:47 -0800 (PST) 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, 19 Jan 2009 13:10:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jan 2009 13:08:25 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750BB7B568@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ecrit] review of: draft-ietf-ecrit-lost-sync-01 Thread-Index: Acl6ehFhaqBHlh01TYmHAA8v/thzrw== From: "Roger Marshall" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , , Subject: [Ecrit] [ecrit] review of: draft-ietf-ecrit-lost-sync-01 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="===============1208552268==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1208552268== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97A7A.597C2502" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97A7A.597C2502 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of: draft-ietf-ecrit-lost-sync-01 I've provided a review of the lost-sync draft, with the following comments - mostly minor wording and grammatical. Assuming that the authors are Ok with the changes, I would encourage the chairs to put the (next) revised version draft into WGLC straight away. List of (12) Comments: C1. Abstract, rewording of how LoST works: Change from: " The LoST (Location-to-Service Translation) protocol is used to map locations to service URLs." Change to:=20 " The LoST (Location-to-Service Translation) protocol is used to map locations and service URNs to service URIs." C2. Introduction, rewording (same as above): Change from: " The LoST (Location-to-Service Translation) protocol [RFC5222] maps geographic locations to service URLs. " Change to:=20 " The LoST (Location-to-Service Translation) protocol [RFC5222] maps geographic locations and service URNs to service URIs. " C3. Introduction, pp1., minor rewording of sentence: Change from: "...there are a variety of LoST servers that cooperate to provide a global, scalable and resilient mapping service. " Change to: "...there are a variety of LoST servers that cooperate to provide a ubiquietous, globally scalable and resilient mapping service. " C4 Section 2, Terminology, minor change to fix missing space: Change from: " ,"RECOMMENDED" Change to: " , "RECOMMENDED" -----^----- C5. Section 3, Distributing Mappings..., change wording for consistency: Change from: "If the querier attempts to remove a non-existent mapping, the query is silently ignored." Change to: ""If the querier attempts to delete a non-existent mapping, the query is silently ignored." C6. Section 3, pp4, minor wording changes throughout paragraph for readability: Change from: " The response to a request is a , currently without additional elements, if the request was successful or an response if the request failed. Only the , , or errors defined in Section 13.1 of [RFC5222] are used. Neither the nor the messages are used for this query." Change to: " The response to a request is a response message. =20 Currently, a successful response message returns no additional elements, whereas an response is=20 returned in the response message, if the request failed. Only the errors, , , or , defined in Section 13.1 of [RFC5222], are used. The and messages are not used for this query/response." C7. Section 3, pp5, minor word correction:: Change from: " ...giving the relatively low volume of data.)" Change to: " ...given the relatively low volume of data.)" C8. Section 3, pp7, wording changes to clarify text: Change from: " An example is shown in Figure 1. In the example, the mappings with sourceId 7e3f40b098c711dbb6060800200c9a66 sourceId=20 7e3f40b098c711dbb606011111111111 are added by the recipient. The last mapping, with source 'nj.us.example' and sourceID 'englewood', is removed." Change to: " An example is shown in Figure 1. In the example, both the mappings with source 'nj.us.example' and sourceId's 7e3f40b098c711dbb6060800200c9a66, and=20 7e3f40b098c711dbb606011111111111, respectively, are added by the recipient. The last mapping, with source 'nj.us.example' and sourceID 'englewood', is deleted." C9. Section 6.1., LoST Synchronization Namespace Registration The example of xml seems to lack some explanatory text to go with it, e.g.,=20 what is this registory for?, etc. C10. Figure 2., minor xml error, which causes validation error (extraneous close mark) Change from: "=20 Change to:=20 "=20 C11. Figure 4., minor xml error, which causes validation error: Comment: "", which should be added. C12. Running the draft through the idnits 2.11.00 yielded the following comment, for which I couldn't resolve (nothing apparent to me that wasn't covered in RFC3979). Here's the output: tmp/draft-ietf-ecrit-lost-sync-01.txt: Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748: =20 ------------------------------------------------------------------------ ---- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see http://trustee.ietf.org/license-info), which is required from December 16, 2008. Version 1.34 of xml2rfc can be used to produce documents with boilerplate according to the mentioned Trust License Policy document. /end of comments -roger marshall. CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. ------_=_NextPart_001_01C97A7A.597C2502 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [ecrit] review of: draft-ietf-ecrit-lost-sync-01

Review of: draft-ietf-ecrit-lost-sync-01

I've provided a review of the lost-sync dr= aft, with the following comments - mostly minor wording and grammatical.&nb= sp; Assuming that the authors are Ok with the changes, I would encourage th= e chairs to put the (next) revised version draft into WGLC straight away.

List of (12) Comments:

C1. Abstract, rewording of how LoST works:=
Change from:
"   The LoST (Location-to-= Service Translation) protocol is used to map
   locations to service URLs.&q= uot;
Change to:
"   The LoST (Location-to-= Service Translation) protocol is used to map
   locations and service URNs t= o service URIs."

C2. Introduction, rewording (same as above= ):
Change from:
"   The LoST (Location-to-= Service Translation) protocol [RFC5222] maps
   geographic locations to serv= ice URLs.  "
Change to:
"   The LoST (Location-to-= Service Translation) protocol [RFC5222] maps
   geographic locations and ser= vice URNs to service URIs.  "

C3. Introduction, pp1., minor rewording of= sentence:
Change from:
"...there are a
   variety of LoST servers that= cooperate to provide a global, scalable
   and resilient mapping servic= e. "
Change to:
"...there are a
   variety of LoST servers that= cooperate to provide a ubiquietous, globally scalable
   and resilient mapping servic= e. "

C4 Section 2, Terminology, minor change to= fix missing space:
Change from:
"   ,"RECOMMENDED&quo= t;
Change to:
"   , "RECOMMENDED&qu= ot;
-----^-----

C5. Section 3, Distributing Mappings..., c= hange wording for consistency:
Change from:
"If the querier
   attempts to remove a non-exi= stent mapping, the query is silently
   ignored."
Change to:
""If the querier
   attempts to delete a non-exi= stent mapping, the query is silently
   ignored."

C6. Section 3, pp4, minor wording changes = throughout paragraph for readability:
Change from:
"   The response to a <= pushMappings> request is a <pushMappingsResponse>,
   currently without additional= elements, if the request was successful
   or an <errors> respons= e if the request failed.  Only the
   <badRequest>, <forb= idden>, <internalError> or <serverTimeout> errors
   defined in Section 13.1 of [= RFC5222] are used.  Neither the
   <redirect> nor the <= ;warnings> messages are used for this query."
Change to:
"   The response to a <= pushMappings> request is a <pushMappingsResponse> response message= . 
   Currently, a successful resp= onse message returns no additional elements, whereas an <errors> resp= onse is
   returned in the response mes= sage, if the request failed.  Only the errors, <badRequest>, <= ;forbidden>, <internalError> or <serverTimeout>,

   defined in Section 13.1 of [R= FC5222], are used.  The <redirect> and <warnings> messages= are not used for this query/response."

C7. Section 3, pp5, minor word correction:= :
Change from:
"  ...giving the relatively low= volume of data.)"
Change to:
"  ...given the relatively low = volume of data.)"

C8. Section 3, pp7, wording changes to cla= rify text:
Change from:
"   An example is shown in= Figure 1.  In the example, the mappings with
   sourceId 7e3f40b098c711dbb60= 60800200c9a66 sourceId
   7e3f40b098c711dbb60601111111= 1111 are added by the recipient.  The
   last mapping, with source 'n= j.us.example' and sourceID 'englewood',
   is removed."
Change to:
"   An example is shown in= Figure 1.  In the example, both the mappings with
   source 'nj.us.example' and s= ourceId's 7e3f40b098c711dbb6060800200c9a66, and
   7e3f40b098c711dbb60601111111= 1111, respectively, are added by the recipient.  The
   last mapping, with source 'n= j.us.example' and sourceID 'englewood',
   is deleted."

C9. Section 6.1.,  LoST Synchronizati= on Namespace Registration
The example of xml seems to lack some exp= lanatory text to go with it, e.g.,
what is this registory for?, etc.

C10. Figure 2., minor xml error, which cau= ses validation error (extraneous close mark)
Change from:
 "<pushMappingsResponse xmln= s=3D"urn:ietf:params:xml:ns:lost1:sync" />
Change to:
 "<pushMappingsResponse xmln= s=3D"urn:ietf:params:xml:ns:lost1:sync">

C11. Figure 4., minor xml error, which cau= ses validation error:
Comment:
"<mapping " element does not= get a closed,  ">", which should be added.

C12. Running the draft through the idnits = 2.11.00 yielded the following comment, for which I couldn't resolve (nothin= g apparent to me that wasn't covered in RFC3979).  Here's the output:<= /FONT>

tmp/draft-ietf-ecrit-lost-sync-01.txt:

  Checking boilerplate required by RF= C 3978 and 3979, updated by RFC 4748:
  ----------------------------------= ------------------------------------------

  ** It looks like you're using RFC 3= 978 boilerplate.  You should update this
     to the boilerpla= te described in the IETF Trust License Policy document
     (see http://trustee.ietf.org/license-info), which is required from
     December 16, 200= 8.  Version 1.34 of xml2rfc can be used to produce
     documents with b= oilerplate according to the mentioned Trust License
     Policy document.=

/end of comments

-roger marshall.

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

------_=_NextPart_001_01C97A7A.597C2502-- --===============1208552268== 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 --===============1208552268==-- From ecrit-bounces@ietf.org Sat Jan 24 00:49:14 2009 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 84D8B3A6ACF; Sat, 24 Jan 2009 00:49:14 -0800 (PST) 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 DD36B3A6A96 for ; Sat, 24 Jan 2009 00:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.016 X-Spam-Level: X-Spam-Status: No, score=-1.016 tagged_above=-999 required=5 tests=[AWL=-1.017, BAYES_50=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 62bWrvdW3-EH for ; Sat, 24 Jan 2009 00:49:12 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id ABB533A6867 for ; Sat, 24 Jan 2009 00:49:11 -0800 (PST) Received: (qmail invoked by alias); 24 Jan 2009 08:48:51 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp055) with SMTP; 24 Jan 2009 09:48:51 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+i4/Y2ruCix65y+Vc52JHMhz2g5I57FKqRqkWOoK TPb1Idndd6p+zE From: "Hannes Tschofenig" To: "ECRIT" Date: Sat, 24 Jan 2009 10:49:29 +0200 Message-ID: <003301c97e00$ac955f60$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acl+AGcDaTZN0lrqSDa8KqbwOQ/NCA== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Subject: [Ecrit] ECRIT Virtual Interim Meeting 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, to make some progress in ECRIT we would like to make a proposal for a virtual interim meeting. The concept of virtual interim meetings is floating around in the IETF recently and we thought it is a pretty good idea. Virtual interim meeting means that we are going to have a phone conference call for about ~2 hours to chat about working group items. So, unless there are strong objections we suggest that ECRIT holds such a meeting on the 18th February 2009, 10am EST for 2 hours. Proposed agenda: Discuss status and open issues of ECRIT working group items We will send an update within the next week on the technicalities of the call. Document authors, please resubmit your drafts by the 11th February. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 24 09:00:03 2009 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 151E228C2BD; Sat, 24 Jan 2009 09:00:03 -0800 (PST) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 94E2728C1EA; Sat, 24 Jan 2009 09:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090124170001.94E2728C1EA@core3.amsl.com> Date: Sat, 24 Jan 2009 09:00:01 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-02.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 : Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements Author(s) : H. Schulzrinne, H. Tschofenig Filename : draft-ietf-ecrit-lost-sync-02.txt Pages : 19 Date : 2009-01-24 The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the XML element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service URI or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. As motived in the Location-to-URL Mapping Architecture document this mechanism is useful for the synchronization of top-level LoST Forest Guides. This document is, however, even useful in a deployment that does not make use of the LoST protocol but purely wants to distribute service boundaries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-02.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-lost-sync-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-24085920.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 Sat Jan 24 09:04:09 2009 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 6BACD28C2BD; Sat, 24 Jan 2009 09:04:09 -0800 (PST) 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 E353928C1E2 for ; Sat, 24 Jan 2009 09:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=-0.980, 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 vUFtJCDVWbGg for ; Sat, 24 Jan 2009 09:04:07 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id EE7E428C153 for ; Sat, 24 Jan 2009 09:04:06 -0800 (PST) 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 n0OH3mCi031971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 24 Jan 2009 18:03:48 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0OH3mN0010810 for ; Sat, 24 Jan 2009 18:03:48 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Jan 2009 18:03:47 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 24 Jan 2009 19:04:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45F7FD4D@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-ecrit-lost-sync-02.txt Thread-Index: Acl+RdG/mT5Q+0LWSg2mUoPyO1xWjA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 24 Jan 2009 17:03:47.0998 (UTC) FILETIME=[B91823E0:01C97E45] Subject: [Ecrit] WGLC for draft-ietf-ecrit-lost-sync-02.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, this is a last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-02.txt Please have your comments in no later than February 7th. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 24 09:08:42 2009 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 A67C43A684C; Sat, 24 Jan 2009 09:08:42 -0800 (PST) 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 B6BD528C153 for ; Sat, 24 Jan 2009 09:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=0.289, 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 lBMhluDwNOdE for ; Sat, 24 Jan 2009 09:08:41 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8B3EC3A6809 for ; Sat, 24 Jan 2009 09:08:40 -0800 (PST) Received: (qmail invoked by alias); 24 Jan 2009 17:08:20 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp055) with SMTP; 24 Jan 2009 18:08:20 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX187Wyw3syE7x6JhLXrMBXkE8RRokz9N30Tnn+gn4y UqKnA771Jdrrcd From: "Hannes Tschofenig" To: "'Roger Marshall'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , , References: <8C837214C95C864C9F34F3635C2A65750BB7B568@SEA-EXCHVS-2.telecomsys.com> Date: Sat, 24 Jan 2009 19:09:01 +0200 Message-ID: <010701c97e46$74f16f40$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8C837214C95C864C9F34F3635C2A65750BB7B568@SEA-EXCHVS-2.telecomsys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acl6ehFhaqBHlh01TYmHAA8v/thzrwDys+TQ X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68 Subject: Re: [Ecrit] [ecrit] review of: draft-ietf-ecrit-lost-sync-01 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 Roger, thanks for your review. I have addressed your comments and uploaded a new version of the document, see http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-02.txt One minor comment below: > C9. Section 6.1., LoST Synchronization Namespace Registration > The example of xml seems to lack some explanatory text to go with it, e.g., > what is this registory for?, etc. This is necessary for the Relax NG schema. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 24 10:53:42 2009 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 C54CC3A69A7; Sat, 24 Jan 2009 10:53:42 -0800 (PST) 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 961BE3A69A7 for ; Sat, 24 Jan 2009 10:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 IYWOY+X0EWwi for ; Sat, 24 Jan 2009 10:53:40 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 917083A6933 for ; Sat, 24 Jan 2009 10:53:40 -0800 (PST) Received: from [209.173.57.233] (helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LQnd3-0004He-Cz; Sat, 24 Jan 2009 12:53:13 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ECRIT'" References: <003301c97e00$ac955f60$0201a8c0@nsnintra.net> In-Reply-To: <003301c97e00$ac955f60$0201a8c0@nsnintra.net> Date: Sat, 24 Jan 2009 13:53:19 -0500 Message-ID: <01f001c97e55$08280450$18780cf0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acl+AGcDaTZN0lrqSDa8KqbwOQ/NCAAVHsGQ 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] ECRIT Virtual Interim Meeting 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 NENA TDC starts on Feb 18. I'll be in the air heading towards it at 10 eastern US. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Saturday, January 24, 2009 3:49 AM > To: ECRIT > Subject: [Ecrit] ECRIT Virtual Interim Meeting > > Hi all, > > to make some progress in ECRIT we would like to make a proposal for a > virtual interim meeting. The concept of virtual interim meetings is > floating > around in the IETF recently and we thought it is a pretty good idea. > Virtual > interim meeting means that we are going to have a phone conference call > for > about ~2 hours to chat about working group items. > > So, unless there are strong objections we suggest that ECRIT holds such > a > meeting on the 18th February 2009, 10am EST for 2 hours. > > Proposed agenda: Discuss status and open issues of ECRIT working group > items > > We will send an update within the next week on the technicalities of > the > call. > > Document authors, please resubmit your drafts by the 11th February. > > 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 Sun Jan 25 00:45:45 2009 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 DE8283A683D; Sun, 25 Jan 2009 00:45:45 -0800 (PST) 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 9A50028C100 for ; Sun, 25 Jan 2009 00:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 ByhpieIyp4QT for ; Sun, 25 Jan 2009 00:45:43 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DDA9E3A6405 for ; Sun, 25 Jan 2009 00:45:42 -0800 (PST) Received: (qmail invoked by alias); 25 Jan 2009 08:45:24 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp058) with SMTP; 25 Jan 2009 09:45:24 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18/OqtH0+k/plQ4ll9A7x4QR+93UL12bdvz3LIaTq 3u2Pa7sJaXmlfE From: "Hannes Tschofenig" To: "'Hannes Tschofenig'" , "'ECRIT'" References: <003301c97e00$ac955f60$0201a8c0@nsnintra.net> Date: Sun, 25 Jan 2009 10:46:05 +0200 Message-ID: <013501c97ec9$5cc04300$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <003301c97e00$ac955f60$0201a8c0@nsnintra.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acl+AGcDaTZN0lrqSDa8KqbwOQ/NCAAyLM5Q Importance: High X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Subject: [Ecrit] ECRIT Virtual Interim Meeting: 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 quickly spotted a conflict with the NENA TDC. Here is another try: http://www.doodle.com/4z4q2fr9mukxn876 Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Hannes Tschofenig >Sent: 24 January, 2009 10:49 >To: ECRIT >Subject: [Ecrit] ECRIT Virtual Interim Meeting > >Hi all, > >to make some progress in ECRIT we would like to make a >proposal for a virtual interim meeting. The concept of virtual >interim meetings is floating around in the IETF recently and >we thought it is a pretty good idea. Virtual interim meeting >means that we are going to have a phone conference call for >about ~2 hours to chat about working group items. > >So, unless there are strong objections we suggest that ECRIT >holds such a meeting on the 18th February 2009, 10am EST for 2 hours. > >Proposed agenda: Discuss status and open issues of ECRIT >working group items > >We will send an update within the next week on the >technicalities of the call. > >Document authors, please resubmit your drafts by the 11th February. > >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 Tue Jan 27 08:00:05 2009 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 01B6E28C101; Tue, 27 Jan 2009 08:00:05 -0800 (PST) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C34AD3A6A09; Tue, 27 Jan 2009 08:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090127160001.C34AD3A6A09@core3.amsl.com> Date: Tue, 27 Jan 2009 08:00:01 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.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 : Best Current Practice for Communications Services in support of Emergency Calling Author(s) : B. Rosen, J. Polk Filename : draft-ietf-ecrit-phonebcp-07.txt Pages : 45 Date : 2009-01-27 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.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-phonebcp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-27074925.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 Tue Jan 27 08:00:06 2009 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 BC11728C173; Tue, 27 Jan 2009 08:00:06 -0800 (PST) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C599E3A688D; Tue, 27 Jan 2009 08:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090127160001.C599E3A688D@core3.amsl.com> Date: Tue, 27 Jan 2009 08:00:01 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-framework-07.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 : Framework for Emergency Calling using Internet Multimedia Author(s) : B. Rosen, et al. Filename : draft-ietf-ecrit-framework-07.txt Pages : 37 Date : 2009-01-27 The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-07.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-framework-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-27074938.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 Tue Jan 27 08:21:08 2009 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 51A1E3A6AD3; Tue, 27 Jan 2009 08:21:08 -0800 (PST) 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 B0DD03A6AD3 for ; Tue, 27 Jan 2009 08:21:07 -0800 (PST) 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 mMFYIaoCWRv9 for ; Tue, 27 Jan 2009 08:21:06 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id E29E93A688D for ; Tue, 27 Jan 2009 08:21:06 -0800 (PST) Received: from [209.173.57.233] (helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LRqg2-0008Uc-Pf for ecrit@ietf.org; Tue, 27 Jan 2009 10:20:39 -0600 From: "Brian Rosen" To: References: <20090127160001.C34AD3A6A09@core3.amsl.com> In-Reply-To: <20090127160001.C34AD3A6A09@core3.amsl.com> Date: Tue, 27 Jan 2009 11:20:48 -0500 Message-ID: <006601c9809b$38c153d0$aa43fb70$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcmAmESJUWSB9Ri2TB6TcmukSiAeSQAAo62A 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] I-D Action:draft-ietf-ecrit-phonebcp-07.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 The only change was to the LCP protocol requirements. I used the language proposed by Marc Linsner, modified by Richard Barnes, and removed the "v" from 802.11v as suggested by Gabor. I request the chairs to run a very short WGLC and submit to the IESG. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Tuesday, January 27, 2009 11:00 AM > To: i-d-announce@ietf.org > Cc: ecrit@ietf.org > Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Emergency Context Resolution with > Internet Technologies Working Group of the IETF. > > > Title : Best Current Practice for Communications > Services in support of Emergency Calling > Author(s) : B. Rosen, J. Polk > Filename : draft-ietf-ecrit-phonebcp-07.txt > Pages : 45 > Date : 2009-01-27 > > The IETF and other standards organization have efforts targeted at > standardizing various aspects of placing emergency calls on IP > networks. This memo describes best current practice on how devices, > networks and services should use such standards to make emergency > calls. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.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 From ecrit-bounces@ietf.org Tue Jan 27 08:22:31 2009 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 7CA8628C122; Tue, 27 Jan 2009 08:22:31 -0800 (PST) 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 0C03A3A6A6F for ; Tue, 27 Jan 2009 08:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 DZtvBmnZQtqx for ; Tue, 27 Jan 2009 08:22:29 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 436633A6924 for ; Tue, 27 Jan 2009 08:22:29 -0800 (PST) Received: from [209.173.57.233] (helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LRqhP-00009Y-69 for ecrit@ietf.org; Tue, 27 Jan 2009 10:22:03 -0600 From: "Brian Rosen" To: References: <20090127160001.C599E3A688D@core3.amsl.com> In-Reply-To: <20090127160001.C599E3A688D@core3.amsl.com> Date: Tue, 27 Jan 2009 11:22:13 -0500 Message-ID: <006701c9809b$6b380750$41a815f0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcmAmFecpAKOcUX3T9u23I6CkaOdSQAAuKlA 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] I-D Action:draft-ietf-ecrit-framework-07.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 This is just a refresh; the old version expired. I updated a couple of references, but made no other changes. I request this document be submitted to the IESG, as no substantive changes have been made from the prior WGLC. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Tuesday, January 27, 2009 11:00 AM > To: i-d-announce@ietf.org > Cc: ecrit@ietf.org > Subject: [Ecrit] I-D Action:draft-ietf-ecrit-framework-07.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Emergency Context Resolution with > Internet Technologies Working Group of the IETF. > > > Title : Framework for Emergency Calling using Internet > Multimedia > Author(s) : B. Rosen, et al. > Filename : draft-ietf-ecrit-framework-07.txt > Pages : 37 > Date : 2009-01-27 > > The IETF has several efforts targeted at standardizing various aspects > of placing emergency calls. This document describes how all of those > component parts are used to support emergency calls from citizens and > visitors to authorities. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-07.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 From ecrit-bounces@ietf.org Tue Jan 27 08:22:44 2009 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 A041428C13E; Tue, 27 Jan 2009 08:22:44 -0800 (PST) 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 5BAE328C13E for ; Tue, 27 Jan 2009 08:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.593 X-Spam-Level: X-Spam-Status: No, score=-5.593 tagged_above=-999 required=5 tests=[AWL=1.006, 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 cOR4av+CobuQ for ; Tue, 27 Jan 2009 08:22:42 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 3542728C0EE for ; Tue, 27 Jan 2009 08:22:42 -0800 (PST) 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 n0RGMJKN007248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 27 Jan 2009 17:22:19 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0RGMJB4018780; Tue, 27 Jan 2009 17:22:19 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Jan 2009 17:22:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Jan 2009 18:22:58 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45FAD919@FIESEXC015.nsn-intra.net> In-Reply-To: <006601c9809b$38c153d0$aa43fb70$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.txt Thread-Index: AcmAmESJUWSB9Ri2TB6TcmukSiAeSQAAo62AAAAm4TA= References: <20090127160001.C34AD3A6A09@core3.amsl.com> <006601c9809b$38c153d0$aa43fb70$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Brian Rosen" , X-OriginalArrivalTime: 27 Jan 2009 16:22:18.0726 (UTC) FILETIME=[6C9CA060:01C9809B] Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.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 The feedback we got during our conference call with EMTEL needs to be discussed during the WGLC period. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Brian Rosen >Sent: 27 January, 2009 18:21 >To: ecrit@ietf.org >Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.txt > >The only change was to the LCP protocol requirements. I used >the language proposed by Marc Linsner, modified by Richard >Barnes, and removed the "v" >from 802.11v as suggested by Gabor. > >I request the chairs to run a very short WGLC and submit to the IESG. > >Brian > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Internet-Drafts@ietf.org >> Sent: Tuesday, January 27, 2009 11:00 AM >> To: i-d-announce@ietf.org >> Cc: ecrit@ietf.org >> Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Emergency Context Resolution with >> Internet Technologies Working Group of the IETF. >> >> >> Title : Best Current Practice for Communications >> Services in support of Emergency Calling >> Author(s) : B. Rosen, J. Polk >> Filename : draft-ietf-ecrit-phonebcp-07.txt >> Pages : 45 >> Date : 2009-01-27 >> >> The IETF and other standards organization have efforts targeted at >> standardizing various aspects of placing emergency calls on IP >> networks. This memo describes best current practice on how devices, >> networks and services should use such standards to make emergency >> calls. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.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 Tue Jan 27 08:38:34 2009 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 0810F28C0D0; Tue, 27 Jan 2009 08:38:34 -0800 (PST) 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 963B63A688D for ; Tue, 27 Jan 2009 08:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 n2ia22vaAg8I for ; Tue, 27 Jan 2009 08:38:31 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 73A983A68CC for ; Tue, 27 Jan 2009 08:38:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,332,1231113600"; d="scan'208";a="34972281" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 27 Jan 2009 16:38:13 +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 n0RGcDAh004004; Tue, 27 Jan 2009 11:38:13 -0500 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 n0RGcDwc008835; Tue, 27 Jan 2009 16:38:13 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 11:38:13 -0500 Received: from jmpolk-wxp01.cisco.com ([10.86.244.133]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 11:38:12 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 27 Jan 2009 10:38:10 -0600 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Brian Rosen" , From: "James M. Polk" In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45FAD919@FIESEXC015.nsn-intr a.net> References: <20090127160001.C34AD3A6A09@core3.amsl.com> <006601c9809b$38c153d0$aa43fb70$@net> <3D3C75174CB95F42AD6BCC56E5555B45FAD919@FIESEXC015.nsn-intra.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 27 Jan 2009 16:38:12.0701 (UTC) FILETIME=[A539A8D0:01C9809D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2754; t=1233074293; x=1233938293; 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]=20I-D=20Action=3Adraft-ietf-ecr it-phonebcp-07.txt |Sender:=20 |To:=20=22Tschofenig,=20Hannes=20(NSN=20-=20FI/Espoo)=22=20 ,=0A=20=20=20=20=20=20=20=20=22ex t=20Brian=20Rosen=22=20,=20; bh=9Dqa6vf+0EzLoE46W+/fgQY7h+tdh4CBxcItYhuyVLs=; b=CpdEYNDz/9moevKtXenK0DXQdu9BuVQPzJilyveFNB9RE86L2lOwxA4tpv cpN8cpDNbvQ50rWTwnPbH4pPw9BiSu/sa2qpIEmESm/PNm2LcKfAjjFX4oyH pH5oKiczfq; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.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 10:22 AM 1/27/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >The feedback we got during our conference call with EMTEL needs to be >discussed during the WGLC period. Hannes -- PhoneBCP WGLC'd last March (of 08). Are you insisting on a second WGLC? If so, you hadn't indicated that previously that I saw. >Ciao >Hannes > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of ext Brian Rosen > >Sent: 27 January, 2009 18:21 > >To: ecrit@ietf.org > >Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.txt > > > >The only change was to the LCP protocol requirements. I used > >the language proposed by Marc Linsner, modified by Richard > >Barnes, and removed the "v" > >from 802.11v as suggested by Gabor. > > > >I request the chairs to run a very short WGLC and submit to the IESG. > > > >Brian > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >> Of Internet-Drafts@ietf.org > >> Sent: Tuesday, January 27, 2009 11:00 AM > >> To: i-d-announce@ietf.org > >> Cc: ecrit@ietf.org > >> Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.txt > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the Emergency Context Resolution with > >> Internet Technologies Working Group of the IETF. > >> > >> > >> Title : Best Current Practice for Communications > >> Services in support of Emergency Calling > >> Author(s) : B. Rosen, J. Polk > >> Filename : draft-ietf-ecrit-phonebcp-07.txt > >> Pages : 45 > >> Date : 2009-01-27 > >> > >> The IETF and other standards organization have efforts targeted at > >> standardizing various aspects of placing emergency calls on IP > >> networks. This memo describes best current practice on how devices, > >> networks and services should use such standards to make emergency > >> calls. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 27 09:01:04 2009 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 8DC873A6AEE; Tue, 27 Jan 2009 09:01:04 -0800 (PST) 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 EF5733A6AB6 for ; Tue, 27 Jan 2009 09:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.604 X-Spam-Level: X-Spam-Status: No, score=-5.604 tagged_above=-999 required=5 tests=[AWL=0.995, 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 NP0paK5VAQ31 for ; Tue, 27 Jan 2009 09:01:02 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id B7FD73A68F3 for ; Tue, 27 Jan 2009 09:01:01 -0800 (PST) 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 n0RH0Z9n010081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 27 Jan 2009 18:00:35 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0RH0Y3t002106; Tue, 27 Jan 2009 18:00:34 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Jan 2009 18:00:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Jan 2009 19:01:15 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45FAD954@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.txt Thread-Index: AcmAnalURu9WVMeGSk2GLLnHP4NWdQAAxmwQ References: <20090127160001.C34AD3A6A09@core3.amsl.com><006601c9809b$38c153d0$aa43fb70$@net><3D3C75174CB95F42AD6BCC56E5555B45FAD919@FIESEXC015.nsn-intra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext James M. Polk" , "ext Brian Rosen" , X-OriginalArrivalTime: 27 Jan 2009 17:00:34.0529 (UTC) FILETIME=[C5045D10:01C980A0] Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.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 James, I was thinking about submitting a short WGLC (for one week) starting by today. In any case, I hope that these two docs are done very, very soon. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext James M. Polk >Sent: 27 January, 2009 18:38 >To: Tschofenig, Hannes (NSN - FI/Espoo); ext Brian Rosen; >ecrit@ietf.org >Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.txt > >At 10:22 AM 1/27/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>The feedback we got during our conference call with EMTEL needs to be >>discussed during the WGLC period. > >Hannes -- PhoneBCP WGLC'd last March (of 08). Are you >insisting on a second WGLC? If so, you hadn't indicated that >previously that I saw. > > >>Ciao >>Hannes >> >> >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >On Behalf Of ext Brian Rosen >> >Sent: 27 January, 2009 18:21 >> >To: ecrit@ietf.org >> >Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.txt >> > >> >The only change was to the LCP protocol requirements. I used >> >the language proposed by Marc Linsner, modified by Richard >> >Barnes, and removed the "v" >> >from 802.11v as suggested by Gabor. >> > >> >I request the chairs to run a very short WGLC and submit to >the IESG. >> > >> >Brian >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >On Behalf >> >> Of Internet-Drafts@ietf.org >> >> Sent: Tuesday, January 27, 2009 11:00 AM >> >> To: i-d-announce@ietf.org >> >> Cc: ecrit@ietf.org >> >> Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.txt >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >> directories. >> >> This draft is a work item of the Emergency Context Resolution with >> >> Internet Technologies Working Group of the IETF. >> >> >> >> >> >> Title : Best Current Practice for Communications >> >> Services in support of Emergency Calling >> >> Author(s) : B. Rosen, J. Polk >> >> Filename : draft-ietf-ecrit-phonebcp-07.txt >> >> Pages : 45 >> >> Date : 2009-01-27 >> >> >> >> The IETF and other standards organization have efforts targeted at >> >> standardizing various aspects of placing emergency calls on IP >> >> networks. This memo describes best current practice on >how devices, >> >> networks and services should use such standards to make emergency >> >> calls. >> >> >> >> A URL for this Internet-Draft is: >> >> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.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 > >_______________________________________________ >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 Jan 27 09:02:35 2009 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 D3E633A68F3; Tue, 27 Jan 2009 09:02:35 -0800 (PST) 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 1B0243A68F3 for ; Tue, 27 Jan 2009 09:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 Md+pehl8zUuB for ; Tue, 27 Jan 2009 09:02:33 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D60B83A68D2 for ; Tue, 27 Jan 2009 09:02:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,332,1231113600"; d="scan'208";a="35013332" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 27 Jan 2009 17:02:13 +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 n0RH2Dvd009488; Tue, 27 Jan 2009 12:02:13 -0500 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 n0RH2DPf019906; Tue, 27 Jan 2009 17:02:13 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 12:02:13 -0500 Received: from jmpolk-wxp01.cisco.com ([10.86.244.133]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 12:02:13 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 27 Jan 2009 11:02:10 -0600 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Brian Rosen" , From: "James M. Polk" In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45FAD954@FIESEXC015.nsn-intr a.net> References: <20090127160001.C34AD3A6A09@core3.amsl.com> <006601c9809b$38c153d0$aa43fb70$@net> <3D3C75174CB95F42AD6BCC56E5555B45FAD919@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45FAD954@FIESEXC015.nsn-intra.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 27 Jan 2009 17:02:13.0243 (UTC) FILETIME=[FFDAECB0:01C980A0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3801; t=1233075733; x=1233939733; 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]=20I-D=20Action=3Adraft-ietf-ecr it-phonebcp-07.txt |Sender:=20 |To:=20=22Tschofenig,=20Hannes=20(NSN=20-=20FI/Espoo)=22=20 ,=0A=20=20=20=20=20=20=20=20=22ex t=20Brian=20Rosen=22=20,=20; bh=gsyfq9Rte3jWxSVDJieqdFbXHdfX+WBnWjUS59f+xVs=; b=rJvWrDBVbdxsjGyiJI8k5b5KuSLnaa2QucaPgiQkYWatA3pXlSrKPyvL7J HfR2FVMG7oZXa760pYkW429w2KWuRi1LqCregJkCctJ8JvnxFGjbHFPIlAeg 7Jfs9s6JEN; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.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 ok -- I was just wondering if I missed a message about this. thanks James At 11:01 AM 1/27/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >Hi James, > >I was thinking about submitting a short WGLC (for one week) starting by >today. >In any case, I hope that these two docs are done very, very soon. > >Ciao >Hannes > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of ext James M. Polk > >Sent: 27 January, 2009 18:38 > >To: Tschofenig, Hannes (NSN - FI/Espoo); ext Brian Rosen; > >ecrit@ietf.org > >Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.txt > > > >At 10:22 AM 1/27/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >>The feedback we got during our conference call with EMTEL needs to be > >>discussed during the WGLC period. > > > >Hannes -- PhoneBCP WGLC'd last March (of 08). Are you > >insisting on a second WGLC? If so, you hadn't indicated that > >previously that I saw. > > > > > >>Ciao > >>Hannes > >> > >> > >> >-----Original Message----- > >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >On Behalf Of ext Brian Rosen > >> >Sent: 27 January, 2009 18:21 > >> >To: ecrit@ietf.org > >> >Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.txt > >> > > >> >The only change was to the LCP protocol requirements. I used > >> >the language proposed by Marc Linsner, modified by Richard > >> >Barnes, and removed the "v" > >> >from 802.11v as suggested by Gabor. > >> > > >> >I request the chairs to run a very short WGLC and submit to > >the IESG. > >> > > >> >Brian > >> > > >> >> -----Original Message----- > >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> >On Behalf > >> >> Of Internet-Drafts@ietf.org > >> >> Sent: Tuesday, January 27, 2009 11:00 AM > >> >> To: i-d-announce@ietf.org > >> >> Cc: ecrit@ietf.org > >> >> Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-07.txt > >> >> > >> >> A New Internet-Draft is available from the on-line Internet-Drafts > >> >> directories. > >> >> This draft is a work item of the Emergency Context Resolution with > >> >> Internet Technologies Working Group of the IETF. > >> >> > >> >> > >> >> Title : Best Current Practice for Communications > >> >> Services in support of Emergency Calling > >> >> Author(s) : B. Rosen, J. Polk > >> >> Filename : draft-ietf-ecrit-phonebcp-07.txt > >> >> Pages : 45 > >> >> Date : 2009-01-27 > >> >> > >> >> The IETF and other standards organization have efforts targeted at > >> >> standardizing various aspects of placing emergency calls on IP > >> >> networks. This memo describes best current practice on > >how devices, > >> >> networks and services should use such standards to make emergency > >> >> calls. > >> >> > >> >> A URL for this Internet-Draft is: > >> >> > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-07.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 > > > >_______________________________________________ > >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 Jan 27 11:36:53 2009 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 967E63A696A; Tue, 27 Jan 2009 11:36:53 -0800 (PST) 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 3DFBD3A6B04 for ; Tue, 27 Jan 2009 11:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.615 X-Spam-Level: X-Spam-Status: No, score=-5.615 tagged_above=-999 required=5 tests=[AWL=0.984, 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 2cEUkfuxZkJ8 for ; Tue, 27 Jan 2009 11:36:51 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 215E63A696A for ; Tue, 27 Jan 2009 11:36:50 -0800 (PST) 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 n0RJaV98000456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 27 Jan 2009 20:36:31 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0RJaQhM025731 for ; Tue, 27 Jan 2009 20:36:31 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Jan 2009 20:36:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Jan 2009 21:37:13 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45FADA13@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Short WGLC for draft-ietf-ecrit-framework-07.txt Thread-Index: AcmAtqcEmO6nnAlMTT21RccIvYHvEA== X-Priority: 1 Priority: Urgent Importance: high From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 27 Jan 2009 19:36:31.0214 (UTC) FILETIME=[8E0930E0:01C980B6] Subject: [Ecrit] Short WGLC for draft-ietf-ecrit-framework-07.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, this is a (short) Last Call for comments on http://tools.ietf.org/id/draft-ietf-ecrit-framework-07.txt Please have your comments in no later than February 4th. Ciao Hannes & Marc PS: We had a WGLC on this document already last year, see http://www.ietf.org/mail-archive/web/ecrit/current/msg04840.html _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jan 27 11:36:53 2009 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 BD13C28C153; Tue, 27 Jan 2009 11:36:53 -0800 (PST) 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 7711F3A696A for ; Tue, 27 Jan 2009 11:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.625 X-Spam-Level: X-Spam-Status: No, score=-3.625 tagged_above=-999 required=5 tests=[AWL=-1.027, 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 pb1sHAwmKWHI for ; Tue, 27 Jan 2009 11:36:48 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 731C33A6825 for ; Tue, 27 Jan 2009 11:36:47 -0800 (PST) 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 n0RJaSdx011406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 27 Jan 2009 20:36:28 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0RJaRMt012388 for ; Tue, 27 Jan 2009 20:36:28 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Jan 2009 20:36:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Jan 2009 21:37:09 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45FADA12@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Short WGLC for draft-ietf-ecrit-phonebcp-07 Thread-Index: AcmAtqUbBFyRbP9NSj6YLt3LyIVPmA== X-Priority: 1 Priority: Urgent Importance: high From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 27 Jan 2009 19:36:27.0548 (UTC) FILETIME=[8BD9CDC0:01C980B6] Subject: [Ecrit] Short WGLC for draft-ietf-ecrit-phonebcp-07 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="===============0799031285==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0799031285== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C980B6.8BF1358C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C980B6.8BF1358C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 this is a (short) Last Call for comments on http://tools.ietf.org/id/draft-ietf-ecrit-phonebcp-07.txt Please have your comments in no later than February 4th.=20 PLEASE READ THIS DOCUMENT! Ciao Hannes & Marc=20 PS: We had a WGLC on this document already last year, see http://www.ietf.org/mail-archive/web/ecrit/current/msg04839.html ------_=_NextPart_001_01C980B6.8BF1358C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Short WGLC for draft-ietf-ecrit-phonebcp-07

Hi all,

this is a (short) Last Call for = comments on
http://tools.ietf.org/id/draft-ietf-ecrit-phonebcp-07.txt=

Please have your comments in no = later than February 4th.

PLEASE READ THIS DOCUMENT!

Ciao
Hannes & Marc

PS: We had a WGLC on this = document already last year, see http://www.ietf.org/mail-archive/web/ecrit/current/msg04839.html


------_=_NextPart_001_01C980B6.8BF1358C-- --===============0799031285== 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 --===============0799031285==-- From ecrit-bounces@ietf.org Wed Jan 28 21:54:24 2009 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 773863A6983; Wed, 28 Jan 2009 21:54:24 -0800 (PST) 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 7384E3A684A for ; Wed, 28 Jan 2009 21:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=-0.023, 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 iJ6R0QY+TH6J for ; Wed, 28 Jan 2009 21:54:21 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id C4A423A6983 for ; Wed, 28 Jan 2009 21:54:20 -0800 (PST) Received: from [128.89.252.93] (helo=Richard-Barnes-Laptop.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LSPqf-0001UQ-9y; Thu, 29 Jan 2009 00:53:57 -0500 Message-ID: <49814474.6070606@bbn.com> Date: Thu, 29 Jan 2009 00:53:56 -0500 From: Richard Barnes User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: ECRIT , draft-ietf-ecrit-lost-sync@tools.ietf.org Subject: [Ecrit] Review of draft-ietf-lost-sync-01 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 draft proposes an XML syntax for transferring LoST mappings between LoST nodes. While this XML syntax seems to have most of the necessary features for the proposed use cases, the details of how the XML syntax is to be used to effect the transfer are either ambiguous or completely missing. Specific comments below. --Richard Section 1. Introduction -- This may reflect a misunderstanding of the mapping architecture on my part, but my impression was that the architecture envisioned query patterns similar to the DNS, either iterating or recursing through the tree. This document seems to propose that instead, authoritative servers and branch nodes would push mapping up, presumably to FGs (this behavior has no analogue in the DNS to my knowledge). It would be helpful if this document could clarify how these two patterns interact. Section 3. Distributing Mappings via ... -- I think there's enough description here to basically understand how this is supposed to work, but there's not a clear, normative specification, not a single MUST in the whole section! It would be helpful to have clear "Sender processing" and "Recipient processing" instructions. -- Likewise, there's no clear description of who sends which messages to whom (except by example), and no description at all of how these messages are carried. If this is an extension to LoST, please say so, or if it's another HTTP usage, or bare TCP, etc. The absence of these details (particularly message flow patterns), it's a hard to understand the sequence of events. -- The message pattern this seems to be following is a little weird; it's "pub/sub", but without the "sub". There should be some comment on this, e.g., that there is an expectation that these peering relationships are established out of band, and thus no subscription or request is necessary. Alternatively, could possibly support an "asynchronous" flag. -- There's a stray " at the end of the fourth paragraph -- The URIs in the example fields are invalid Section 4. Synchronizing Mapping Stores via ... -- Same first two comments as for Section 3. There needs to be a much clearer, normative description of how the peers process and transmit messages. -- Please change the tag to something readable (?) -- The description here seems to conflate two types of query parameters, "what I have" and "what I want". If you separate these two out, it could simplify the semantics: the "what I have" section would have elements that MUST have all three identifier fields, while the "what I want" section would have descriptions of mappings to be returned (using subsets of identifier fields). -- Why can't a element have a lastUpdated attribute? Either it should have everything or nothing. (IMO, the optimization isn't worth the extra complexity of merging attributes from and ) -- Is there a reason no content-based queries are allowed? For example, I could imagine that it would be useful to be able to query for all service boundaries that intersect a given region, or to constrain a query by service URN. Section 5. Security Considerations -- The document delegates security to LoST without ever having said that the XML defined here is carried by LoST. In order for this stuff to be meaningful, there has to be a transport protocol defined. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jan 30 15:22:43 2009 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 B0F2A3A6922; Fri, 30 Jan 2009 15:22:43 -0800 (PST) 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 B04853A68D2 for ; Fri, 30 Jan 2009 15:22:42 -0800 (PST) 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 HQxmznC5QVLE for ; Fri, 30 Jan 2009 15:22:41 -0800 (PST) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id 105133A67A3 for ; Fri, 30 Jan 2009 15:22:39 -0800 (PST) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1233357738; x=1233444138; h=From:Date:Subject:Message-ID:Content-Type:Content-Transfer-Encoding:Content-cl ass; b=cZDwkzmH1rhs6Be1CNBLgoa3O/q7xpN+05ca+Uy5UFNDGBkr+95tgYjA6WvJScIv2EAkMgCelOZvHK qVJi3QCw== Received: from ([10.31.13.50]) by chihiron2.nc.neustar.com with ESMTP id 5202415.11229778; Fri, 30 Jan 2009 18:22:04 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 x-cr-puzzleid: {F518282D-DF23-4973-BEFC-AF97F8825EFA} x-cr-hashedpuzzle: A0Kp CFk8 CcK1 C1eA DG9X EIdF EaRu Edua EhKx EkY8 FRXJ Fk2c F4Xl HoKP IWkE Kj7k; 1; ZQBjAHIAaQB0AEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {F518282D-DF23-4973-BEFC-AF97F8825EFA}; YgByAGkAYQBuAC4AcgBvAHMAZQBuAEAAbgBlAHUAcwB0AGEAcgAuAGIAaQB6AA==; Fri, 30 Jan 2009 23:20:50 GMT; RABvAGUAcwAgAGkAdAAgAG0AYQBrAGUAIABzAGUAbgBzAGUAIAB0AG8AIABlAG0AYQBpAGwAIAB0AG8AIAB1AHIAbgA6AHMAZQByAHYAaQBjAGUAOgBzAG8AcwA/AA== Content-class: urn:content-classes:message Date: Fri, 30 Jan 2009 18:20:50 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does it make sense to email to urn:service:sos? Thread-Index: AcmDMWOtSoU7FJUQQ42CbNtnSJaDcA== From: "Rosen, Brian" To: Subject: [Ecrit] Does it make sense to email to urn:service:sos? 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 subject of emailing an emergency request comes up from time to time. So far, we've dismissed the idea primarily because email is not a real time protocol. In the U.S., we have started working towards supporting SMS for emergency use. The objection raised is "SMS is not a real time protocol". My response to the SMS issue is "although it's certainly true that it isn't a real time protocol, and messages can be delayed by minutes, hours, or even days, people use it as if it was real time, and deal with the reality that it isn't. Many users have an expectation that they should be able to text to the emergency service". Is that not true, perhaps to somewhat less degree, for email? Users are indeed less likely to treat email as real time, but in fact they often use it as if it was. Let us consider what it would take to allow email for emergency services: 1. We would need a way to convey location in SMTP 2. We would need a way to mark an emergency email 3. We would need a way to route an emergency email It goes without saying that a PSAP could send a reply email to the originator. 2 and 3 could clearly be virtually identical to what we use for calls: "dial string" translation to urn:service:sos, LoST routing to a URI, regular email routing to that URI. 1 would require a new feature in SMTP. I'm not sure there is any analog to the "recognize the local dial string, translate to the service urn, retarget to the PSAP URI", but it does seem like a straightforward thing for an email server to do. Does this make any sense? Is there a good reason NOT to do it? Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jan 31 04:30:59 2009 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 0275928C0E4; Sat, 31 Jan 2009 04:30:59 -0800 (PST) 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 E4DFE28C0E4 for ; Sat, 31 Jan 2009 04:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 YiAR1CHHoDot for ; Sat, 31 Jan 2009 04:30:56 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6178D3A6803 for ; Sat, 31 Jan 2009 04:30:55 -0800 (PST) Received: (qmail invoked by alias); 31 Jan 2009 12:30:36 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp015) with SMTP; 31 Jan 2009 13:30:36 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+DdCIbO9iDLLtsoYk5IBR+UM+H0qgdN62mUxZ+YM NphdLwE+ejSg+V From: "Hannes Tschofenig" To: "'Rosen, Brian'" , References: Date: Sat, 31 Jan 2009 14:31:19 +0200 Message-ID: <044901c9839f$d2a5f4e0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AcmDMWOtSoU7FJUQQ42CbNtnSJaDcAAZ+iUA X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? 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, we have already everything in place that would allow emergency email to work. Here are the building blocks: * LoST * mails can obviously carry location as location is just another MIME type * mechanisms to obtain location LoST allows different elements to be returned. In the examples we spoke about SIP related URIs (including tel URIs) and XMPP URIs. Obviously one can also put a mailto: URI in there. So, if the end point uses LoST to obtain the mailto: URI then it could send the emergency email there. One important question is: Would email provider be interested in deploying this? I suspect "no". Hence, it is better not to mark the mail as an emergency email in the same way as we did the marking with the Service URN in SIP. Instead, the theme would be to mark it for those you care and if there is someone who does not care then it still gets routed to the right place (rather than dropped on the floor). The fear that a user could do fraud by marking emails as emergency emails is not really an issue for email at all. It might be possible to operate dedicated email providers only responsible for handling emergency email routing as many email clients allow multiple accounts to be maintained quite transparently. The next important question is whether the PSAP operator really want this. We all know that email does not really have a strong notion of security. Even though there is DKIM standardized it isn't widely used. As such, there is essentially no cryptographic identity with email the PSAP operators get and email operators will not deploy new security security mechanisms for this purpose either since the email operators will not like the emergency email concept as it adds new obligations for them and no (monetary) benefit. PSAPs might receive a lot of fake emergency mails and it might make them difficult to figure out which onces are real. The final aspect is on location suitable for dispatch: While our protocols would support ways to fetch location by the PSAP operator from the access provider using, for example, the location by reference concept we so far know that (despite initial indications of interest) operators rather prefer a model where they do not send anything to the end host. Even though the location aspect is independent of the actual application service (voice, IM, email, etc.) most operators would not see it that way. Hence, they would only hand out location to the PSAP if the regulator forces them (and sometimes not even then). This is more an procedural aspect than a technical one. Did you think about an opt-in variant or not? Ciao Hannes PS: I see James already writing an RPH extension for email :-) >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Rosen, Brian >Sent: 31 January, 2009 01:21 >To: ecrit@ietf.org >Subject: [Ecrit] Does it make sense to email to urn:service:sos? > >The subject of emailing an emergency request comes up from >time to time. >So far, we've dismissed the idea primarily because email is >not a real time protocol. > >In the U.S., we have started working towards supporting SMS >for emergency use. The objection raised is "SMS is not a real >time protocol". > >My response to the SMS issue is "although it's certainly true >that it isn't a real time protocol, and messages can be >delayed by minutes, hours, or even days, people use it as if >it was real time, and deal with the reality that it isn't. >Many users have an expectation that they should be able to >text to the emergency service". > >Is that not true, perhaps to somewhat less degree, for email? >Users are indeed less likely to treat email as real time, but >in fact they often use it as if it was. > >Let us consider what it would take to allow email for emergency >services: >1. We would need a way to convey location in SMTP 2. We would >need a way to mark an emergency email 3. We would need a way >to route an emergency email It goes without saying that a PSAP >could send a reply email to the originator. > >2 and 3 could clearly be virtually identical to what we use for calls: >"dial string" translation to urn:service:sos, LoST routing to >a URI, regular email routing to that URI. 1 would require a >new feature in SMTP. I'm not sure there is any analog to the >"recognize the local dial string, translate to the service >urn, retarget to the PSAP URI", but it does seem like a >straightforward thing for an email server to do. > >Does this make any sense? Is there a good reason NOT to do it? > >Brian > > >_______________________________________________ >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 Sat Jan 31 13:59:26 2009 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 68DA83A682D; Sat, 31 Jan 2009 13:59:26 -0800 (PST) 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 2B5383A682D for ; Sat, 31 Jan 2009 13:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 YBEk4IYi1hMC for ; Sat, 31 Jan 2009 13:59:24 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id F2CDE3A67D7 for ; Sat, 31 Jan 2009 13:59:23 -0800 (PST) Received: (qmail invoked by alias); 31 Jan 2009 21:59:04 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp009) with SMTP; 31 Jan 2009 22:59:04 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18GxbMupxsGncst5vlJKDJta8BzNbpUcdE9FHv5yV cf+bt/yItGNpVw From: "Hannes Tschofenig" To: "'ext Hannes Tschofenig'" , "'ECRIT'" References: <003301c97e00$ac955f60$0201a8c0@nsnintra.net> <013501c97ec9$5cc04300$0201a8c0@nsnintra.net> Date: Sat, 31 Jan 2009 23:59:47 +0200 Message-ID: <045801c983ef$3c4643b0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <013501c97ec9$5cc04300$0201a8c0@nsnintra.net> Thread-Index: Acl+AGcDaTZN0lrqSDa8KqbwOQ/NCAAyLM5QAUk+ynA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: [Ecrit] ECRIT Virtual Interim Meeting: 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, Based on the received feedback I have picked one of the preferred dates: >>> 26th February, 2:00 PM EST <<< Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Hannes Tschofenig >Sent: 25 January, 2009 10:46 >To: 'Hannes Tschofenig'; 'ECRIT' >Subject: [Ecrit] ECRIT Virtual Interim Meeting: Update >Importance: High > >Brian quickly spotted a conflict with the NENA TDC. Here is >another try: >http://www.doodle.com/4z4q2fr9mukxn876 > >Ciao >Hannes > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >>Of Hannes Tschofenig >>Sent: 24 January, 2009 10:49 >>To: ECRIT >>Subject: [Ecrit] ECRIT Virtual Interim Meeting >> >>Hi all, >> >>to make some progress in ECRIT we would like to make a proposal for a >>virtual interim meeting. The concept of virtual interim meetings is >>floating around in the IETF recently and we thought it is a >pretty good >>idea. Virtual interim meeting means that we are going to have a phone >>conference call for about ~2 hours to chat about working group items. >> >>So, unless there are strong objections we suggest that ECRIT >holds such >>a meeting on the 18th February 2009, 10am EST for 2 hours. >> >>Proposed agenda: Discuss status and open issues of ECRIT >working group >>items >> >>We will send an update within the next week on the technicalities of >>the call. >> >>Document authors, please resubmit your drafts by the 11th February. >> >>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 Sat Jan 31 15:10:21 2009 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 44A3B3A6808; Sat, 31 Jan 2009 15:10:21 -0800 (PST) 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 B733A3A6808 for ; Sat, 31 Jan 2009 15:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 UX5DtRA6fjOh for ; Sat, 31 Jan 2009 15:10:19 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 82BD73A67D1 for ; Sat, 31 Jan 2009 15:10:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,356,1231113600"; d="scan'208";a="240586320" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 Jan 2009 23:10:01 +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 n0VNA1Ne028719; Sat, 31 Jan 2009 15:10:01 -0800 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 n0VNA0kQ018637; Sat, 31 Jan 2009 23:10:00 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); Sat, 31 Jan 2009 15:10:00 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.18.249]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 Jan 2009 15:10:00 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 31 Jan 2009 17:09:59 -0600 To: "Hannes Tschofenig" , "'Rosen, Brian'" , From: "James M. Polk" In-Reply-To: <044901c9839f$d2a5f4e0$0201a8c0@nsnintra.net> References: <044901c9839f$d2a5f4e0$0201a8c0@nsnintra.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 31 Jan 2009 23:10:00.0126 (UTC) FILETIME=[0A650DE0:01C983F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7502; t=1233443401; x=1234307401; 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]=20Does=20it=20make=20sense=20to =20email=20to=20urn=3Aservice=3Asos? |Sender:=20; bh=TOS0Irp4h0RJdGe7ABkXTi1XQ2OE5OAAP0HHDBNfmAA=; b=nt2Hr/kFCkP77zZAmhNQOmeGYV5jwR4pUh+Zv74pVQ39WuC4oyes117R5K ZufXhz2VTArFRiiCuhUR2kli1BMFAAiCIu+PB/cQq3n9caLkeHChPWSBt4tw fWo8R644CajEnjS1JsaUzktgltpQBGEuTYHAmHzPlyH4yQAwg/E7Y=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos? 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 SWIW - email has no guarantee of delivery - no guarantee of delivery to the right endpoint - no guarantee of delivery to the an endpoint application that won't filter said message into the wrong directory/folder - had a HIGH likelihood of SPAM on the recepient's end - SPAM could in general become the biggest issue wrt actually having someone at the PSAP have to "look" at each and every message because no one can build in the proper automated filters to cover all possible misspellings of a legitimate email message - every email application will have to be revved to incorporate location into some kind of user identifying indication this is for sos (maybe this is merely having the "urn:service:sos" in the To: header). Many (most) users do not upgrade their mailers too often (like their home routers)... so this upgrade path will be an issue, because it likely cannot be universally expected by the network to be in place. - MTAs don't have the ability to understand where "I am" to insert location, given the number of users that either -- use a generic application on any computer to access their email, or -- have a VPN for example, I use the same laptop with an out of date email application (Eudora -- that's not supported anymore, and even if it was -- which version do I have?). I'm connecting via a VPN today from a suburb of Fort Worth through Cisco's Richardson facility (which is a suburb of Dallas) through Cisco San Jose (California). Last wee I was in Barcelona, Spain. I used the same VPN server in Richardson to get to the Cisco San Jose campus. The only thing that changed was my origination point, one that cannot be tied to an IP address, because any VPN that I use going through Richardson - which gives my laptop one from its own address range. To make matters worse, I have access to 16 other VPN connection points other than Richardson (in case I cannot get through via Richardson). Some times these are accessed automatically, sometimes I purposely connect to another Cisco site than Richardson directly. How does Cisco understand where I am connecting from? I'm mostly focused on location URIs being inserted by a server in the network thinking it knows where I am (i.e., what we (use to?) call a "sighter" function). At 06:31 AM 1/31/2009, Hannes Tschofenig wrote: >Hi Brian, > >we have already everything in place that would allow emergency email to >work. > >Here are the building blocks: > >* LoST >* mails can obviously carry location as location is just another MIME type >* mechanisms to obtain location > >LoST allows different elements to be returned. In the examples we >spoke about SIP related URIs (including tel URIs) and XMPP URIs. Obviously >one can also put a mailto: URI in there. > >So, if the end point uses LoST to obtain the mailto: URI then it could send >the emergency email there. > >One important question is: Would email provider be interested in deploying >this? I suspect "no". Hence, it is better not to mark the mail as an >emergency email in the same way as we did the marking with the Service URN >in SIP. Instead, the theme would be to mark it for those you care and if >there is someone who does not care then it still gets routed to the right >place (rather than dropped on the floor). The fear that a user could do >fraud by marking emails as emergency emails is not really an issue for email >at all. > >It might be possible to operate dedicated email providers only responsible >for handling emergency email routing as many email clients allow multiple >accounts to be maintained quite transparently. > >The next important question is whether the PSAP operator really want this. >We all know that email does not really have a strong notion of security. >Even though there is DKIM standardized it isn't widely used. As such, there >is essentially no cryptographic identity with email the PSAP operators get >and email operators will not deploy new security security mechanisms for >this purpose either since the email operators will not like the emergency >email concept as it adds new obligations for them and no (monetary) benefit. >PSAPs might receive a lot of fake emergency mails and it might make them >difficult to figure out which onces are real. > >The final aspect is on location suitable for dispatch: While our protocols >would support ways to fetch location by the PSAP operator from the access >provider using, for example, the location by reference concept we so far >know that (despite initial indications of interest) operators rather prefer >a model where they do not send anything to the end host. Even though the >location aspect is independent of the actual application service (voice, IM, >email, etc.) most operators would not see it that way. Hence, they would >only hand out location to the PSAP if the regulator forces them (and >sometimes not even then). This is more an procedural aspect than a technical >one. > >Did you think about an opt-in variant or not? > >Ciao >Hannes > >PS: I see James already writing an RPH extension for email :-) > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of Rosen, Brian > >Sent: 31 January, 2009 01:21 > >To: ecrit@ietf.org > >Subject: [Ecrit] Does it make sense to email to urn:service:sos? > > > >The subject of emailing an emergency request comes up from > >time to time. > >So far, we've dismissed the idea primarily because email is > >not a real time protocol. > > > >In the U.S., we have started working towards supporting SMS > >for emergency use. The objection raised is "SMS is not a real > >time protocol". > > > >My response to the SMS issue is "although it's certainly true > >that it isn't a real time protocol, and messages can be > >delayed by minutes, hours, or even days, people use it as if > >it was real time, and deal with the reality that it isn't. > >Many users have an expectation that they should be able to > >text to the emergency service". > > > >Is that not true, perhaps to somewhat less degree, for email? > >Users are indeed less likely to treat email as real time, but > >in fact they often use it as if it was. > > > >Let us consider what it would take to allow email for emergency > >services: > >1. We would need a way to convey location in SMTP 2. We would > >need a way to mark an emergency email 3. We would need a way > >to route an emergency email It goes without saying that a PSAP > >could send a reply email to the originator. > > > >2 and 3 could clearly be virtually identical to what we use for calls: > >"dial string" translation to urn:service:sos, LoST routing to > >a URI, regular email routing to that URI. 1 would require a > >new feature in SMTP. I'm not sure there is any analog to the > >"recognize the local dial string, translate to the service > >urn, retarget to the PSAP URI", but it does seem like a > >straightforward thing for an email server to do. > > > >Does this make any sense? Is there a good reason NOT to do it? > > > >Brian > > > > > >_______________________________________________ > >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 Sat Jan 31 15:13:19 2009 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 7007D3A6856; Sat, 31 Jan 2009 15:13:19 -0800 (PST) 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 71B7E3A67D1 for ; Sat, 31 Jan 2009 15:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 achhL8U7rkN0 for ; Sat, 31 Jan 2009 15:13:17 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A97D13A6856 for ; Sat, 31 Jan 2009 15:13:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,356,1231113600"; d="scan'208";a="240587129" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 31 Jan 2009 23:12:59 +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 n0VNCxIg027999; Sat, 31 Jan 2009 15:12:59 -0800 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 n0VNCxCB019283; Sat, 31 Jan 2009 23:12:59 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); Sat, 31 Jan 2009 15:12:59 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.18.249]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 Jan 2009 15:12:58 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 31 Jan 2009 17:12:58 -0600 To: "Hannes Tschofenig" , "'ext Hannes Tschofenig'" , "'ECRIT'" From: "James M. Polk" In-Reply-To: <045801c983ef$3c4643b0$0201a8c0@nsnintra.net> References: <003301c97e00$ac955f60$0201a8c0@nsnintra.net> <013501c97ec9$5cc04300$0201a8c0@nsnintra.net> <045801c983ef$3c4643b0$0201a8c0@nsnintra.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 31 Jan 2009 23:12:58.0742 (UTC) FILETIME=[74DBB160:01C983F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2333; t=1233443579; x=1234307579; 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=20Virtual=20Interim=20M eeting=3A=20Update |Sender:=20; bh=BifWprmcw41FFHW7+NwKzDi2BGSPUG+4cvyimEKrvqg=; b=Ok8HdoNQX3kX4kx9+z8L+KDykm65IxVzF94tOn+ilr4xxFPz6WeniPQoz3 hU3fXu5FhvU9eY5d6qNRDWa8fut6xDxRFD0yEDA75ELTanirtFcTz4bPVNKN U2FKEfHkr1; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Ecrit] ECRIT Virtual Interim Meeting: 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 03:59 PM 1/31/2009, Hannes Tschofenig wrote: >Hi all, > >Based on the received feedback I have picked one of the preferred dates: > > >>> 26th February, 2:00 PM EST <<< err... hate to point this one out, but no day at 2pm EST was an option. The options were 8am and 1pm (both EST) Please clarify this >Ciao >Hannes > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of ext Hannes Tschofenig > >Sent: 25 January, 2009 10:46 > >To: 'Hannes Tschofenig'; 'ECRIT' > >Subject: [Ecrit] ECRIT Virtual Interim Meeting: Update > >Importance: High > > > >Brian quickly spotted a conflict with the NENA TDC. Here is > >another try: > >http://www.doodle.com/4z4q2fr9mukxn876 > > > >Ciao > >Hannes > > > >>-----Original Message----- > >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >>Of Hannes Tschofenig > >>Sent: 24 January, 2009 10:49 > >>To: ECRIT > >>Subject: [Ecrit] ECRIT Virtual Interim Meeting > >> > >>Hi all, > >> > >>to make some progress in ECRIT we would like to make a proposal for a > >>virtual interim meeting. The concept of virtual interim meetings is > >>floating around in the IETF recently and we thought it is a > >pretty good > >>idea. Virtual interim meeting means that we are going to have a phone > >>conference call for about ~2 hours to chat about working group items. > >> > >>So, unless there are strong objections we suggest that ECRIT > >holds such > >>a meeting on the 18th February 2009, 10am EST for 2 hours. > >> > >>Proposed agenda: Discuss status and open issues of ECRIT > >working group > >>items > >> > >>We will send an update within the next week on the technicalities of > >>the call. > >> > >>Document authors, please resubmit your drafts by the 11th February. > >> > >>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