From john.elwell@siemens-enterprise.com Fri May 1 00:24:05 2009 Return-Path: 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 C6F823A6FF7 for ; Fri, 1 May 2009 00:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 rsb-Ukb7OSi8 for ; Fri, 1 May 2009 00:24:04 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id D32BD3A6FED for ; Fri, 1 May 2009 00:24:03 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KIY00FD3FAEQE@siemenscomms.co.uk> for ecrit@ietf.org; Fri, 01 May 2009 08:25:26 +0100 (BST) Date: Fri, 01 May 2009 08:25:25 +0100 From: "Elwell, John" In-reply-to: To: Marc Linsner , Ted Hardie , ecrit@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001D8D5F8@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnJzTFWv2G1/rdFK0mW8nvlVMBQZgAYFX6w Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: 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: , X-List-Received-Date: Fri, 01 May 2009 07:24:05 -0000 I can't recall any. We sometimes state the opposite, i.e., some RFCs (e.g., those specifying P-headers) state that they are not suitable for the Internet, only for use in closed environments. For the majority of SIP specs there is no such applicability statement. John > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Marc Linsner > Sent: 30 April 2009 20:52 > To: Ted Hardie; ecrit@ietf.org > Subject: Re: [Ecrit] PhoneBCP >=20 > Ted, >=20 > I searched a small amount for comparison type language in=20 > other IETF drafts. > I'm struggling with the notion that anyone who would read=20 > IETF drafts would > get confused as to their solution/applicability space. >=20 > Since my search was small and cycles are short, are you aware=20 > if there is > any such language in any of the ream of SIP drafts that point out the > solution space and explicitly exclude IMS? >=20 > -Marc- >=20 >=20 > On 4/30/09 1:40 PM, "Ted Hardie" wrote: >=20 > > At 9:48 AM -0700 4/30/09, Dawson, Martin wrote: > >> Understanding ECRIT means understanding that broadband=20 > Internet access is > >> broadband Internet access is broadband Internet access. > >=20 > > To put it mildy, this is far from true. There is a whole=20 > class of offerings > > that > > is voice-as-a-service (the IMS/NGN group) which absolutely=20 > do not act like > > voice-as-an-application. The solution we've defined is for > > voice-as-an-application, > > which has the natural result that the end user device has=20 > the primary role. > >=20 > > The root of the problem we're facing is that there is a=20 > difference between > > using IP and using the Internet model. IMS uses IP, but=20 > uses a different > > model entirely (Whatever you think of that model, I don't=20 > think anyone > > who looked at how it works could argue that it is the same=20 > as the Internet > > model.) > >=20 > > The documents we're dealing with contrast the offering with=20 > PSTN, but > > don't really see any differentiation among "packet-switched=20 > networks". > > Take this early text from the Framework document: > >=20 > >> It is beyond the scope of this document to enumerate and=20 > discuss all > >> the differences between traditional (Public Switched Telephone > >> Network) and IP-based telephony, but calling on the Internet is > >> characterized by: > >> o the interleaving over the same infrastructure of a=20 > wider variety > >> of services; > >> o the separation of the access provider from the application > >> provider; > >> o media other than voice (e.g. video and text in several forms); > >> o the potential mobility of all end systems, including endpoints > >> nominally thought of as fixed systems and not just those using > >> radio access technology. For example, consider a wired phone > >> connected to a router using a mobile data network=20 > such as EV-DO as > >> an uplink. > >>=20 > >> This document focuses on how devices using the Internet can place > >> emergency calls and how PSAPs can handle Internet multimedia > >> emergency calls natively, rather than describing how=20 > circuit-switched > >> PSAPs can handle VoIP calls. In many cases, PSAPs making the > >> transition from circuit-switched interfaces to packet-switched > >> interfaces may be able to use some of the mechanisms=20 > described here, > >> in combination with gateways that translate packet-switched calls > >> into legacy interfaces, e.g., to continue to be able to=20 > use existing > >> call taker equipment. There are many legacy telephone=20 > networks that > >> will persist long after most systems have been upgraded to IP > >> origination and termination of emergency calls. Many of=20 > these legacy > >> systems route calls based on telephone numbers. Gateways and > >> conversions between existing systems and newer systems defined by > >> this document will be required. Since existing systems=20 > are governed > >> primarily by local government regulations and national=20 > standards, the > >> gateway and conversion details will be governed by=20 > national standards > >> and thus are out of scope for this document. > >=20 > > The real contrast being made is between circuit-switched=20 > and Internet > > model, but the terms used mix "packet-switched",=20 > "IP-based", and "Internet"; > > there is even an explicit mention of EV-DO, but in a mode=20 > that treats > > it as a pure IP bearer (which is not what is being sold in=20 > most markets > > today). The reality on the ground today is that there are at least > > circuit-switched, > > Internet model IP, and IP with operator services out there=20 > in the real > > world. This document set doesn't acknowledge that, and it=20 > treats all > > packet-switched services/IP-based services as if they were=20 > Internet model. > > That's simply not true. > >=20 > > The argument that Steven and others have made is that the=20 > document set > > needs to have an explicit acknowledgement of the other=20 > model, so that > > there is a realization by those reading them that just=20 > because they have > > IP, doesn't mean they are dealing with the Internet model. =20 > You could > > argue that everyone knows that, but the document itself muddies it > > far enough that it is far from evident. > >=20 > > Do I, personally believe the Internet model version is=20 > better? Yep. Do > > I, personally believe that it will eventually subsume other=20 > versions? Maybe, > > and I think it would be nice. But I also recognize that it=20 > is not the case > > now, > > and we're trying to define a system that will actually=20 > work to deliver > > emergency > > calls in the real world. Explicit acknowledgement seems to=20 > me valuable > > in that case. The other option is to re-write the=20 > documents to clarify that > > not any packet-switched network nor any network using IP=20 > fits this set > > of assumptions; that seems to me likely to take longer and=20 > not add much. > >=20 > > You've already had Keith note that he would object to the=20 > documents if > > they did not contain language like that which was in -09. =20 > If it is taken out, > > I believe the documents will need a major editing pass to=20 > accomplish the > > clarification without the explicit text. This text is a=20 > compromise already, > > and the issue it deals with is important. Unless we are=20 > going to pretend > > that the IMS model simply doesn't exist and won't be used=20 > to deliver a > > substantial fraction of emergency calls for a good long=20 > time to come, > > we need it. If we are going to pretend that, I think we=20 > are being very > > foolish > > indeed. > >=20 > > Ted > >=20 > >=20 > >=20 > >> Having to change the way the device initiates an emergency=20 > call when > >> something as prosaic as the access technology changes is=20 > akin to having to > >> change your web browser just because the access technology=20 > has changed. It's > >> neither helpful nor harmless to have such a restriction. > >>=20 > >> A helpful statement to put in the BCP might be "Other=20 > architectures, such as > >> IMS Emergency calling defined by 3GPP and 3GPP2, which are=20 > not based on the > >> ECRIT framework are likely to not be compatible with=20 > devices and emergency > >> networks which assume this framework - e.g. such as is=20 > defined by NENA as > >> i3." > >>=20 > >> I don't endorse the inclusion of such a statement; it's=20 > commentary - as is > >> the proposed "applicability statement" and commentary is=20 > unnecessary. > >> Nevertheless, I think it's a more accurate=20 > characterization. That is, it's > >> more the case that the 3GPP IMS emergency architecture=20 > doesn't fit ECRIT than > >> it is that ECRIT doesn't fit a 3GPP access network. > >>=20 > >> Cheers, > >> Martin > >>=20 > >>=20 > >> From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf Of > >> Edge, Stephen > >> Sent: Friday, 1 May 2009 2:29 AM > >> To: Bernard Aboba; Thomson, Martin; ecrit@ietf.org > >> Subject: Re: [Ecrit] PhoneBCP > >>=20 > >> Bernard and others > >>=20 > >> This is an interesting view - an admission that the Ecrit=20 > solution will > >> probably not be universally applied and when it is may be=20 > subject to > >> modification. On the 3GPP/3GPP2 sides, solutions are=20 > defined with a specific > >> and explicit scope and are expected to be - and nearly=20 > always actually are - > >> supported exactly as defined in the appropriate spec.s for=20 > all scenarios > >> covered by the scope. A solution whose deployment is=20 > unpredictable will be > >> less useful because of the implied interworking problems=20 > between incompatible > >> implementations. That is a main reason why I and others=20 > initially tried to > >> include a more precise applicability/scope statement than=20 > the one we are now > >> discussing. Specifically, the Ecrit solution will probably=20 > not be deployed by > >> 3GPP/3GPP2 operators for cellular terminals because they=20 > have defined a > >> somewhat different solution more suitable for cellular=20 > operation. That means > >> that a terminal supporting only the Ecrit solution (based=20 > on an assertion of > >> universal ap > > plicability) will encounter problems when its user=20 > attempts an emergency call > > on a 3GPP/3GPP2 network. If I can extend your analogies,=20 > this would be like > > not including a precise menu description for a meal=20 > containing meat and/or > > fish in a restaurant catering to both vegetarians and=20 > non-vegetarians. > >>=20 > >> Kind Regards > >>=20 > >> Stephen > >>=20 > >> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > >> Sent: Thursday, April 30, 2009 1:13 AM > >> To: Edge, Stephen; martin.thomson@andrew.com; ecrit@ietf.org > >> Subject: RE: [Ecrit] PhoneBCP > >>=20 > >>> Your interpretation of applicability is certainly extreme=20 > (yes or qualified > >>> yes to all questions) - removing any dependence on suitability or > >>> feasibility (which are the more normal benchmarks) and=20 > simply making a > >>> legalistic blanket assertion. (I can now more understand=20 > incidentally why > >>> the fictitious protocol police are so often invoked on matters of > >>> conformance.) > >>>=20 > >>> But do others have any views on this? > >>=20 > >> Here is my 2 pence. As noted in the Introduction, the=20 > Phone BCP document > >> and framework documents are closely related documents that=20 > need to be read > >> (and understood) together. In looking at Phone BCP, there=20 > have been many > >> situations in which I wondered what the justification was=20 > for a requirement, > >> only to find the (usually persuasive) explanation in the=20 > corresponding > >> section of the framework document. > >>=20 > >> IMHO, the separation of the two documents is somewhat=20 > unnatural. It's a bit > >> like taking a meal, freeze drying it, and then presenting=20 > the diner with a > >> cup of powder and a cup of water and wondering why they=20 > are left with a > >> quizical look on their faces. Including cooking=20 > instructions along with the > >> two cups is not a fully satisfactory answer. > >>=20 > >> Given this reality, if there is a need for text explaining=20 > the fundamental > >> assumptions of the architecture, the place for that text=20 > is not in the BCP > >> document, but in the framework document. As has been=20 > noted by others, the > >> entire BCP document is an applicability statement, and=20 > when viewed in that > >> way, the proposed text is not only unnecessary, but=20 > somewhat confusing since > >> required context for the BCP document belongs in the=20 > framework document. If > >> anything more is necesary, it would probably be some=20 > additional instructions > >> for the reader delving into the document set for the first time. > >>=20 > >> Like any IETF effort, the framework and BCP documents will=20 > be evaluated on > >> their own merits. Athough this is an area with a=20 > considerable regulatory > >> component, I see little evidence that the world at large=20 > is so in awe of the > >> IETF that every word will be taken as immutable truth. No=20 > doubt other SDOs > >> will take issue with these documents in whole or in part=20 > and will explain the > >> basis of their assessments and where necessary, their=20 > alternatives. As a > >> result, some portions of the architecture may be adopted,=20 > some portions may > >> be ignored, and others will be revised in an effort to=20 > address the issues > >> encountered and improve their chances for deployment. > >>=20 > >> With respect to this process, the addition of cautionary=20 > text is a bit like > >> the warning labels that we find on consumer products. =20 > While it may be > >> necessary in some legalistic sense, given the expertise of=20 > the individuals > >> assessing these documents, one wonders what the practical=20 > effect will be. > >> Typically these are individuals who already understand=20 > that it is a good idea > >> to double-cup hot coffee. > >>=20 > >>=20 > >>=20 > >>=20 > -------------------------------------------------------------- > --------------- > >> ------------------- > >> This message is for the designated recipient only and may > >> contain privileged, proprietary, or otherwise private information. > >> If you have received it in error, please notify the sender > >> immediately and delete the original. Any unauthorized use of > >> this email is prohibited. > >>=20 > -------------------------------------------------------------- > --------------- > >> ------------------- > >> [mf2] > >>=20 > >> Content-Type: text/plain; name=3D"ATT00001.txt" > >> Content-Description: ATT00001.txt > >> Content-Disposition: attachment; filename=3D"ATT00001.txt"; = size=3D194; > >> creation-date=3D"Thu, 30 Apr 2009 09:49:15 GMT"; > >> modification-date=3D"Thu, 30 Apr 2009 09:49:15 GMT" > >>=20 > >> Attachment converted: Macintosh HD:ATT00001 5257.txt=20 > (TEXT/ttxt) (0040366B) > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From khwolf1@gmail.com Fri May 1 02:36:39 2009 Return-Path: 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 E5B2F3A704E for ; Fri, 1 May 2009 02:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 cYdT3ksjEXUE for ; Fri, 1 May 2009 02:36:39 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 5B5513A6C6C for ; Fri, 1 May 2009 02:35:49 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so2380523qwe.31 for ; Fri, 01 May 2009 02:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VfoVZQ5Qlu0oTqTMXj0bpmpEZPvdEVP9Dz4YM+ZG5Rg=; b=ZfaQyFEftISVBtQGi114fijGfhzupCZg1qOxQdlTk7CDnoEvgB7bLSkc+j89a6skfm OoLgNwA4qtiQ0/zm4yCjeScljCJXJwWoEeHZeE75LeLYpq3zF3yE6GCKTQMDMOEBBRcx 2Mqd6P8LjgtmohcQpY+5pzqFLPJ7RcmXCtr78= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=T5OUCVd34nDxtjQqg69jGVgCtn3/FIsHZDlYShFaUrmtjSxwsER4X5Mjs4Jk7MbiuN teuISs+Qe/uNfpSXsgFbC6q1geJADyF28WGMv1FEqURBopjMsU30eVq4W80aK9dolDh9 TuXdodDXqmMvKr4EPOxF+njUGJXiqix5zZJxs= MIME-Version: 1.0 Received: by 10.220.76.207 with SMTP id d15mr5069694vck.31.1241170632263; Fri, 01 May 2009 02:37:12 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 May 2009 11:37:12 +0200 Message-ID: From: Karl Heinz Wolf To: Marc Linsner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ECRIT Subject: Re: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary-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: , X-List-Received-Date: Fri, 01 May 2009 09:36:40 -0000 for completeness in this threat Henning's comment: http://www.ietf.org/mail-archive/web/ecrit/current/msg06117.html On Fri, Apr 24, 2009 at 8:36 PM, Marc Linsner wrote: > All, > > Please review this draft to and respond by Friday May 1 if you find this > valuable for ECRIT to work on. > > Thanks, > > -Marc- > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > From drage@alcatel-lucent.com Fri May 1 05:47:04 2009 Return-Path: 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 00E8A3A6E3C for ; Fri, 1 May 2009 05:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.956 X-Spam-Level: X-Spam-Status: No, score=-5.956 tagged_above=-999 required=5 tests=[AWL=0.293, 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 JDOVMJiSfbkG for ; Fri, 1 May 2009 05:47:02 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 6FA173A6845 for ; Fri, 1 May 2009 05:47:02 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n41Cm1Q7010802 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 1 May 2009 14:48:03 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 1 May 2009 14:48:01 +0200 From: "DRAGE, Keith (Keith)" To: "Winterbottom, James" , Brian Rosen , Richard Barnes , Ted Hardie Date: Fri, 1 May 2009 14:48:00 +0200 Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnFTimNAHgqVpUYQG+aUwBx8n7MqwANNc3nABM9GjAACDpT8gBHiFLgALoywPAAGKyc4A== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D675955657@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net> <28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 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: , X-List-Received-Date: Fri, 01 May 2009 12:47:04 -0000 That question has not been put to the list yet, but it has to be before it = goes to publication request.=20 I believe the statement helps the reading community understand the context = in which the document is used, versus other solutions. It is therefore help= ful to our end customers. I agree the wording could probably be better, but it was drafted in a spiri= t of trying to find some middle ground. You don't seem to be prepared to en= ter the middle ground. Well two of us can adopt intransient positions. In my view you haven't just= ified yours. I therefore don't need to justify mine further. Keith=20 > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 > Sent: Friday, May 01, 2009 2:10 AM > To: DRAGE, Keith (Keith); Brian Rosen; Richard Barnes; Ted Hardie > Cc: ECRIT > Subject: RE: [Ecrit] PhoneBCP >=20 > Hi Keith, >=20 > So you are saying that you will object to the document=20 > leaving the WG unless the statement is included, on the=20 > grounds that there have been discussions about what the=20 > statement should say? This is despite the fact that no=20 > consensus was ever reached to include the statement in the=20 > first place. >=20 > I believe that other than this debate these documents are=20 > good to go, and that once this hum is completed the consensus=20 > will be reached and the documents can leave the WG. >=20 > Cheers > James >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Monday, 27 April 2009 6:08 PM > To: Winterbottom, James; Brian Rosen; Richard Barnes; Ted Hardie > Cc: ECRIT > Subject: RE: [Ecrit] PhoneBCP >=20 > I hum for the applicability statement. >=20 > I would also note that if we go the way you want to go, we=20 > have a hum for whether the document is acceptable without=20 > this. Having had the discussion to agree an applicability=20 > statement, I warn that I will hum against a document without it. >=20 > You need some form of consensus to get the document out of the WG. >=20 > regards >=20 > Keith=20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Winterbottom, James > > Sent: Saturday, April 25, 2009 10:58 PM > > To: Brian Rosen; Richard Barnes; Ted Hardie > > Cc: ECRIT > > Subject: Re: [Ecrit] PhoneBCP > >=20 > > My point is that because there was no consensus at the=20 > IETF, in fact=20 > > the document should have remained unchanged. > >=20 > > I want a hum first as to whether the applicability statement is=20 > > required at all. As I have stated more then one I don't=20 > believe it is,=20 > > and no reasonable argument has yet been provided to changed my mind. > >=20 > > So let us first establish with a clear consensus that the=20 > > applicability statement is required. > >=20 > > I HUM against the inclusion of an applicability statement. > >=20 > >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Sat 4/25/2009 1:04 PM > > To: Winterbottom, James; 'Richard Barnes'; 'Ted Hardie' > > Cc: 'ECRIT' > > Subject: RE: [Ecrit] PhoneBCP > > =20 > > Actually, I think the list hum is whether or not you accept the=20 > > change, as proposed, and consider the document ready to send to the=20 > > IESG. It's kind of a combination of is an applicability statement=20 > > acceptable, and is this particular one acceptable (and are you=20 > > otherwise okay with the document, which is implied in=20 > Marc's message,=20 > > but I think important to recognize). > >=20 > > Brian > >=20 > >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Winterbottom, James > > Sent: Saturday, April 25, 2009 4:51 AM > > To: Richard Barnes; Ted Hardie > > Cc: ECRIT > > Subject: Re: [Ecrit] PhoneBCP > >=20 > > So is this turning into a list "hum" as to whether we=20 > should have an=20 > > applicability statement or not? > >=20 > > ISTM that this would be an appropriate course of action=20 > given the lack=20 > > on consensus at the actually meeting. > >=20 > >=20 > > Cheers > > James > >=20 > >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org on behalf of Richard Barnes > > Sent: Fri 4/24/2009 9:32 PM > > To: Ted Hardie > > Cc: ECRIT > > Subject: Re: [Ecrit] PhoneBCP > > =20 > > +1 > >=20 > >=20 > > Ted Hardie wrote: > > > At 11:23 AM -0700 4/24/09, Marc Linsner wrote: > > >> > > > -09.txt>http:/ > > /www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt > > >> > > >> At the San Francisco meeting and ensuing list threads, the > > last issue > > around PhoneBCP was whether or not to include an 'applicability=20 > > statement'. > > The hum during the meeting was inconclusive. The draft editor has=20 > > included text in this latest version in an attempt to compromise on=20 > > this issue. > > >> > > >> Please review this version and respond by Friday May 1 to > > the list as > > >> to > > your acceptance of this change. > > >> > > >> Thanks, > > >> > > >> Marc, Hannes, & Roger > > >=20 > > > I support the current draft going forward to publication=20 > requested. > > >=20 > > > regards, > > > Ted > > >=20 > > >=20 > > >=20 > > >> Content-Type: text/plain; name=3D"ATT00001.txt" > > >> Content-Description: ATT00001.txt > > >> Content-Disposition: attachment;=20 > filename=3D"ATT00001.txt"; size=3D194; > > >> creation-date=3D"Fri, 24 Apr 2009 11:24:11 GMT"; > > >> modification-date=3D"Fri, 24 Apr 2009 11:24:11 GMT" > > >> > > >> Attachment converted: Macintosh HD:ATT00001 5171.txt (TEXT/ttxt) > > (003FF52C) > > >=20 > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 > > -------------------------------------------------------------- > > -------------- > > -------------------- > > This message is for the designated recipient only and may contain=20 > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender=20 > immediately=20 > > and delete the original. Any unauthorized use of this email is=20 > > prohibited. > > -------------------------------------------------------------- > > -------------- > > -------------------- > > [mf2] > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 > >=20 > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may contain=20 > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender=20 > immediately=20 > > and delete the original. Any unauthorized use of this email is=20 > > prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may=20 > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender=20 > immediately and delete the original. Any unauthorized use of=20 > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 > = From fluffy@cisco.com Fri May 1 05:48:42 2009 Return-Path: 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 B5AAE3A68C9 for ; Fri, 1 May 2009 05:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 35grQCrNNxdm for ; Fri, 1 May 2009 05:48:41 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id CFD523A6FDF for ; Fri, 1 May 2009 05:48:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,278,1238976000"; d="scan'208";a="158237711" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 01 May 2009 12:50:05 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n41Co5Wm017147; Fri, 1 May 2009 05:50:05 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n41Co4wx029071; Fri, 1 May 2009 12:50:05 GMT From: Cullen Jennings To: "Stark, Barbara" In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0E046C52@crexc41p> Impp: xmpp:cullenfluffyjennings@jabber.org References: <7582BC68E4994F4ABF0BD4723975C3FA0E046C52@crexc41p> Message-Id: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 1 May 2009 06:50:04 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1260; t=1241182205; x=1242046205; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Ecrit]=20PhoneBCP |Sender:=20; bh=bcBIcWeBPsiDcZ1IFIQ0h9OajdbxDRsR64jPbbUnl+A=; b=DIDp972PG4DwwIgyMC4vWJskuudG5I3L9zCCARWWSU/DgTo5KeJPBUuebz 6rrdLgfq3ori3vsMcZdXXkxqLpT8vGK+D4+ZYi3NKNHpYt9UlVdqJjr04Gj+ 6Dv6lgBI+t; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 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: , X-List-Received-Date: Fri, 01 May 2009 12:48:42 -0000 On Apr 24, 2009, at 12:43 PM, Stark, Barbara wrote: > I assume you=92re referring to the following paragraph in the =20 > introduction: > =93 This document focuses on the case in which all three steps in = the > emergency calling process -- location configuration, call routing, > and call placement - can be and are performed by the calling > endpoint, with the endpoint's Access Service Provider supporting =20= > the > process by providing location information. Calls in this case =20 > may be > routed via an application-layer Communications Service Provider > (e.g., a Voice Service Provider), but need not be. The underlying > protocols can also be used to support other models in which parts =20= > of > the process are delegated to the Communications Service Provider. > This document does not address in detail either these models or > interoperability issues between them and the model described here.=94= > > I've read this text several times and I'm trying to decide if anyone =20 outside this WG could ever decide what it means. Can someone clearly =20 explain all the implications of this paragraph? Particularly the last =20= two sentences. Thanks, Cullen in my AD role From br@brianrosen.net Fri May 1 06:06:47 2009 Return-Path: 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 22DB83A6F6A for ; Fri, 1 May 2009 06:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 1n4zqqsnnTjL for ; Fri, 1 May 2009 06:06:46 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id C5FA528C17E for ; Fri, 1 May 2009 06:06:35 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LzsT2-0003Hk-Er; Fri, 01 May 2009 08:07:52 -0500 From: "Brian Rosen" To: "'Cullen Jennings'" , "'Stark, Barbara'" References: <7582BC68E4994F4ABF0BD4723975C3FA0E046C52@crexc41p> In-Reply-To: Date: Fri, 1 May 2009 09:07:53 -0400 Message-ID: <086d01c9ca5d$d892d300$89b87900$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnKW1j0z+7QdkDjT/WwWZt61M7eIgAAbt2Q Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] 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: , X-List-Received-Date: Fri, 01 May 2009 13:06:47 -0000 The underlying protocols can support models where the location of the endpoint can be determined by the calling network and/or the calling network can do the routing (LoST lookup or some nation specific routing), and even the marking of the call. --framework and phonebcp don't really discuss that model. An example of that is IMS, which has an element called an E-CSCF that is capable of querying a mobile network's location infrastructure to determine the location of the caller, and can perform any routing tasks appropriate to the location of the caller. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Friday, May 01, 2009 8:50 AM To: Stark, Barbara Cc: ECRIT Subject: Re: [Ecrit] PhoneBCP On Apr 24, 2009, at 12:43 PM, Stark, Barbara wrote: > I assume you're referring to the following paragraph in the > introduction: > " This document focuses on the case in which all three steps in the > emergency calling process -- location configuration, call routing, > and call placement - can be and are performed by the calling > endpoint, with the endpoint's Access Service Provider supporting > the > process by providing location information. Calls in this case > may be > routed via an application-layer Communications Service Provider > (e.g., a Voice Service Provider), but need not be. The underlying > protocols can also be used to support other models in which parts > of > the process are delegated to the Communications Service Provider. > This document does not address in detail either these models or > interoperability issues between them and the model described here." > > I've read this text several times and I'm trying to decide if anyone outside this WG could ever decide what it means. Can someone clearly explain all the implications of this paragraph? Particularly the last two sentences. Thanks, Cullen in my AD role _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From RMarshall@telecomsys.com Fri May 1 10:38:01 2009 Return-Path: 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 9506C3A6D80 for ; Fri, 1 May 2009 10:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, 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 EenYZY+in8G5 for ; Fri, 1 May 2009 10:38:00 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 266CE3A6CD8 for ; Fri, 1 May 2009 10:38:00 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 1 May 2009 10:39:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 10:38:42 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750CB9A0B2@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <086d01c9ca5d$d892d300$89b87900$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnKW1j0z+7QdkDjT/WwWZt61M7eIgAAbt2QAAj1jBA= References: <7582BC68E4994F4ABF0BD4723975C3FA0E046C52@crexc41p> <086d01c9ca5d$d892d300$89b87900$@net> From: "Roger Marshall" To: "Brian Rosen" , "Cullen Jennings" , "Stark, Barbara" 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: , X-List-Received-Date: Fri, 01 May 2009 17:38:01 -0000 And I'd say, that for a while yet, these other types of call routing architectures are going to be in vogue, because of the following constraints: -- a mobile context - a device w/o a location at the time that an emergency request is made, does shouldn't hold up the call. -- a rough vs. precise location routing decision at the edge is assumed (yet this isn't too worked out for edge devices). -- location determination takes time based on today's available real-time location technology. Therefore, the (mobile) edge device either: 1. waits for a location to be determined before edge routing, 2. acquires a placeholder (in the form of a location URI), and routes based on pre-provisioned rules to a core element which either "has" or "gets" a LO, or 3. (in classic 3GPP style) the endpoint call routing occurs immediately based on pre-provisioned routing rules, lands at a core element which can do immediate (rough) or eventual (precise) routing to parts beyond. I am ok with the applicability statement being left in. -roger marshall. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Friday, May 01, 2009 6:08 AM > To: 'Cullen Jennings'; 'Stark, Barbara' > Cc: 'ECRIT' > Subject: Re: [Ecrit] PhoneBCP >=20 > The underlying protocols can support models where the location of the > endpoint can be determined by the calling network and/or the calling > network > can do the routing (LoST lookup or some nation specific routing), and > even > the marking of the call. --framework and phonebcp don't really discuss > that > model. An example of that is IMS, which has an element called an E- > CSCF > that is capable of querying a mobile network's location infrastructure > to > determine the location of the caller, and can perform any routing tasks > appropriate to the location of the caller. >=20 > Brian >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > Cullen Jennings > Sent: Friday, May 01, 2009 8:50 AM > To: Stark, Barbara > Cc: ECRIT > Subject: Re: [Ecrit] PhoneBCP >=20 >=20 > On Apr 24, 2009, at 12:43 PM, Stark, Barbara wrote: >=20 > > I assume you're referring to the following paragraph in the > > introduction: > > " This document focuses on the case in which all three steps in the > > emergency calling process -- location configuration, call routing, > > and call placement - can be and are performed by the calling > > endpoint, with the endpoint's Access Service Provider supporting > > the > > process by providing location information. Calls in this case > > may be > > routed via an application-layer Communications Service Provider > > (e.g., a Voice Service Provider), but need not be. The underlying > > protocols can also be used to support other models in which parts > > of > > the process are delegated to the Communications Service Provider. > > This document does not address in detail either these models or > > interoperability issues between them and the model described > here." > > > > >=20 > I've read this text several times and I'm trying to decide if anyone > outside this WG could ever decide what it means. Can someone clearly > explain all the implications of this paragraph? Particularly the last > two sentences. >=20 > Thanks, Cullen in my AD role >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. From br@brianrosen.net Sat May 2 19:19:49 2009 Return-Path: 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 27DCF3A6837 for ; Sat, 2 May 2009 19:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 LrVGTQ24ki3G for ; Sat, 2 May 2009 19:19:48 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 2B2B83A682F for ; Sat, 2 May 2009 19:19:48 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1M0RK5-0008L1-PH; Sat, 02 May 2009 21:20:58 -0500 From: "Brian Rosen" To: "'Roger Marshall'" , "'Cullen Jennings'" , "'Stark, Barbara'" References: <7582BC68E4994F4ABF0BD4723975C3FA0E046C52@crexc41p> <086d01c9ca5d$d892d300$89b87900$@net> <8C837214C95C864C9F34F3635C2A65750CB9A0B2@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750CB9A0B2@SEA-EXCHVS-2.telecomsys.com> Date: Sat, 2 May 2009 22:21:08 -0400 Message-ID: <0b0401c9cb95$d3811eb0$7a835c10$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnKW1j0z+7QdkDjT/WwWZt61M7eIgAAbt2QAAj1jBAARR2/AA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] 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: , X-List-Received-Date: Sun, 03 May 2009 02:19:49 -0000 Without prejudice to the hum, I believe these are covered by the phonebcp architecture: 1. The phone will get a location URI from its LIS 2. If a routing location is requested by dereferencing the location URI, it will get an immediate response which equates to cell/sector location 3. When dispatch location is requested, the actual (precise) location will be returned Brian -----Original Message----- From: Roger Marshall [mailto:RMarshall@telecomsys.com] Sent: Friday, May 01, 2009 1:39 PM To: Brian Rosen; Cullen Jennings; Stark, Barbara Cc: ECRIT Subject: RE: [Ecrit] PhoneBCP And I'd say, that for a while yet, these other types of call routing architectures are going to be in vogue, because of the following constraints: -- a mobile context - a device w/o a location at the time that an emergency request is made, does shouldn't hold up the call. -- a rough vs. precise location routing decision at the edge is assumed (yet this isn't too worked out for edge devices). -- location determination takes time based on today's available real-time location technology. Therefore, the (mobile) edge device either: 1. waits for a location to be determined before edge routing, 2. acquires a placeholder (in the form of a location URI), and routes based on pre-provisioned rules to a core element which either "has" or "gets" a LO, or 3. (in classic 3GPP style) the endpoint call routing occurs immediately based on pre-provisioned routing rules, lands at a core element which can do immediate (rough) or eventual (precise) routing to parts beyond. I am ok with the applicability statement being left in. -roger marshall. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Friday, May 01, 2009 6:08 AM > To: 'Cullen Jennings'; 'Stark, Barbara' > Cc: 'ECRIT' > Subject: Re: [Ecrit] PhoneBCP > > The underlying protocols can support models where the location of the > endpoint can be determined by the calling network and/or the calling > network > can do the routing (LoST lookup or some nation specific routing), and > even > the marking of the call. --framework and phonebcp don't really discuss > that > model. An example of that is IMS, which has an element called an E- > CSCF > that is capable of querying a mobile network's location infrastructure > to > determine the location of the caller, and can perform any routing tasks > appropriate to the location of the caller. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > Cullen Jennings > Sent: Friday, May 01, 2009 8:50 AM > To: Stark, Barbara > Cc: ECRIT > Subject: Re: [Ecrit] PhoneBCP > > > On Apr 24, 2009, at 12:43 PM, Stark, Barbara wrote: > > > I assume you're referring to the following paragraph in the > > introduction: > > " This document focuses on the case in which all three steps in the > > emergency calling process -- location configuration, call routing, > > and call placement - can be and are performed by the calling > > endpoint, with the endpoint's Access Service Provider supporting > > the > > process by providing location information. Calls in this case > > may be > > routed via an application-layer Communications Service Provider > > (e.g., a Voice Service Provider), but need not be. The underlying > > protocols can also be used to support other models in which parts > > of > > the process are delegated to the Communications Service Provider. > > This document does not address in detail either these models or > > interoperability issues between them and the model described > here." > > > > > > I've read this text several times and I'm trying to decide if anyone > outside this WG could ever decide what it means. Can someone clearly > explain all the implications of this paragraph? Particularly the last > two sentences. > > Thanks, Cullen in my AD role > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. From RMarshall@telecomsys.com Mon May 4 09:22:46 2009 Return-Path: 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 48D3728C134 for ; Mon, 4 May 2009 09:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, 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 yIAGIhoxSav6 for ; Mon, 4 May 2009 09:22:45 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 28E6C28C128 for ; Mon, 4 May 2009 09:22:45 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Mon, 4 May 2009 09:24:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 09:23:59 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750CB9A630@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <0b0401c9cb95$d3811eb0$7a835c10$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnKW1j0z+7QdkDjT/WwWZt61M7eIgAAbt2QAAj1jBAARR2/AABPhvPw References: <7582BC68E4994F4ABF0BD4723975C3FA0E046C52@crexc41p> <086d01c9ca5d$d892d300$89b87900$@net> <8C837214C95C864C9F34F3635C2A65750CB9A0B2@SEA-EXCHVS-2.telecomsys.com> <0b0401c9cb95$d3811eb0$7a835c10$@net> From: "Roger Marshall" To: "Brian Rosen" , "Cullen Jennings" , "Stark, Barbara" 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: , X-List-Received-Date: Mon, 04 May 2009 16:22:46 -0000 Only the first of three scenarios are covered by Phonebcp/Framework. The second and third, > 2. acquires a placeholder (in the form of a location URI), and > routes based on pre-provisioned rules to a core element which either > "has" or "gets" a LO, or > 3. (in classic 3GPP style) the endpoint call routing occurs > immediately based on pre-provisioned routing rules, lands at a core > element which can do immediate (rough) or eventual (precise) routing to > parts beyond. ...are not covered. These rely on other key material (dial string analysis) and pre-set rules to get the call moving into the core. At the edge, there is no location based routing at all. 3GPP would have to change their call architecture to include a location URI, and then do edge routing, in order to truly be Phonebcp/Framework compliant. -roger. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Saturday, May 02, 2009 7:21 PM > To: Roger Marshall; 'Cullen Jennings'; 'Stark, Barbara' > Cc: 'ECRIT' > Subject: RE: [Ecrit] PhoneBCP >=20 > Without prejudice to the hum, I believe these are covered by the > phonebcp > architecture: > 1. The phone will get a location URI from its LIS > 2. If a routing location is requested by dereferencing the location > URI, it > will get an immediate response which equates to cell/sector location > 3. When dispatch location is requested, the actual (precise) location > will > be returned >=20 > Brian >=20 > -----Original Message----- > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > Sent: Friday, May 01, 2009 1:39 PM > To: Brian Rosen; Cullen Jennings; Stark, Barbara > Cc: ECRIT > Subject: RE: [Ecrit] PhoneBCP >=20 > And I'd say, that for a while yet, these other types of call routing > architectures are going to be in vogue, because of the following > constraints: >=20 > -- a mobile context - a device w/o a location at the time that an > emergency request is made, does shouldn't hold up the call. > -- a rough vs. precise location routing decision at the edge is assumed > (yet this isn't too worked out for edge devices). > -- location determination takes time based on today's available > real-time location technology. >=20 > Therefore, the (mobile) edge device either: >=20 > 1. waits for a location to be determined before edge routing, > 2. acquires a placeholder (in the form of a location URI), and > routes based on pre-provisioned rules to a core element which either > "has" or "gets" a LO, or > 3. (in classic 3GPP style) the endpoint call routing occurs > immediately based on pre-provisioned routing rules, lands at a core > element which can do immediate (rough) or eventual (precise) routing to > parts beyond. >=20 > I am ok with the applicability statement being left in. >=20 > -roger marshall. >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > Of Brian Rosen > > Sent: Friday, May 01, 2009 6:08 AM > > To: 'Cullen Jennings'; 'Stark, Barbara' > > Cc: 'ECRIT' > > Subject: Re: [Ecrit] PhoneBCP > > > > The underlying protocols can support models where the location of the > > endpoint can be determined by the calling network and/or the calling > > network > > can do the routing (LoST lookup or some nation specific routing), and > > even > > the marking of the call. --framework and phonebcp don't really > discuss > > that > > model. An example of that is IMS, which has an element called an E- > > CSCF > > that is capable of querying a mobile network's location > infrastructure > > to > > determine the location of the caller, and can perform any routing > tasks > > appropriate to the location of the caller. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > Of > > Cullen Jennings > > Sent: Friday, May 01, 2009 8:50 AM > > To: Stark, Barbara > > Cc: ECRIT > > Subject: Re: [Ecrit] PhoneBCP > > > > > > On Apr 24, 2009, at 12:43 PM, Stark, Barbara wrote: > > > > > I assume you're referring to the following paragraph in the > > > introduction: > > > " This document focuses on the case in which all three steps in > the > > > emergency calling process -- location configuration, call > routing, > > > and call placement - can be and are performed by the calling > > > endpoint, with the endpoint's Access Service Provider supporting > > > the > > > process by providing location information. Calls in this case > > > may be > > > routed via an application-layer Communications Service Provider > > > (e.g., a Voice Service Provider), but need not be. The > underlying > > > protocols can also be used to support other models in which > parts > > > of > > > the process are delegated to the Communications Service > Provider. > > > This document does not address in detail either these models or > > > interoperability issues between them and the model described > > here." > > > > > > > > > > I've read this text several times and I'm trying to decide if anyone > > outside this WG could ever decide what it means. Can someone clearly > > explain all the implications of this paragraph? Particularly the last > > two sentences. > > > > Thanks, Cullen in my AD role > > > > _______________________________________________ > > 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 >=20 > CONFIDENTIALITY NOTICE: The information contained in this message may > be > privileged and/or confidential. If you are not the intended recipient, > or > responsible for delivering this message to the intended recipient, any > review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, > and > delete it and all attachments from your computer and network. From br@brianrosen.net Mon May 4 09:44:39 2009 Return-Path: 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 EE19B28C1A5 for ; Mon, 4 May 2009 09:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 oBuY3qjdbNBj for ; Mon, 4 May 2009 09:44:38 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id ABE6928C15F for ; Mon, 4 May 2009 09:44:38 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1M11Ig-0004ve-FP; Mon, 04 May 2009 11:45:55 -0500 From: "Brian Rosen" To: "'Roger Marshall'" , "'Cullen Jennings'" , "'Stark, Barbara'" References: <7582BC68E4994F4ABF0BD4723975C3FA0E046C52@crexc41p> <086d01c9ca5d$d892d300$89b87900$@net> <8C837214C95C864C9F34F3635C2A65750CB9A0B2@SEA-EXCHVS-2.telecomsys.com> <0b0401c9cb95$d3811eb0$7a835c10$@net> <8C837214C95C864C9F34F3635C2A65750CB9A630@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750CB9A630@SEA-EXCHVS-2.telecomsys.com> Date: Mon, 4 May 2009 12:45:57 -0400 Message-ID: <0db201c9ccd7$ce612e00$6b238a00$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnKW1j0z+7QdkDjT/WwWZt61M7eIgAAbt2QAAj1jBAARR2/AABPhvPwAACQHtA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] 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: , X-List-Received-Date: Mon, 04 May 2009 16:44:40 -0000 You described three constraints: > -- a mobile context - a device w/o a location at the time that an > emergency request is made, does shouldn't hold up the call. > -- a rough vs. precise location routing decision at the edge is assumed > (yet this isn't too worked out for edge devices). > -- location determination takes time based on today's available > real-time location technology. -framework and -phonebcp are designed to deal with those constraints, which is what I pointed out. There ARE other ways to do it, which have various problems; the usual one we trot out is the raw packet problem. -framework and -phonebcp only describe the endpoint LCP/route model. It IS a solution to the constraints. It's an excellent solution. It's not the only one. Brian -----Original Message----- From: Roger Marshall [mailto:RMarshall@telecomsys.com] Sent: Monday, May 04, 2009 12:24 PM To: Brian Rosen; Cullen Jennings; Stark, Barbara Cc: ECRIT Subject: RE: [Ecrit] PhoneBCP Only the first of three scenarios are covered by Phonebcp/Framework. The second and third, > 2. acquires a placeholder (in the form of a location URI), and > routes based on pre-provisioned rules to a core element which either > "has" or "gets" a LO, or > 3. (in classic 3GPP style) the endpoint call routing occurs > immediately based on pre-provisioned routing rules, lands at a core > element which can do immediate (rough) or eventual (precise) routing to > parts beyond. ...are not covered. These rely on other key material (dial string analysis) and pre-set rules to get the call moving into the core. At the edge, there is no location based routing at all. 3GPP would have to change their call architecture to include a location URI, and then do edge routing, in order to truly be Phonebcp/Framework compliant. -roger. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Saturday, May 02, 2009 7:21 PM > To: Roger Marshall; 'Cullen Jennings'; 'Stark, Barbara' > Cc: 'ECRIT' > Subject: RE: [Ecrit] PhoneBCP > > Without prejudice to the hum, I believe these are covered by the > phonebcp > architecture: > 1. The phone will get a location URI from its LIS > 2. If a routing location is requested by dereferencing the location > URI, it > will get an immediate response which equates to cell/sector location > 3. When dispatch location is requested, the actual (precise) location > will > be returned > > Brian > > -----Original Message----- > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > Sent: Friday, May 01, 2009 1:39 PM > To: Brian Rosen; Cullen Jennings; Stark, Barbara > Cc: ECRIT > Subject: RE: [Ecrit] PhoneBCP > > And I'd say, that for a while yet, these other types of call routing > architectures are going to be in vogue, because of the following > constraints: > > -- a mobile context - a device w/o a location at the time that an > emergency request is made, does shouldn't hold up the call. > -- a rough vs. precise location routing decision at the edge is assumed > (yet this isn't too worked out for edge devices). > -- location determination takes time based on today's available > real-time location technology. > > Therefore, the (mobile) edge device either: > > 1. waits for a location to be determined before edge routing, > 2. acquires a placeholder (in the form of a location URI), and > routes based on pre-provisioned rules to a core element which either > "has" or "gets" a LO, or > 3. (in classic 3GPP style) the endpoint call routing occurs > immediately based on pre-provisioned routing rules, lands at a core > element which can do immediate (rough) or eventual (precise) routing to > parts beyond. > > I am ok with the applicability statement being left in. > > -roger marshall. > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > Of Brian Rosen > > Sent: Friday, May 01, 2009 6:08 AM > > To: 'Cullen Jennings'; 'Stark, Barbara' > > Cc: 'ECRIT' > > Subject: Re: [Ecrit] PhoneBCP > > > > The underlying protocols can support models where the location of the > > endpoint can be determined by the calling network and/or the calling > > network > > can do the routing (LoST lookup or some nation specific routing), and > > even > > the marking of the call. --framework and phonebcp don't really > discuss > > that > > model. An example of that is IMS, which has an element called an E- > > CSCF > > that is capable of querying a mobile network's location > infrastructure > > to > > determine the location of the caller, and can perform any routing > tasks > > appropriate to the location of the caller. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > Of > > Cullen Jennings > > Sent: Friday, May 01, 2009 8:50 AM > > To: Stark, Barbara > > Cc: ECRIT > > Subject: Re: [Ecrit] PhoneBCP > > > > > > On Apr 24, 2009, at 12:43 PM, Stark, Barbara wrote: > > > > > I assume you're referring to the following paragraph in the > > > introduction: > > > " This document focuses on the case in which all three steps in > the > > > emergency calling process -- location configuration, call > routing, > > > and call placement - can be and are performed by the calling > > > endpoint, with the endpoint's Access Service Provider supporting > > > the > > > process by providing location information. Calls in this case > > > may be > > > routed via an application-layer Communications Service Provider > > > (e.g., a Voice Service Provider), but need not be. The > underlying > > > protocols can also be used to support other models in which > parts > > > of > > > the process are delegated to the Communications Service > Provider. > > > This document does not address in detail either these models or > > > interoperability issues between them and the model described > > here." > > > > > > > > > > I've read this text several times and I'm trying to decide if anyone > > outside this WG could ever decide what it means. Can someone clearly > > explain all the implications of this paragraph? Particularly the last > > two sentences. > > > > Thanks, Cullen in my AD role > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > CONFIDENTIALITY NOTICE: The information contained in this message may > be > privileged and/or confidential. If you are not the intended recipient, > or > responsible for delivering this message to the intended recipient, any > review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, > and > delete it and all attachments from your computer and network. From bs7652@att.com Mon May 4 13:41:33 2009 Return-Path: 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 1983C3A68A0 for ; Mon, 4 May 2009 13:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.969 X-Spam-Level: X-Spam-Status: No, score=-104.969 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_20=-0.74, 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 doWRQslBzNdF for ; Mon, 4 May 2009 13:41:32 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 3A7FB3A7135 for ; Mon, 4 May 2009 13:41:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-14.tower-129.messagelabs.com!1241469776!15211590!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 25419 invoked from network); 4 May 2009 20:42:57 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-14.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2009 20:42:57 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n44KgukV021587 for ; Mon, 4 May 2009 16:42:56 -0400 Received: from 01GAF5142010625.AD.BLS.COM (01GAF5142010625.ad.bls.com [139.76.131.31]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n44KgoNQ021440 for ; Mon, 4 May 2009 16:42:51 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 4 May 2009 16:42:50 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 4 May 2009 16:42:50 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 16:42:44 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0E1E734A@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP -- are we there yet? thread-index: AcnKW1j0z+7QdkDjT/WwWZt61M7eIgAAbt2QAAj1jBAARR2/AABPhvPwAAhwkYAAAL9YkA== References: <7582BC68E4994F4ABF0BD4723975C3FA0E046C52@crexc41p><086d01c9ca5d$d892d300$89b87900$@net><8C837214C95C864C9F34F3635C2A65750CB9A0B2@SEA-EXCHVS-2.telecomsys.com><0b0401c9cb95$d3811eb0$7a835c10$@net> <8C837214C95C864C9F34F3635C2A65750CB9A630@SEA-EXCHVS-2.telecomsys.com> From: "Stark, Barbara" To: "ECRIT" X-OriginalArrivalTime: 04 May 2009 20:42:50.0258 (UTC) FILETIME=[E3CCDF20:01C9CCF8] Subject: Re: [Ecrit] PhoneBCP -- are we there yet? 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: , X-List-Received-Date: Mon, 04 May 2009 20:41:33 -0000 Is this hum over yet? Marc, you said Friday, May 1. Have the results been tabulated? Will we be having another hum, then, as to whether phonebcp is good to go? Inquiring minds want to know. Barbara ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA625 From Martin.Dawson@andrew.com Mon May 4 13:46:39 2009 Return-Path: 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 7A4213A69B4 for ; Mon, 4 May 2009 13:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.155 X-Spam-Level: X-Spam-Status: No, score=-1.155 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 gnBjBUMogtuo for ; Mon, 4 May 2009 13:46:38 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id E9F4428C232 for ; Mon, 4 May 2009 13:46:06 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_05_04_15_52_23 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 04 May 2009 15:52:23 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 15:31:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 15:31:26 -0500 Message-ID: In-Reply-To: <8C837214C95C864C9F34F3635C2A65750CB9A630@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnKW1j0z+7QdkDjT/WwWZt61M7eIgAAbt2QAAj1jBAARR2/AABPhvPwAAhwkYA= References: <7582BC68E4994F4ABF0BD4723975C3FA0E046C52@crexc41p><086d01c9ca5d$d892d300$89b87900$@net><8C837214C95C864C9F34F3635C2A65750CB9A0B2@SEA-EXCHVS-2.telecomsys.com><0b0401c9cb95$d3811eb0$7a835c10$@net> <8C837214C95C864C9F34F3635C2A65750CB9A630@SEA-EXCHVS-2.telecomsys.com> From: "Dawson, Martin" To: "Roger Marshall" , "Brian Rosen" , "Cullen Jennings" , "Stark, Barbara" X-OriginalArrivalTime: 04 May 2009 20:31:29.0801 (UTC) FILETIME=[4E375F90:01C9CCF7] 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: , X-List-Received-Date: Mon, 04 May 2009 20:46:39 -0000 Actually I think the words mask the reality. If there's a routing=0D=0Adeci= sion to be made, then location adequate for routing has to be=0D=0Adetermin= ed. And it doesn't matter if the location is represented as a=0D=0Acell-ide= ntity (a dangerous assumption where reliable routing in a US=0D=0Acontext i= s concerned); it's still a logical location. There's no magic:=0D=0A=0D=0A>= -- a mobile context - a device w/o a location at the time that an=0D=0A> e= mergency request is made, does shouldn't hold up the call.=0D=0A=0D=0AAn in= itial location has to be determined. The device gets it or the=0D=0Anetwork= gets it. There's no definitive basis for assuming one approach=0D=0Ais sup= erior to another. As Brian says, PhoneBCP says it's coarse request=0D=0A(su= b-second latency in any type of public access technology is a=0D=0Areasonab= le expectation) plus Location-URI for later dispatch-accuracte=0D=0Alocatio= n determination.=0D=0A=0D=0A> -- a rough vs. precise location routing decis= ion at the edge is=0D=0A> assumed=0D=0A=0D=0AYou can't "assume" a locati= on. It still has to be based on some sort of=0D=0Alogic. Even if you deploy= ed E-CSCF at a PSAP routing granularity (I'm=0D=0Asure that'd be popular), = then the E-CSCF discovery step becomes your=0D=0Arouting question and you'r= e back where you started. A "pre-provisioned=0D=0Arouting rule" still needs= some sort of location determination. For that=0D=0Amatter, LoST routing ru= les are also "pre-provisioned".=0D=0A=0D=0A> (yet this isn't too worked out= for edge devices).=0D=0A=0D=0AIsn't worked out by who=3F I don't think any= standards forum, no matter=0D=0Ahow much they narrow the scope of their so= lution, can provide a magic=0D=0Adesign for this in a wide area wireless co= ntext. Nearest we've come to=0D=0A"zero wait" routing is POTS via direct LE= C trunks to the selective=0D=0Arouter... and, even then, there's an SR DB d= ip against the logical=0D=0Alocation represented by the ANI before routing = was complete.=0D=0A=0D=0A> -- location determination takes time based on to= day's available=0D=0A> real-time location technology.=0D=0A>=0D=0A=0D=0AEve= rything takes time.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original= Message-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.= org] On Behalf=0D=0AOf Roger Marshall=0D=0ASent: Tuesday, 5 May 2009 2:24 A= M=0D=0ATo: Brian Rosen; Cullen Jennings; Stark, Barbara=0D=0ACc: ECRIT=0D=0A= Subject: Re: [Ecrit] PhoneBCP=0D=0A=0D=0AOnly the first of three scenarios = are covered by Phonebcp/Framework.=0D=0AThe second and third,=0D=0A=0D=0A> = =092. acquires a placeholder (in the form of a location URI), and=0D=0A> ro= utes based on pre-provisioned rules to a core element which either=0D=0A> "= has" or "gets" a LO, or=0D=0A> =093. (in classic 3GPP style) the endpoint c= all routing occurs=0D=0A> immediately based on pre-provisioned routing rule= s, lands at a core=0D=0A> element which can do immediate (rough) or eventua= l (precise) routing=0D=0Ato=0D=0A> parts beyond.=0D=0A=0D=0A...are not cove= red. These rely on other key material (dial string=0D=0Aanalysis) and pre-= set rules to get the call moving into the core. At=0D=0Athe edge, there is= no location based routing at all. 3GPP would have to=0D=0Achange their ca= ll architecture to include a location URI, and then do=0D=0Aedge routing, i= n order to truly be Phonebcp/Framework compliant.=0D=0A=0D=0A-roger.=0D=0A=0D= =0A> -----Original Message-----=0D=0A> From: Brian Rosen [mailto:br@brianro= sen.net]=0D=0A> Sent: Saturday, May 02, 2009 7:21 PM=0D=0A> To: Roger Marsh= all; 'Cullen Jennings'; 'Stark, Barbara'=0D=0A> Cc: 'ECRIT'=0D=0A> Subject:= RE: [Ecrit] PhoneBCP=0D=0A>=20=0D=0A> Without prejudice to the hum, I beli= eve these are covered by the=0D=0A> phonebcp=0D=0A> architecture:=0D=0A> 1.= The phone will get a location URI from its LIS=0D=0A> 2. If a routing loca= tion is requested by dereferencing the location=0D=0A> URI, it=0D=0A> will = get an immediate response which equates to cell/sector location=0D=0A> 3. W= hen dispatch location is requested, the actual (precise) location=0D=0A> wi= ll=0D=0A> be returned=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> -----Original= Message-----=0D=0A> From: Roger Marshall [mailto:RMarshall@telecomsys.com]=0D= =0A> Sent: Friday, May 01, 2009 1:39 PM=0D=0A> To: Brian Rosen; Cullen Jenn= ings; Stark, Barbara=0D=0A> Cc: ECRIT=0D=0A> Subject: RE: [Ecrit] PhoneBCP=0D= =0A>=20=0D=0A> And I'd say, that for a while yet, these other types of call= routing=0D=0A> architectures are going to be in vogue, because of the foll= owing=0D=0A> constraints:=0D=0A>=20=0D=0A> -- a mobile context - a device w= /o a location at the time that an=0D=0A> emergency request is made, does sh= ouldn't hold up the call.=0D=0A> -- a rough vs. precise location routing de= cision at the edge is=0D=0Aassumed=0D=0A> (yet this isn't too worked out fo= r edge devices).=0D=0A> -- location determination takes time based on today= 's available=0D=0A> real-time location technology.=0D=0A>=20=0D=0A> Therefo= re, the (mobile) edge device either:=0D=0A>=20=0D=0A> =091. waits for a loc= ation to be determined before edge routing,=0D=0A> =092. acquires a placeho= lder (in the form of a location URI), and=0D=0A> routes based on pre-provis= ioned rules to a core element which either=0D=0A> "has" or "gets" a LO, or=0D= =0A> =093. (in classic 3GPP style) the endpoint call routing occurs=0D=0A> = immediately based on pre-provisioned routing rules, lands at a core=0D=0A> = element which can do immediate (rough) or eventual (precise) routing=0D=0At= o=0D=0A> parts beyond.=0D=0A>=20=0D=0A> I am ok with the applicability stat= ement being left in.=0D=0A>=20=0D=0A> -roger marshall.=0D=0A>=20=0D=0A> > -= ----Original Message-----=0D=0A> > From: ecrit-bounces@ietf.org [mailto:ecr= it-bounces@ietf.org] On=0D=0A> Behalf=0D=0A> > Of Brian Rosen=0D=0A> > Sent= : Friday, May 01, 2009 6:08 AM=0D=0A> > To: 'Cullen Jennings'; 'Stark, Barb= ara'=0D=0A> > Cc: 'ECRIT'=0D=0A> > Subject: Re: [Ecrit] PhoneBCP=0D=0A> >=0D= =0A> > The underlying protocols can support models where the location of=0D= =0Athe=0D=0A> > endpoint can be determined by the calling network and/or th= e calling=0D=0A> > network=0D=0A> > can do the routing (LoST lookup or some= nation specific routing),=0D=0Aand=0D=0A> > even=0D=0A> > the marking of t= he call. --framework and phonebcp don't really=0D=0A> discuss=0D=0A> > tha= t=0D=0A> > model. An example of that is IMS, which has an element called a= n E-=0D=0A> > CSCF=0D=0A> > that is capable of querying a mobile network's = location=0D=0A> infrastructure=0D=0A> > to=0D=0A> > determine the location = of the caller, and can perform any routing=0D=0A> tasks=0D=0A> > appropriat= e to the location of the caller.=0D=0A> >=0D=0A> > Brian=0D=0A> >=0D=0A> > = -----Original Message-----=0D=0A> > From: ecrit-bounces@ietf.org [mailto:ec= rit-bounces@ietf.org] On=0D=0A> Behalf=0D=0A> > Of=0D=0A> > Cullen Jennings=0D= =0A> > Sent: Friday, May 01, 2009 8:50 AM=0D=0A> > To: Stark, Barbara=0D=0A= > > Cc: ECRIT=0D=0A> > Subject: Re: [Ecrit] PhoneBCP=0D=0A> >=0D=0A> >=0D=0A= > > On Apr 24, 2009, at 12:43 PM, Stark, Barbara wrote:=0D=0A> >=0D=0A> > >= I assume you're referring to the following paragraph in the=0D=0A> > > int= roduction:=0D=0A> > > " This document focuses on the case in which all th= ree steps in=0D=0A> the=0D=0A> > > emergency calling process -- location= configuration, call=0D=0A> routing,=0D=0A> > > and call placement - can= be and are performed by the calling=0D=0A> > > endpoint, with the endpo= int's Access Service Provider=0D=0Asupporting=0D=0A> > > the=0D=0A> > > = process by providing location information. Calls in this case=0D=0A> > > m= ay be=0D=0A> > > routed via an application-layer Communications Service = Provider=0D=0A> > > (e.g., a Voice Service Provider), but need not be. = The=0D=0A> underlying=0D=0A> > > protocols can also be used to support o= ther models in which=0D=0A> parts=0D=0A> > > of=0D=0A> > > the process a= re delegated to the Communications Service=0D=0A> Provider.=0D=0A> > > T= his document does not address in detail either these models or=0D=0A> > > = interoperability issues between them and the model described=0D=0A> > her= e."=0D=0A> > >=0D=0A> > >=0D=0A> >=0D=0A> > I've read this text several tim= es and I'm trying to decide if anyone=0D=0A> > outside this WG could ever d= ecide what it means. Can someone clearly=0D=0A> > explain all the implicati= ons of this paragraph=3F Particularly the=0D=0Alast=0D=0A> > two sentences.=0D= =0A> >=0D=0A> > Thanks, Cullen in my AD role=0D=0A> >=0D=0A> > ____________= ___________________________________=0D=0A> > Ecrit mailing list=0D=0A> > Ec= rit@ietf.org=0D=0A> > https://www.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D= =0A> > _______________________________________________=0D=0A> > Ecrit maili= ng list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www.ietf.org/mailman/listi= nfo/ecrit=0D=0A>=20=0D=0A> CONFIDENTIALITY NOTICE: The information containe= d in this message may=0D=0A> be=0D=0A> privileged and/or confidential. If y= ou are not the intended recipient,=0D=0A> or=0D=0A> responsible for deliver= ing this message to the intended recipient, any=0D=0A> review, forwarding, = dissemination, distribution or copying of this=0D=0A> communication or any = attachment(s) is strictly prohibited. If you have=0D=0A> received this mess= age in error, please notify the sender immediately,=0D=0A> and=0D=0A> delet= e it and all attachments from your computer and network.=0D=0A=0D=0A_______= ________________________________________=0D=0AEcrit mailing list=0D=0AEcrit= @ietf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A-----= ---------------------------------------------------------------------------= ----------------=0D=0AThis message is for the designated recipient only and= may=0D=0Acontain privileged, proprietary, or otherwise private information= =2E =20=0D=0AIf you have received it in error, please notify the sender=0D=0A= immediately and delete the original. Any unauthorized use of=0D=0Athis ema= il is prohibited.=0D=0A----------------------------------------------------= --------------------------------------------=0D=0A[mf2]=0D=0A From randy@qualcomm.com Mon May 4 14:38:24 2009 Return-Path: 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 687863A6E70 for ; Mon, 4 May 2009 14:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.555 X-Spam-Level: X-Spam-Status: No, score=-105.555 tagged_above=-999 required=5 tests=[AWL=1.044, 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 3r81SUaWQSih for ; Mon, 4 May 2009 14:38:23 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 5D1E93A6CE3 for ; Mon, 4 May 2009 14:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1241473189; x=1273009189; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20 |References:=20<49F276 37.7050201@bbn.com><058701c9c5d0$53c 5ef40$fb51cdc0$@net><28B7C3AA2A7ABA 4A841F11217ABE78D67=0D=0A=20590B=0D=0A=20D8E@FRMRSSXCHMBS B3.dc-m.alcatel-lucent.com><7582BC68E4994F4ABF0BD4723975C 3FA0E0471BA@crexc41p><1288E74A73964940B132 A0B9EA8D8ABC5926A365@NASANEXMB04.na.qualcomm.=0D=0A=20com >=0D=0A=20<49F761CC.3090902@bbn.com><1288E74A73964940B132 A0B9EA8D8ABC5926A470@NA=0D=0A=20SANE=0D=0A=20XMB04.na.qua lcomm.com><1288E74A73964940B132A0B9E A8D8ABC5926A498@NASANEXMB04.na.qualc=0D=0A=20omm.=0D=0A =20com><1288E=0D=0A=2074A7=0D=0A=203964940B132A0B9EA8D 8ABC5926A4B2@NASANEXMB04.na.qualcomm.com>=0D=0A=20< 1288E74A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.q ualcomm.com>=0D=0A=20=0D=0A=20|X-Mailer:=20Eudora=20for=20Mac=20OS=20X |X-message-Note:=20Warning:=20Outlook=20in=20use.=20=20Up grade=20to=20Eudora:=20|Date:=20Mo n,=204=20May=202009=2014:36:50=20-0700|To:=20Ted=20Hardie =20,=0D=0A=20=20=20=20=20=20=20=20"D awson,=20Martin"=0D=0A=09,=0D =0A=20=20=20=20=20=20=20=20"Edge,=20Stephen"=20,=0D=0A=20=20=20=20=20=20=20=20"Bernard=0D=0A =20Aboba"=20,=0D=0A=20=20=20 =20=20=20=20=20"Thomson,=20=09Martin"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"ecrit@iet f.org"=20|From:=20Randall=20Gellens=20|Subject:=20Re:=20[Ecrit]=20PhoneBCP |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,56 05"=3B=20a=3D"17769468"; bh=t5sP94gv/ax521sy56Pb9q4NXTLGhQEgMr4hTgyejXM=; b=NrTGiMlMqUA3VeFnt2Lihm3QUiZ/laF1n/L23Q7ch+XrkrQMIT0m9A43 QpoZdXmS9kAGofqLMoAwwfVstCFAd4YvTeFebSa5p8ouy6EmDo0QxE4bw 7qqb8ZZ6g8+NkpMLjcgRCnQMG1wmbsMlxZE5mAbEYpl7E3ugjTiVCN0dU Q=; X-IronPort-AV: E=McAfee;i="5300,2777,5605"; a="17769468" 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; 04 May 2009 14:39:49 -0700 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 n44LdmgC013312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 May 2009 14:39:49 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n44Ldmg7004127 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 May 2009 14:39:48 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 4 May 2009 14:39:47 -0700 Received: from [192.168.1.13] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 4 May 2009 14:39:47 -0700 Message-ID: In-Reply-To: References: <49F27637.7050201@bbn.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><28B7C3AA2A7ABA4A841F11217ABE78D67 590B D8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p><1288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qualcomm. com> <49F761CC.3090902@bbn.com><1288E74A73964940B132A0B9EA8D8ABC5926A470@NA SANE XMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC5926A498@NASANEXMB04.na.qualc omm. com><1288E 74A7 3964940B132A0B9EA8D8ABC5926A4B2@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcomm.com> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 4 May 2009 14:36:50 -0700 To: Ted Hardie , "Dawson, Martin" , "Edge, Stephen" , "Bernard Aboba" , "Thomson, Martin" , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 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: , X-List-Received-Date: Mon, 04 May 2009 21:38:24 -0000 At 10:40 AM -0700 4/30/09, Ted Hardie wrote: > The root of the problem we're facing is that there is a difference between > using IP and using the Internet model. IMS uses IP, but uses a different > model entirely (Whatever you think of that model, I don't think anyone > who looked at how it works could argue that it is the same as the Internet > model.) > The argument that Steven and others have made is that the document set > needs to have an explicit acknowledgement of the other model, so that > there is a realization by those reading them that just because they have > IP, doesn't mean they are dealing with the Internet model. You could > argue that everyone knows that, but the document itself muddies it > far enough that it is far from evident. These are helpful insights into what we're really arguing about here. The statement added in -09 is a compromise; even the most fervent argument against it comes down to "it isn't needed". Given the choice between a compromise statement that clearly does no harm, and, depending on one's viewpoint is either vitally needed or redundant, it seem clear that we should progress the document with the text in it. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- A bird in the hand is safer than one overhead. From spencer@wonderhamster.org Mon May 4 15:00:03 2009 Return-Path: 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 D20283A6C5E for ; Mon, 4 May 2009 15:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.347, 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 dDaA9-qpASAH for ; Mon, 4 May 2009 15:00:03 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 0A7613A6B9B for ; Mon, 4 May 2009 15:00:03 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1M16Dt46aF-000cfm; Mon, 04 May 2009 18:01:27 -0400 Message-ID: From: "Spencer Dawkins" To: "Ted Hardie" , "Dawson, Martin" , "Edge, Stephen" , "BernardAboba" , "Thomson, Martin" , , "Randall Gellens" References: x.gbl><1288E74A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcomm.com> Date: Mon, 4 May 2009 17:00:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19M617c5WKxg9pNSnSKrKIw/0F3qwCSywZc5gZ TEklEqiCL5MfnxlPTIg27wUHbMfzLGI18/nx5rM6To+Pdbyf9/ bTVlvRQBsclFsB96Y4/6m4ecO//XUma3GlU/oYEZA0= 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: , X-List-Received-Date: Mon, 04 May 2009 22:00:03 -0000 I had hoped to stay quiet in this thread, and this is NOT a late hum, either for or against, but > The statement added in -09 is a compromise; even the most fervent argument > against it comes down to "it isn't needed". Given the choice between a > compromise statement that clearly does no harm, and, depending on one's > viewpoint is either vitally needed or redundant, it seem clear that we > should progress the document with the text in it. I'm having a difficult time thinking of "clearly does no harm" as sufficient justification for including text in a document that's still tagged as a BCP... :-( Thanks, Spencer From randy@qualcomm.com Mon May 4 15:30:23 2009 Return-Path: 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 ECAC93A6A18 for ; Mon, 4 May 2009 15:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.62 X-Spam-Level: X-Spam-Status: No, score=-103.62 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5iEZxebO9ta for ; Mon, 4 May 2009 15:30:22 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 7E3E43A684F for ; Mon, 4 May 2009 15:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1241476308; x=1273012308; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20|References:=20x.gbl><1288E74A73964940B132A0B9E A8D8ABC5926A4D4@NASANEXMB04.na.qualcom=0D=0A=20m.com>< p06=0D=0A=20240804c61f8d43cad4@[10.0.1.197]>=0D=0A=20=0D=0A=20|X-Mailer:=20Eudora =20for=20Mac=20OS=20X|X-message-Note:=20Warning:=20Outloo k=20in=20use.=20=20Upgrade=20to=20Eudora:=20|Date:=20Mon,=204=20May=202009=2015:26:28=20-07 00|To:=20Spencer=20Dawkins=20, =0D=0A=20=20=20=20=20=20=20=20Ted=20Hardie=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"Dawson,=20 Martin"=20,=0D=0A=20=20=20=20 =20=20=20=20"Edge,=0D=0A=20Stephen"=20,=0D=0A=20=20=20=20=20=20=20=20BernardAboba=20,=0D=0A=20=20=20=20=20=20=20=20"Thomson, =20=09Martin"=20,=20,=0D=0A=20=20=20=20=20=20=20=20"Randall=0D=0A=20Gel lens"=20|From:=20Randall=20Gellens=20 |Subject:=20Re:=20[Ecrit]=20PhoneBCP |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,56 05"=3B=20a=3D"17764183"; bh=B40cP/7vemvs8e8eSf9jXFwVNQQD5CSrCP1tdpQSibA=; b=X3v+oLqntAzN5b7c5+ao00zahpEcpnccHUX6HRcNRnE0IO4KYLTPviQd ygpZZBbogY8CV/Ig+pWlsl7mS/qmqIgn3/orfBAGhhkq6mEUKm91QbjBV N2sJbVdZzWw/nT6uo4H0AJO8Ml+5H+0b8Nlw7QX5E/zGEMVR+mUpZQjml k=; X-IronPort-AV: E=McAfee;i="5300,2777,5605"; a="17764183" 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; 04 May 2009 15:31:48 -0700 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 n44MVmuC005430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 May 2009 15:31:48 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n44MVlWQ031669 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 May 2009 15:31:47 -0700 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.358.0; Mon, 4 May 2009 15:31:46 -0700 Received: from [192.168.1.13] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 4 May 2009 15:31:46 -0700 Message-ID: In-Reply-To: References: x.gbl><1288E74A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcom m.com> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 4 May 2009 15:26:28 -0700 To: Spencer Dawkins , Ted Hardie , "Dawson, Martin" , "Edge, Stephen" , BernardAboba , "Thomson, Martin" , , "Randall Gellens" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 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: , X-List-Received-Date: Mon, 04 May 2009 22:30:24 -0000 At 5:00 PM -0500 5/4/09, Spencer Dawkins wrote: >> The statement added in -09 is a compromise; even the most fervent >> argument against it comes down to "it isn't needed". Given the >> choice between a compromise statement that clearly does no harm, >> and, depending on one's viewpoint is either vitally needed or >> redundant, it seem clear that we should progress the document with >> the text in it. > > I'm having a difficult time thinking of "clearly does no harm" as > sufficient justification for including text in a document that's > still tagged as a BCP... I never said "clearly does no harm" is *sufficient* justification for adding it, rather, it's justification for not removing it given the arguments for it. There are a number of people who have made well-reasoned and detailed cases for why this text is needed; since it is already a compromise that does no harm, the choice to leave it in seems clear. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Procedures! Of course, that's what you'd use with a *sophisticated* machine like this. Procedures. --'Ceaser Smith' in _Hot_Millions_ From James.Winterbottom@andrew.com Mon May 4 17:15:21 2009 Return-Path: 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 AE18828C26D for ; Mon, 4 May 2009 17:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.248 X-Spam-Level: X-Spam-Status: No, score=-1.248 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 S1B8qVUOgjNB for ; Mon, 4 May 2009 17:15:20 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id B144328C1DE for ; Mon, 4 May 2009 17:15:20 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_05_04_19_37_39 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 04 May 2009 19:37:39 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 19:16:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 19:16:44 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnNCCC8eEB9FaTCSOisI9+9TZFKHAADm0LQ References: x.gbl><1288E74A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcomm.com> From: "Winterbottom, James" To: "Randall Gellens" , "Spencer Dawkins" , "Ted Hardie" , "Dawson, Martin" , "Edge,Stephen" , "BernardAboba" , "Thomson, Martin" , X-OriginalArrivalTime: 05 May 2009 00:16:45.0666 (UTC) FILETIME=[C64CB420:01C9CD16] 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: , X-List-Received-Date: Tue, 05 May 2009 00:15:21 -0000 Under the same reasoning Randy, since there was never consensus in the=0D=0A= WG to add it, it should never have been added, and since no real=0D=0Ajusti= fication for its inclusion has been provided, we should revert back=0D=0Ato= the previous version of the document and proceed to last call the=0D=0Adoc= ument.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A-----Original Message-----=0D= =0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D= =0AOf Randall Gellens=0D=0ASent: Tuesday, 5 May 2009 8:26 AM=0D=0ATo: Spenc= er Dawkins; Ted Hardie; Dawson, Martin; Edge,Stephen;=0D=0ABernardAboba; Th= omson, Martin; ecrit@ietf.org; RandallGellens=0D=0ASubject: Re: [Ecrit] Pho= neBCP=0D=0A=0D=0AAt 5:00 PM -0500 5/4/09, Spencer Dawkins wrote:=0D=0A=0D=0A= >> The statement added in -09 is a compromise; even the most fervent=20=0D= =0A>> argument against it comes down to "it isn't needed". Given the=20=0D= =0A>> choice between a compromise statement that clearly does no harm,=20=0D= =0A>> and, depending on one's viewpoint is either vitally needed or=20=0D=0A= >> redundant, it seem clear that we should progress the document with=20=0D= =0A>> the text in it.=0D=0A>=0D=0A> I'm having a difficult time thinking o= f "clearly does no harm" as=20=0D=0A> sufficient justification for includin= g text in a document that's=20=0D=0A> still tagged as a BCP...=0D=0A=0D=0AI= never said "clearly does no harm" is *sufficient* justification for=20=0D=0A= adding it, rather, it's justification for not removing it given the=20=0D=0A= arguments for it. There are a number of people who have made=20=0D=0Awell-= reasoned and detailed cases for why this text is needed; since=20=0D=0Ait i= s already a compromise that does no harm, the choice to leave it=20=0D=0Ain= seems clear.=0D=0A=0D=0A--=20=0D=0ARandall Gellens=0D=0AOpinions are perso= nal; facts are suspect; I speak for myself only=0D=0A-------------- R= andomly selected tag: ---------------=0D=0AProcedures! Of course, that's w= hat you'd use with a *sophisticated*=0D=0Amachine like this. Procedures. = --'Ceaser Smith' in _Hot_Millions_=0D=0A_________________________________= ______________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www= =2Eietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A-----------------------------= -------------------------------------------------------------------=0D=0ATh= is message is for the designated recipient only and may=0D=0Acontain privil= eged, proprietary, or otherwise private information. =20=0D=0AIf you have r= eceived it in error, please notify the sender=0D=0Aimmediately and delete t= he original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-= ---------------------------------------------------------------------------= --------------------=0D=0A[mf2]=0D=0A From randy@qualcomm.com Mon May 4 17:28:55 2009 Return-Path: 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 4EC113A704E for ; Mon, 4 May 2009 17:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.56 X-Spam-Level: X-Spam-Status: No, score=-105.56 tagged_above=-999 required=5 tests=[AWL=1.039, 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 Q4FOSxZ6XDkZ for ; Mon, 4 May 2009 17:28:54 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 4B4D73A6D96 for ; Mon, 4 May 2009 17:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1241483420; x=1273019420; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20|References:=20x.gbl><1288E74A73964940 B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcom=0D=0A=20m .com>=0D=0A=20=0D=0A=20=0D=0A=20|X-Mailer:=20Eudor a=20for=20Mac=20OS=20X|X-message-Note:=20Warning:=20Outlo ok=20in=20use.=20=20Upgrade=20to=20Eudora:=20|Date:=20Mon,=204=20May=202009=2017:29:19=20-0 700|To:=20"Winterbottom,=20James"=20,=0D=0A=20=20=20=20=20=20=20=20Spencer=20Dawkin s=0D=0A=09,=0D=0A=20=20=20=20 =20=20=20=20Ted=20Hardie=20,=0D=0A =20=20=20=20=20=20=20=20"Dawson,=0D=0A=20=20Martin"=20,=0D=0A=20=20=20=20=20=20=20=20"Ed ge,Stephen"=20,=0D=0A=20=20=20=20=20 =20=20=20BernardAboba=20,=0D =0A=20=20=20=20=20=20=20=20"Thomson,=20Martin"=0D=0A=09,=20|From:=20Ran dall=20Gellens=20|Subject:=20Re:=20[E crit]=20PhoneBCP|MIME-Version:=201.0|Content-Type:=20text /plain=3B=20charset=3D"us-ascii"=3B=20format=3Dflowed |X-Random-Sig-Tag:=201.0b28|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5605"=3B=20a=3D"17775383"; bh=dzg/Ywyx2A+RaGi0EBvcaG3UIjMvUpOzN9zogeIuaDU=; b=Y6DHd8ER29M+c/LbcWzl/SGuJwTUSE6h1FeH8oft7kIO2Gab+8ZEsOAs RpB80UwiNDdHt9skPXD3YI7rcAggK5xG5S5bb2WXH0T1p/Og9GDxOQqHv F23P9G7WC00Mv344XECKdYa1ZQHq7ai6N4auf6ZqIdjcj/9gM6jDEoZJs Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5605"; a="17775383" 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; 04 May 2009 17:30:19 -0700 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 n450UJLZ001515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 May 2009 17:30:19 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n450UIDX018505 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 May 2009 17:30:19 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 4 May 2009 17:30:18 -0700 Received: from [192.168.1.13] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 4 May 2009 17:30:17 -0700 Message-ID: In-Reply-To: References: x.gbl><1288E74A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcom m.com> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 4 May 2009 17:29:19 -0700 To: "Winterbottom, James" , Spencer Dawkins , Ted Hardie , "Dawson, Martin" , "Edge,Stephen" , BernardAboba , "Thomson, Martin" , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 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: , X-List-Received-Date: Tue, 05 May 2009 00:28:55 -0000 At 7:16 PM -0500 5/4/09, James Winterbottom wrote: > Under the same reasoning Randy, since there was never consensus in the > WG to add it, There may not have been a formal consensus call, but there was significant discussion on the list, and my impression was that we had general agreement to add it. > it should never have been added, and since no real > justification for its inclusion has been provided, There has been much justification with detailed reasoning for adding it. > we should revert back > to the previous version of the document and proceed to last call the > document. It was added as a compromise based on the discussion in SFO and on the list subsequently. It's a compromise, like much of the text we publish. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Randall Gellens > Sent: Tuesday, 5 May 2009 8:26 AM > To: Spencer Dawkins; Ted Hardie; Dawson, Martin; Edge,Stephen; > BernardAboba; Thomson, Martin; ecrit@ietf.org; RandallGellens > Subject: Re: [Ecrit] PhoneBCP > > At 5:00 PM -0500 5/4/09, Spencer Dawkins wrote: > >>> The statement added in -09 is a compromise; even the most fervent >>> argument against it comes down to "it isn't needed". Given the >>> choice between a compromise statement that clearly does no harm, >>> and, depending on one's viewpoint is either vitally needed or >>> redundant, it seem clear that we should progress the document with >>> the text in it. >> >> I'm having a difficult time thinking of "clearly does no harm" as >> sufficient justification for including text in a document that's >> still tagged as a BCP... > > I never said "clearly does no harm" is *sufficient* justification for > adding it, rather, it's justification for not removing it given the > arguments for it. There are a number of people who have made > well-reasoned and detailed cases for why this text is needed; since > it is already a compromise that does no harm, the choice to leave it > in seems clear. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Procedures! Of course, that's what you'd use with a *sophisticated* > machine like this. Procedures. --'Ceaser Smith' in _Hot_Millions_ > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I have made it a rule, whenever in my power, to avoid becoming the draughtsman of papers to be reviewed by a public body. --Benjamin Franklin From James.Winterbottom@andrew.com Mon May 4 17:31:44 2009 Return-Path: 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 56C733A714D for ; Mon, 4 May 2009 17:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.247 X-Spam-Level: X-Spam-Status: No, score=-1.247 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 RfKOwXzBzBqE for ; Mon, 4 May 2009 17:31:43 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 3EADD3A7144 for ; Mon, 4 May 2009 17:31:43 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_05_04_19_54_03 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 04 May 2009 19:54:03 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 19:33:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 19:33:08 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnNGK6QEXFW2N8WToGyF6gV6HGVPAAADWqQ References: x.gbl><1288E74A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcom m.com> From: "Winterbottom, James" To: "Randall Gellens" , "Spencer Dawkins" , "Ted Hardie" , "Dawson, Martin" , "Edge,Stephen" , "BernardAboba" , "Thomson, Martin" , X-OriginalArrivalTime: 05 May 2009 00:33:09.0238 (UTC) FILETIME=[108DE160:01C9CD19] 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: , X-List-Received-Date: Tue, 05 May 2009 00:31:44 -0000 There was no consensus to add the text, whether the wording is a=0D=0Acompr= omise is irrelevant at this stage. It was added without consensus=0D=0Aand = needs to be removed.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A-----Ori= ginal Message-----=0D=0AFrom: Randall Gellens [mailto:randy@qualcomm.com] =0D= =0ASent: Tuesday, 5 May 2009 10:29 AM=0D=0ATo: Winterbottom, James; Spencer= Dawkins; Ted Hardie; Dawson, Martin;=0D=0AEdge,Stephen; BernardAboba; Thom= son, Martin; ecrit@ietf.org=0D=0ASubject: Re: [Ecrit] PhoneBCP=0D=0A=0D=0AA= t 7:16 PM -0500 5/4/09, James Winterbottom wrote:=0D=0A=0D=0A> Under the s= ame reasoning Randy, since there was never consensus in=0D=0Athe=0D=0A> WG= to add it,=0D=0A=0D=0AThere may not have been a formal consensus call, but= there was=20=0D=0Asignificant discussion on the list, and my impression wa= s that we had=20=0D=0Ageneral agreement to add it.=0D=0A=0D=0A> it should= never have been added, and since no real=0D=0A> justification for its inc= lusion has been provided,=0D=0A=0D=0AThere has been much justification with= detailed reasoning for adding it.=0D=0A=0D=0A> we should revert back=0D=0A= > to the previous version of the document and proceed to last call the=0D=0A= > document.=0D=0A=0D=0AIt was added as a compromise based on the discussio= n in SFO and on=20=0D=0Athe list subsequently. It's a compromise, like muc= h of the text we=20=0D=0Apublish.=0D=0A=0D=0A=0D=0A> -----Original Message= -----=0D=0A> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] = On=0D=0ABehalf=0D=0A> Of Randall Gellens=0D=0A> Sent: Tuesday, 5 May 2009= 8:26 AM=0D=0A> To: Spencer Dawkins; Ted Hardie; Dawson, Martin; Edge,Step= hen;=0D=0A> BernardAboba; Thomson, Martin; ecrit@ietf.org; RandallGellens=0D= =0A> Subject: Re: [Ecrit] PhoneBCP=0D=0A>=0D=0A> At 5:00 PM -0500 5/4/09,= Spencer Dawkins wrote:=0D=0A>=0D=0A>>> The statement added in -09 is a c= ompromise; even the most fervent=0D=0A>>> argument against it comes down t= o "it isn't needed". Given the=0D=0A>>> choice between a compromise state= ment that clearly does no harm,=0D=0A>>> and, depending on one's viewpoint= is either vitally needed or=0D=0A>>> redundant, it seem clear that we sho= uld progress the document with=0D=0A>>> the text in it.=0D=0A>>=0D=0A>> = I'm having a difficult time thinking of "clearly does no harm" as=0D=0A>> = sufficient justification for including text in a document that's=0D=0A>> s= till tagged as a BCP...=0D=0A>=0D=0A> I never said "clearly does no harm" = is *sufficient* justification for=0D=0A> adding it, rather, it's justifica= tion for not removing it given the=0D=0A> arguments for it. There are a n= umber of people who have made=0D=0A> well-reasoned and detailed cases for = why this text is needed; since=0D=0A> it is already a compromise that does= no harm, the choice to leave it=0D=0A> in seems clear.=0D=0A>=0D=0A> --=0D= =0A> Randall Gellens=0D=0A> Opinions are personal; facts are suspect; = I speak for myself=0D=0Aonly=0D=0A> -------------- Randomly selected ta= g: ---------------=0D=0A> Procedures! Of course, that's what you'd use wi= th a *sophisticated*=0D=0A> machine like this. Procedures. --'Ceaser S= mith' in _Hot_Millions_=0D=0A> ___________________________________________= ____=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www.= ietf.org/mailman/listinfo/ecrit=0D=0A>=0D=0A>=20=0D=0A>=0D=0A--------------= ----------------------------------------------------------=0D=0A-----------= -------------=0D=0A> This message is for the designated recipient only and= may=0D=0A> contain privileged, proprietary, or otherwise private informat= ion.=20=0D=0A> If you have received it in error, please notify the sender=0D= =0A> immediately and delete the original. Any unauthorized use of=0D=0A> = this email is prohibited.=0D=0A>=20=0D=0A>=0D=0A--------------------------= ----------------------------------------------=0D=0A-----------------------= -=0D=0A> [mf2]=0D=0A>=0D=0A> ____________________________________________= ___=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www.i= etf.org/mailman/listinfo/ecrit=0D=0A=0D=0A=0D=0A--=20=0D=0ARandall Gellens=0D= =0AOpinions are personal; facts are suspect; I speak for myself only=0D= =0A-------------- Randomly selected tag: ---------------=0D=0AI have made i= t a rule, whenever in my power, to avoid becoming the=0D=0Adraughtsman of p= apers to be reviewed by a public body.=0D=0A --Benjamin Frankl= in=0D=0A=0D=0A-------------------------------------------------------------= -----------------------------------=0D=0AThis message is for the designated= recipient only and may=0D=0Acontain privileged, proprietary, or otherwise = private information. =20=0D=0AIf you have received it in error, please noti= fy the sender=0D=0Aimmediately and delete the original. Any unauthorized u= se of=0D=0Athis email is prohibited.=0D=0A---------------------------------= ---------------------------------------------------------------=0D=0A[mf2]=0D= =0A From sedge@qualcomm.com Mon May 4 20:17:20 2009 Return-Path: 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 979653A67FA for ; Mon, 4 May 2009 20:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.568 X-Spam-Level: X-Spam-Status: No, score=-103.568 tagged_above=-999 required=5 tests=[AWL=-0.969, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36Yq1ECff7P1 for ; Mon, 4 May 2009 20:17:19 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 440553A67EF for ; Mon, 4 May 2009 20:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1241493525; x=1273029525; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Winterbottom,=20James"=20, =0D=0A=20=20=20=20=20=20=20=20"Gellens,=20Randall"=0D=0A =09,=0D=0A=20=20=20=20=20=20=20=20Spe ncer=20Dawkins=20,=0D=0A=20=20 =20=20=20=20=20=20"Hardie,=0D=0A=20Ted"=20,=0D=0A=20=20=20=20=20=20=20=20"Dawson,=20Martin" =20,=0D=0A=20=20=20=20=20=20=20 =20BernardAboba=20,=0D=0A=20 =20=20=20=20=20=20=20"Thomson,=20Martin"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"ecrit@ ietf.org"=20|Date:=20Mon,=204=20May=20200 9=2020:18:37=20-0700|Subject:=20RE:=20[Ecrit]=20PhoneBCP |Thread-Topic:=20[Ecrit]=20PhoneBCP|Thread-Index:=20AcnNG K6QEXFW2N8WToGyF6gV6HGVPAAADWqQAAVBX2A=3D|Message-ID:=20< 1288E74A73964940B132A0B9EA8D8ABC5926A6F9@NASANEXMB04.na.q ualcomm.com>|References:=20x.gbl><1288E74A73964940B132A0B 9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcom=0D=0A=20m.com>=0D=0A=20=0D=0A=20=0D=0A=20=0D=0A=20=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5605"=3B=20a=3D"17773097"; bh=nakwPSkWW8YONTajOfuhwS8EDfooAZvnP0C8cXTxrJA=; b=At+VyuCtPfzRsRrYP00dgbP4Ftj0Xn7g/9c1Bc9PhFSfcMwYOsAEBfaG ZOVVdarUgCBstQmiEf6nB1k4o/R+u+BOlh4qszbyihqdOKZqd3U3F9yRH dldZC624wT7IpNnCcu64mewjpTSDuAeSLlDpaMtHwIvRY2kLRfzcl0bha Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5605"; a="17773097" 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; 04 May 2009 20:18:45 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n453Ig5N032347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 May 2009 20:18:45 -0700 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 n453IdiX014204 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 May 2009 20:18:39 -0700 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Mon, 4 May 2009 20:18:39 -0700 From: "Edge, Stephen" To: "Winterbottom, James" , "Gellens, Randall" , Spencer Dawkins , "Hardie, Ted" , "Dawson, Martin" , BernardAboba , "Thomson, Martin" , "ecrit@ietf.org" Date: Mon, 4 May 2009 20:18:37 -0700 Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnNGK6QEXFW2N8WToGyF6gV6HGVPAAADWqQAAVBX2A= Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5926A6F9@NASANEXMB04.na.qualcomm.com> References: x.gbl><1288E74A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcom m.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: , X-List-Received-Date: Tue, 05 May 2009 03:17:20 -0000 Perhaps "mostly harmless" then? Note that we are having this discussion now as a result of a previous discu= ssion concerning the suitability of the Ecrit solution for any type of publ= ic IP access. Those contending that the solution is suitable are (by and la= rge) the ones now objecting to including the statement although they were n= ot objecting just over 5 weeks ago when the statement was introduced as a m= eans of settling the first discussion. Those contending that the solution i= s not universally suitable are (as far as I am aware) prepared to drop that= issue (at least as regards having the solution go through last call) if th= e statement is included. If the statement is in the end removed, we may find ourselves back again to= the first discussion. If that happens, I will consider the solution fair g= ame for some more specific and detailed criticism than has so far been prov= ided - since after all, any solution that claims universal applicability is= setting itself up as rather large and inviting target. Kind Regards Stephen -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 Sent: Monday, May 04, 2009 5:33 PM To: Gellens, Randall; Spencer Dawkins; Hardie, Ted; Dawson, Martin; Edge, S= tephen; BernardAboba; Thomson, Martin; ecrit@ietf.org Subject: RE: [Ecrit] PhoneBCP There was no consensus to add the text, whether the wording is a compromise is irrelevant at this stage. It was added without consensus and needs to be removed. Cheers James -----Original Message----- From: Randall Gellens [mailto:randy@qualcomm.com]=20 Sent: Tuesday, 5 May 2009 10:29 AM To: Winterbottom, James; Spencer Dawkins; Ted Hardie; Dawson, Martin; Edge,Stephen; BernardAboba; Thomson, Martin; ecrit@ietf.org Subject: Re: [Ecrit] PhoneBCP At 7:16 PM -0500 5/4/09, James Winterbottom wrote: > Under the same reasoning Randy, since there was never consensus in the > WG to add it, There may not have been a formal consensus call, but there was=20 significant discussion on the list, and my impression was that we had=20 general agreement to add it. > it should never have been added, and since no real > justification for its inclusion has been provided, There has been much justification with detailed reasoning for adding it. > we should revert back > to the previous version of the document and proceed to last call the > document. It was added as a compromise based on the discussion in SFO and on=20 the list subsequently. It's a compromise, like much of the text we=20 publish. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Randall Gellens > Sent: Tuesday, 5 May 2009 8:26 AM > To: Spencer Dawkins; Ted Hardie; Dawson, Martin; Edge,Stephen; > BernardAboba; Thomson, Martin; ecrit@ietf.org; RandallGellens > Subject: Re: [Ecrit] PhoneBCP > > At 5:00 PM -0500 5/4/09, Spencer Dawkins wrote: > >>> The statement added in -09 is a compromise; even the most fervent >>> argument against it comes down to "it isn't needed". Given the >>> choice between a compromise statement that clearly does no harm, >>> and, depending on one's viewpoint is either vitally needed or >>> redundant, it seem clear that we should progress the document with >>> the text in it. >> >> I'm having a difficult time thinking of "clearly does no harm" as >> sufficient justification for including text in a document that's >> still tagged as a BCP... > > I never said "clearly does no harm" is *sufficient* justification for > adding it, rather, it's justification for not removing it given the > arguments for it. There are a number of people who have made > well-reasoned and detailed cases for why this text is needed; since > it is already a compromise that does no harm, the choice to leave it > in seems clear. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Procedures! Of course, that's what you'd use with a *sophisticated* > machine like this. Procedures. --'Ceaser Smith' in _Hot_Millions_ > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > >=20 > ------------------------------------------------------------------------ ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information.=20 > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. >=20 > ------------------------------------------------------------------------ ------------------------ > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=20 Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I have made it a rule, whenever in my power, to avoid becoming the draughtsman of papers to be reviewed by a public body. --Benjamin Franklin ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] From MILANPA@nortel.com Tue May 5 03:27:34 2009 Return-Path: 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 72F4D3A6A18 for ; Tue, 5 May 2009 03:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.018 X-Spam-Level: X-Spam-Status: No, score=-6.018 tagged_above=-999 required=5 tests=[AWL=0.581, 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 yx+0WasKRH8R for ; Tue, 5 May 2009 03:27:33 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 47EB03A69B0 for ; Tue, 5 May 2009 03:27:33 -0700 (PDT) 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 n45ASdm27261; Tue, 5 May 2009 10:28:40 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 11:28:34 +0100 Message-ID: <0913B6CD18F370498CD65864CF254E90098B8F8A@zharhxm1.corp.nortel.com> In-Reply-To: <49FB4DD6.6010102@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Thread-Index: AcnKk01vTtiJRQeGSzS/nHSzc6CZhAC2Mnpw References: <49FB4DD6.6010102@ericsson.com> From: "Milan Patel" To: "Gonzalo Camarillo" , "Dawes, Peter, VF-Group" Cc: ecrit@ietf.org Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.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: , X-List-Received-Date: Tue, 05 May 2009 10:27:34 -0000 Hi Peter and Gonazalo, Thank you for the comments provided on the list. I'll provide version -05 this week based on your feedback. Best regards, Milan Milan Patel Carrier Networks Core Standards Nortel milanpa@nortel.com Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 / ESN 748 9261 For the Companies listed below, The Institute of Chartered Accountants in England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act 1986. The affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as agents of the Companies only and without personal liability. The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel Networks AB; Nortel Networks International Finance & Holding BV -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: 01 May 2009 20:31 To: Dawes, Peter, VF-Group Cc: Patel, Milan (MOP:EP10); ecrit@ietf.org Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Hi, inline: Dawes, Peter, VF-Group wrote: > Hello Milan, Gonzalo, > I have read through draft-patel-ecrit-sos-parameter-04 and I have a few > comments: >=20 > Section 4.2 says: > The "sos" URI parameter is appended to the URI included in the > Contact header, thus indicating to the UA that this contact address > will be included in the Contact header of an INVITE for emergency > call initiation. >=20 > I think it would be clearer to say: >=20 > The "sos" URI parameter is appended to the URI included in the > Contact header, thus indicating to the UA that it MUST include this > contact address > in the Contact header of an INVITE for emergency call initiation. defining normative behavior in this way is not very clear. I would say=20 "it needs to include" instead. Defining what the UA MUST do could be=20 placed in a different paragraph or section if needed. The point is that=20 separating the specification of UAC behavior from the specification of=20 UAS behavior is typically a good thing. > Also, 4.2 says nothing about whether the PSAP uses the URI in the > Contact: header for=20 > callback. At the end of section 1., it says: >=20 > A call back from a PSAP would be routed to the registered contact > address. >=20 > So it seems that for any subsequent callback session initiated by the > PSAP, the address > in the From: or P-Asserted-Identity header fields will be used. I am > not sure that > draft-ietf-ecrit-framework-09 is clear on what to include in the > Request URI for callback, > but it suggests that for dropped calls the URI from the Contact: header > field may be used.=20 >=20 > =20 > Section 4.3 says: > If registration is successful, the 200 (OK) response from a legacy > registrar is unlikely to include the "sos" URI parameter in the > Contact header. The UAC is aware of its registered contact address > and address-of-record, however, is unable to distinguish between this > registration and a non-emergency registration. >=20 > Does it matter if the UAC gets the "sos" URI parameter back from the > registrar? I would > have thought that the disadvantage of a non-supporting registrar is > limited to not=20 > routing callbacks to the contact address marked for emergency use. The > UAC can still use > the emergency registered contact address in the Contact: header field of > an INVITE request > for an emergency call. the thing is that a legacy registrar will treat this registration as a=20 non-emergency registration. That is what the text needs to capture. Cheers, Gonzalo From hannes.tschofenig@nsn.com Wed May 6 02:29:19 2009 Return-Path: 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 83FA53A6B1B for ; Wed, 6 May 2009 02:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.602 X-Spam-Level: X-Spam-Status: No, score=-5.602 tagged_above=-999 required=5 tests=[AWL=0.997, 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 r21QMrPrmEOj for ; Wed, 6 May 2009 02:29:13 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id E03133A6B09 for ; Wed, 6 May 2009 02:29:09 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n469UWrp032583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2009 11:30:32 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n469UVY6006859; Wed, 6 May 2009 11:30:31 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 May 2009 11:30:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 May 2009 12:32:09 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450152E1E1@FIESEXC015.nsn-intra.net> In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5926A6F9@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnNGK6QEXFW2N8WToGyF6gV6HGVPAAADWqQAAVBX2AAPjN9YA== References: x.gbl><1288E74A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5926A6F9@NASANEXMB04.na.qualcomm.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Edge, Stephen" , "Winterbottom, James" , "Gellens, Randall" , "Spencer Dawkins" , "Hardie,Ted" , "Dawson, Martin" , "BernardAboba" , "Thomson, Martin" , X-OriginalArrivalTime: 06 May 2009 09:30:31.0834 (UTC) FILETIME=[4D0D57A0:01C9CE2D] 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: , X-List-Received-Date: Wed, 06 May 2009 09:29:19 -0000 Hi Stephen,=20 I believe what James is saying is that there was never a HUM to include an applicability statement into the document. He is correct about this aspect. =20 Instead, there were some folks in the group who thought they should discuss how a potential text could look like and Brian included it into the document. This has upset a few folks.=20 When it comes to important things like these the working group always has to make a conscious decision * whether they want to include an applicability statement at all, and=20 * if so, what it should say.=20 What we should also keep in mind is that our document might bounce back from the IESG with the indication that we should resolve the technical issues that prevent applicability of the work in a certain environment.=20 In this weeks 3GPP IETF conference call Cullen has asked Hannu to solicit feedback from the 3GPP about the technical issues that prevent the work being used in the cellular environment. He very well understands that the 3GPP is working on IMS and has crafted many things on their own.=20 Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of ext Edge, Stephen >Sent: 05 May, 2009 06:19 >To: Winterbottom, James; Gellens, Randall; Spencer Dawkins;=20 >Hardie,Ted; Dawson, Martin; BernardAboba; Thomson, Martin;=20 >ecrit@ietf.org >Subject: Re: [Ecrit] PhoneBCP > >Perhaps "mostly harmless" then? > >Note that we are having this discussion now as a result of a=20 >previous discussion concerning the suitability of the Ecrit=20 >solution for any type of public IP access. Those contending=20 >that the solution is suitable are (by and large) the ones now=20 >objecting to including the statement although they were not=20 >objecting just over 5 weeks ago when the statement was=20 >introduced as a means of settling the first discussion. Those=20 >contending that the solution is not universally suitable are=20 >(as far as I am aware) prepared to drop that issue (at least=20 >as regards having the solution go through last call) if the=20 >statement is included. > >If the statement is in the end removed, we may find ourselves=20 >back again to the first discussion. If that happens, I will=20 >consider the solution fair game for some more specific and=20 >detailed criticism than has so far been provided - since after=20 >all, any solution that claims universal applicability is=20 >setting itself up as rather large and inviting target. > >Kind Regards > >Stephen >-----Original Message----- >From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] >Sent: Monday, May 04, 2009 5:33 PM >To: Gellens, Randall; Spencer Dawkins; Hardie, Ted; Dawson,=20 >Martin; Edge, Stephen; BernardAboba; Thomson, Martin; ecrit@ietf.org >Subject: RE: [Ecrit] PhoneBCP > >There was no consensus to add the text, whether the wording is=20 >a compromise is irrelevant at this stage. It was added without=20 >consensus and needs to be removed. > >Cheers >James > > >-----Original Message----- >From: Randall Gellens [mailto:randy@qualcomm.com] >Sent: Tuesday, 5 May 2009 10:29 AM >To: Winterbottom, James; Spencer Dawkins; Ted Hardie; Dawson,=20 >Martin; Edge,Stephen; BernardAboba; Thomson, Martin; ecrit@ietf.org >Subject: Re: [Ecrit] PhoneBCP > >At 7:16 PM -0500 5/4/09, James Winterbottom wrote: > >> Under the same reasoning Randy, since there was never consensus in >the >> WG to add it, > >There may not have been a formal consensus call, but there was=20 >significant discussion on the list, and my impression was that=20 >we had general agreement to add it. > >> it should never have been added, and since no real justification=20 >> for its inclusion has been provided, > >There has been much justification with detailed reasoning for=20 >adding it. > >> we should revert back >> to the previous version of the document and proceed to last=20 >call the =20 >> document. > >It was added as a compromise based on the discussion in SFO=20 >and on the list subsequently. It's a compromise, like much of=20 >the text we publish. > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >Behalf >> Of Randall Gellens >> Sent: Tuesday, 5 May 2009 8:26 AM >> To: Spencer Dawkins; Ted Hardie; Dawson, Martin; Edge,Stephen; =20 >> BernardAboba; Thomson, Martin; ecrit@ietf.org; RandallGellens >> Subject: Re: [Ecrit] PhoneBCP >> >> At 5:00 PM -0500 5/4/09, Spencer Dawkins wrote: >> >>>> The statement added in -09 is a compromise; even the=20 >most fervent =20 >>>> argument against it comes down to "it isn't needed". Given the =20 >>>> choice between a compromise statement that clearly does no harm, =20 >>>> and, depending on one's viewpoint is either vitally needed or =20 >>>> redundant, it seem clear that we should progress the=20 >document with =20 >>>> the text in it. >>> >>> I'm having a difficult time thinking of "clearly does no=20 >harm" as =20 >>> sufficient justification for including text in a document that's =20 >>> still tagged as a BCP... >> >> I never said "clearly does no harm" is *sufficient*=20 >justification for =20 >> adding it, rather, it's justification for not removing it given the =20 >> arguments for it. There are a number of people who have made =20 >> well-reasoned and detailed cases for why this text is needed; since =20 >> it is already a compromise that does no harm, the choice to=20 >leave it =20 >> in seems clear. >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself >only >> -------------- Randomly selected tag: --------------- Procedures! =20 >> Of course, that's what you'd use with a *sophisticated* >> machine like this. Procedures. --'Ceaser Smith' in=20 >_Hot_Millions_ >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >>=20 >> >--------------------------------------------------------------- >--------- >------------------------ >> This message is for the designated recipient only and may contain=20 >> privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender =20 >> immediately and delete the original. Any unauthorized use of this=20 >> email is prohibited. >>=20 >> >--------------------------------------------------------------- >--------- >------------------------ >> [mf2] >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > >-- >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly selected tag: --------------- I have=20 >made it a rule, whenever in my power, to avoid becoming the=20 >draughtsman of papers to be reviewed by a public body. > --Benjamin Franklin > >--------------------------------------------------------------- >--------------------------------- >This message is for the designated recipient only and may=20 >contain privileged, proprietary, or otherwise private information. =20 >If you have received it in error, please notify the sender=20 >immediately and delete the original. Any unauthorized use of=20 >this email is prohibited. >--------------------------------------------------------------- >--------------------------------- >[mf2] > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From Hannes.Tschofenig@gmx.net Wed May 6 11:32:11 2009 Return-Path: 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 DC24728C259 for ; Wed, 6 May 2009 11:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.581 X-Spam-Level: X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_05=-1.11] 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 C2o0yCishB+q for ; Wed, 6 May 2009 11:32:05 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2FBB63A6F00 for ; Wed, 6 May 2009 11:23:40 -0700 (PDT) Received: (qmail invoked by alias); 06 May 2009 18:25:04 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp070) with SMTP; 06 May 2009 20:25:04 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX194YcVf33V40cmBYPDLto1WwvolBQWxFOZG2ttDNj kW1ILo/KLA9ACZ From: "Hannes Tschofenig" To: Date: Wed, 6 May 2009 21:26:39 +0300 Message-ID: <018601c9ce78$34a2c650$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnOeCfbk3tbFF0wSoG0in3t1L82Jw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6899999999999999 Subject: [Ecrit] ECRIT Interim Teleconference 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: , X-List-Received-Date: Wed, 06 May 2009 18:32:11 -0000 On Wednesday, June 3, 2009, 13:00-14:30 EDT (17:00-18:30 GMT), ECRIT will be having a teleconference interim. The agenda, slides and dial-in information for this meeting will be posted to the ECRIT wiki page at: http://trac.tools.ietf.org/wg/ecrit/trac/wiki From sedge@qualcomm.com Wed May 6 17:26:54 2009 Return-Path: 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 9F52228C1AF for ; Wed, 6 May 2009 17:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.538 X-Spam-Level: X-Spam-Status: No, score=-103.538 tagged_above=-999 required=5 tests=[AWL=-0.939, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAYcw8+eRDMS for ; Wed, 6 May 2009 17:26:53 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 14A4028C1FF for ; Wed, 6 May 2009 17:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1241656067; x=1273192067; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Tschofenig,=20Hannes=20(NSN=20-=20FI/Espoo)"=20,=0D=0A=20=20=20=20=20=20=20=20"Winterbo ttom,=20James"=20,=0D=0A =20=20=20=20=20=20=20=20"Gellens,=20Randall"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20Spencer=20 Dawkins=20,=0D=0A=20=20=20=20 =20=20=20=20"Hardie,=0D=0A=20Ted"=20 ,=0D=0A=20=20=20=20=20=20=20=20"Dawson,=20Martin"=20,=0D=0A=20=20=20=20=20=20=20=20Berna rdAboba=20,=0D=0A=20=20=20=20 =20=20=20=20"Thomson,=20Martin"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"ecrit@ietf.org" =20|Date:=20Wed,=206=20May=202009=2017:27 :41=20-0700|Subject:=20RE:=20[Ecrit]=20PhoneBCP |Thread-Topic:=20[Ecrit]=20PhoneBCP|Thread-Index:=20AcnNG K6QEXFW2N8WToGyF6gV6HGVPAAADWqQAAVBX2AAPjN9YAAg1AvQ |Message-ID:=20<1288E74A73964940B132A0B9EA8D8ABC5926A848@ NASANEXMB04.na.qualcomm.com>|References:=20x.gbl><1288E74 A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcomm .com> =0D=0A=20<128 8E74A73964940B132A0B9EA8D8ABC5926A6F9@NASANEXMB04.na.qual comm.com>=0D=0A=20<3D3C75174CB95F42AD6BCC56E5555B450152E1 E1@FIESEXC015.nsn-intra.net>|In-Reply-To:=20<3D3C75174CB9 5F42AD6BCC56E5555B450152E1E1@FIESEXC015.nsn-intra.net> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5607"=3B=20a=3D"17863178"; bh=udhjyKweqOUUYCfpykupEqjPW3DW9mdJO7u/WrXJNqQ=; b=FY4KVdWsmgm7XKgiLM7CLEfu03FBAyw28s/9CywRHfmYFOmfw0GwSc0D mKHX92Ogn4toyCRXcHW3Rj9IzLTPVh6Q0tuk9KDO1QnSJl5ZSAZpgnMCl q7q2fBscRe2QUTdokGC8XuuRzSvMJjI3FeHX8R8WuggaP/E0wn1wkJuem k=; X-IronPort-AV: E=McAfee;i="5300,2777,5607"; a="17863178" 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; 06 May 2009 17:27:46 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n470RjAx002879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2009 17:27:46 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n470RgLD020012 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 May 2009 17:27:42 -0700 (PDT) Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub04.na.qualcomm.com ([129.46.134.222]) with mapi; Wed, 6 May 2009 17:27:41 -0700 From: "Edge, Stephen" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "Winterbottom, James" , "Gellens, Randall" , Spencer Dawkins , "Hardie, Ted" , "Dawson, Martin" , BernardAboba , "Thomson, Martin" , "ecrit@ietf.org" Date: Wed, 6 May 2009 17:27:41 -0700 Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnNGK6QEXFW2N8WToGyF6gV6HGVPAAADWqQAAVBX2AAPjN9YAAg1AvQ Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5926A848@NASANEXMB04.na.qualcomm.com> References: x.gbl><1288E74A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5926A6F9@NASANEXMB04.na.qualcomm.com> <3D3C75174CB95F42AD6BCC56E5555B450152E1E1@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450152E1E1@FIESEXC015.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: , X-List-Received-Date: Thu, 07 May 2009 00:26:54 -0000 Hi Hannes Thanks for the FYI. Hannu has now invited 3GPP comments from SA2 so we will= see what will happen. I have effectively told Hannu (you and Cullen were C= C'd) that since SA2 are meeting next week (in Estonia), that a couple of we= eks could be needed. Kind Regards Stephen -----Original Message----- From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com= ]=20 Sent: Wednesday, May 06, 2009 2:32 AM To: Edge, Stephen; Winterbottom, James; Gellens, Randall; Spencer Dawkins; = Hardie, Ted; Dawson, Martin; BernardAboba; Thomson, Martin; ecrit@ietf.org Subject: RE: [Ecrit] PhoneBCP Hi Stephen,=20 I believe what James is saying is that there was never a HUM to include an applicability statement into the document. He is correct about this aspect. =20 Instead, there were some folks in the group who thought they should discuss how a potential text could look like and Brian included it into the document. This has upset a few folks.=20 When it comes to important things like these the working group always has to make a conscious decision * whether they want to include an applicability statement at all, and=20 * if so, what it should say.=20 What we should also keep in mind is that our document might bounce back from the IESG with the indication that we should resolve the technical issues that prevent applicability of the work in a certain environment.=20 In this weeks 3GPP IETF conference call Cullen has asked Hannu to solicit feedback from the 3GPP about the technical issues that prevent the work being used in the cellular environment. He very well understands that the 3GPP is working on IMS and has crafted many things on their own.=20 Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of ext Edge, Stephen >Sent: 05 May, 2009 06:19 >To: Winterbottom, James; Gellens, Randall; Spencer Dawkins;=20 >Hardie,Ted; Dawson, Martin; BernardAboba; Thomson, Martin;=20 >ecrit@ietf.org >Subject: Re: [Ecrit] PhoneBCP > >Perhaps "mostly harmless" then? > >Note that we are having this discussion now as a result of a=20 >previous discussion concerning the suitability of the Ecrit=20 >solution for any type of public IP access. Those contending=20 >that the solution is suitable are (by and large) the ones now=20 >objecting to including the statement although they were not=20 >objecting just over 5 weeks ago when the statement was=20 >introduced as a means of settling the first discussion. Those=20 >contending that the solution is not universally suitable are=20 >(as far as I am aware) prepared to drop that issue (at least=20 >as regards having the solution go through last call) if the=20 >statement is included. > >If the statement is in the end removed, we may find ourselves=20 >back again to the first discussion. If that happens, I will=20 >consider the solution fair game for some more specific and=20 >detailed criticism than has so far been provided - since after=20 >all, any solution that claims universal applicability is=20 >setting itself up as rather large and inviting target. > >Kind Regards > >Stephen >-----Original Message----- >From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] >Sent: Monday, May 04, 2009 5:33 PM >To: Gellens, Randall; Spencer Dawkins; Hardie, Ted; Dawson,=20 >Martin; Edge, Stephen; BernardAboba; Thomson, Martin; ecrit@ietf.org >Subject: RE: [Ecrit] PhoneBCP > >There was no consensus to add the text, whether the wording is=20 >a compromise is irrelevant at this stage. It was added without=20 >consensus and needs to be removed. > >Cheers >James > > >-----Original Message----- >From: Randall Gellens [mailto:randy@qualcomm.com] >Sent: Tuesday, 5 May 2009 10:29 AM >To: Winterbottom, James; Spencer Dawkins; Ted Hardie; Dawson,=20 >Martin; Edge,Stephen; BernardAboba; Thomson, Martin; ecrit@ietf.org >Subject: Re: [Ecrit] PhoneBCP > >At 7:16 PM -0500 5/4/09, James Winterbottom wrote: > >> Under the same reasoning Randy, since there was never consensus in >the >> WG to add it, > >There may not have been a formal consensus call, but there was=20 >significant discussion on the list, and my impression was that=20 >we had general agreement to add it. > >> it should never have been added, and since no real justification=20 >> for its inclusion has been provided, > >There has been much justification with detailed reasoning for=20 >adding it. > >> we should revert back >> to the previous version of the document and proceed to last=20 >call the =20 >> document. > >It was added as a compromise based on the discussion in SFO=20 >and on the list subsequently. It's a compromise, like much of=20 >the text we publish. > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >Behalf >> Of Randall Gellens >> Sent: Tuesday, 5 May 2009 8:26 AM >> To: Spencer Dawkins; Ted Hardie; Dawson, Martin; Edge,Stephen; =20 >> BernardAboba; Thomson, Martin; ecrit@ietf.org; RandallGellens >> Subject: Re: [Ecrit] PhoneBCP >> >> At 5:00 PM -0500 5/4/09, Spencer Dawkins wrote: >> >>>> The statement added in -09 is a compromise; even the=20 >most fervent =20 >>>> argument against it comes down to "it isn't needed". Given the =20 >>>> choice between a compromise statement that clearly does no harm, =20 >>>> and, depending on one's viewpoint is either vitally needed or =20 >>>> redundant, it seem clear that we should progress the=20 >document with =20 >>>> the text in it. >>> >>> I'm having a difficult time thinking of "clearly does no=20 >harm" as =20 >>> sufficient justification for including text in a document that's =20 >>> still tagged as a BCP... >> >> I never said "clearly does no harm" is *sufficient*=20 >justification for =20 >> adding it, rather, it's justification for not removing it given the =20 >> arguments for it. There are a number of people who have made =20 >> well-reasoned and detailed cases for why this text is needed; since =20 >> it is already a compromise that does no harm, the choice to=20 >leave it =20 >> in seems clear. >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself >only >> -------------- Randomly selected tag: --------------- Procedures! =20 >> Of course, that's what you'd use with a *sophisticated* >> machine like this. Procedures. --'Ceaser Smith' in=20 >_Hot_Millions_ >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >>=20 >> >--------------------------------------------------------------- >--------- >------------------------ >> This message is for the designated recipient only and may contain=20 >> privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender =20 >> immediately and delete the original. Any unauthorized use of this=20 >> email is prohibited. >>=20 >> >--------------------------------------------------------------- >--------- >------------------------ >> [mf2] >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > >-- >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly selected tag: --------------- I have=20 >made it a rule, whenever in my power, to avoid becoming the=20 >draughtsman of papers to be reviewed by a public body. > --Benjamin Franklin > >--------------------------------------------------------------- >--------------------------------- >This message is for the designated recipient only and may=20 >contain privileged, proprietary, or otherwise private information. =20 >If you have received it in error, please notify the sender=20 >immediately and delete the original. Any unauthorized use of=20 >this email is prohibited. >--------------------------------------------------------------- >--------------------------------- >[mf2] > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From jbakker@rim.com Wed May 6 20:06:56 2009 Return-Path: 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 D4B433A69C4 for ; Wed, 6 May 2009 20:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.053 X-Spam-Level: X-Spam-Status: No, score=-5.053 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 etGzs8C3z3mv for ; Wed, 6 May 2009 20:06:55 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 27EFA3A6834 for ; Wed, 6 May 2009 20:06:54 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id 72A52585DE; Wed, 6 May 2009 23:08:21 -0400 (EDT) X-AuditID: 0a401fcb-a3a6dbb000003e39-88-4a0250a5620c Received: from XCH39YKF.rim.net (unknown [10.64.31.40]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id 2CEBD585DB; Wed, 6 May 2009 23:08:21 -0400 (EDT) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 May 2009 23:08:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" content-transfer-encoding: quoted-printable Date: Wed, 6 May 2009 22:08:17 -0500 Message-ID: In-Reply-To: <0913B6CD18F370498CD65864CF254E90097B3549@zharhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt thread-index: AcmgoqEwGgnKMKiDS8KCxn9Oay/pdQnYyfBwAayUNIA= References: <499D6530.9040208@ericsson.com><0913B6CD18F370498CD65864CF254E9008DA24B2@zharhxm1.corp.nortel.com><49B4F019.2020904@ericsson.com> <0913B6CD18F370498CD65864CF254E90097B3549@zharhxm1.corp.nortel.com> From: "John-Luc Bakker" To: "Milan Patel" , "Gonzalo Camarillo" X-OriginalArrivalTime: 07 May 2009 03:08:21.0117 (UTC) FILETIME=[13B15AD0:01C9CEC1] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: ecrit@ietf.org Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.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: , X-List-Received-Date: Thu, 07 May 2009 03:06:56 -0000 Hi Milan, I would like to pick up on Gonzalo's comment below: > The document does not talk about backwards compatibility. What happens > if the registrar does not understand the 'sos' parameter? Will it do > the right thing? Will the UAC detect the failure? Is there a need to > define an option tag?... the document should address these points. In the meanwhile, the document does talk about backwards compatibility. However, the legacy registrar will do the only (right) thing it can do but from a perspective of the UE that might not be the anticipated (right) thing. It is my understanding that an emergency registration can happen at any time and a UE is not required to immediately follow up the successful registration with an emergency call or tear down the emergency registration after the emergency call. Suppose a UAC has one public user identity and it performs a normal registration with some feature tags. Subsequently, the same UAC performs an emergency registration with different feature tags. Would the legacy registrar "refresh" the binding, then the S-CSCF would apply "emergency" feature tags to all session requests. An option tag would prevent this. If in agreement, I suggest the following changes to the draft (between and tags): 4.1. REGISTER Request When the UA sends a REGISTER request for emergency registration, the "sos" URI parameter MUST be appended to the URI in the Contact Header and the option-tag "e-reg" must be included in the Proxy-Require and Require header. This serves as an indication to the registrar that the request is for emergency registration and it is only accepted if emergency registration is supported. Example: Contact: "Alice" ;q=3D0.7; expires=3D3600 In the event that more than one Contact header field is included in the REGISTER request, only the contact addresses that include the "sos" URI parameter shall be considered as emergency registered contact addresses. Upon receipt of a 420 (Bad Extension) response the UAC will use an existing registration or initiate another registration. 4.3. Backwards compatibility issues The backwards compatibility scenario considered in this document is where a legacy registrar does not support the "sos" URI parameter. This document registers an option tag with IANA in section 6.2. Inclusion of the option tag will prevent a legacy registrar from handling the request. 6. IANA Considerations 6.2 SIP URI parameter This specification defines one new SIP URI parameter, as per the registry created by RFC 3969 [RFC3969] Parameter Name: sos Predefined Values: none Reference: [RFCXXXX] [NOTE TO IANA: Please replace XXXX with the RFC number of this specification.] 6.2 SIP Option Tag This specification registers a new SIP option tag, as per the guidelines in Section 27.1 of RFC 3261 [RFC3261]. Name: e-reg Description: This option tag is used to identify the emergency registration extension. When used in a Supported header, it indicates that a User Agent understands the extension. When used in a Require header field of a REGISTER request, it indicates that the registrar is not expected to process the registration unless it supports the emergency registration extension. Regards, John-Luc -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Milan Patel Sent: Tuesday, April 28, 2009 8:36 AM To: Gonzalo Camarillo Cc: ecrit@ietf.org Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Hi Gonzalo, Version 4 of draft-patel-ecrit-sos-parameter addresses all the comments you provided in the expert review. Please can you confirm that you are OK with its contents and that all the issues you had previously highlighted are now resolved. http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-04 Best regards, Milan Milan Patel Carrier Networks Core Standards Nortel milanpa@nortel.com Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 / ESN 748 9261 For the Companies listed below, The Institute of Chartered Accountants in England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act 1986. The affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as agents of the Companies only and without personal liability. The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel Networks AB; Nortel Networks International Finance & Holding BV -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] Sent: 09 March 2009 10:32 To: Patel, Milan (MOP:EP10) Cc: ecrit@ietf.org; Hannes Tschofenig Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Hi, the problem with this text is that it specifies behavior for entities that will not implement this specification. The new section should describe how a legacy registrar will handle, following regular SIP rules, a REGISTER request with the sos parameter. However, it cannot specify extra behavior for such a legacy registrar. That is the whole point of backwards compatibility: to support unchanged legacy applications that will not implement the new functionality. In any case, I believe you can use most of the text you proposed below. It just needs to be rephrased so that it is more descriptive and non normative. Thanks, Gonzalo Milan Patel wrote: > Folks, > > In response to Gonzalo's comment on backwards compatibility, I propose > a subclause "4.3 Backwards compatibility issues" as follows: > > ---------------------------------------------------------------------- > -- > ---------------------------------- > 4.3 Backwards compatibility issues > The backwards compatibility scenario considered in this document is > where the registrar does not support the "sos" URI parameter. In this > case, if the registrar receives a REGISTER request that includes the > "sos" URI parameter in the Contact header, the registrar MUST proceed > with registration procedures and silently ignore the URI-parameter in > accordance with RFC 3261. This ensures the user is registered and thus > can successfully initiate an emergency call. > > The drawback of proceeding with registration is if the > address-of-record is barred or has roaming restrictions applied, then > these restrictions will not be lifted and thus registration will be > unsuccessful. This may limit the UAC's ability to successfully place an emergency call. > > If registration is successful, the registrar shall return a 200 (OK) > response to the UAC and does not include the "sos" URI parameter in > the Contact header. The UAC is aware of its registered contact address > and address-of-record, however, cannot distinguish between this > registration and a non-emergency registration. > ---------------------------------------------------------------------- > -- > -------------------------------------- > > Comments/feedback/suggestions for improvement are appreciated. I will > address Gonzalo's other comments in version -04 of the draft as well. > > Best regards, > Milan > > Milan Patel > Carrier Networks Core Standards > Nortel > milanpa@nortel.com > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 / > ESN 748 9261 > > For the Companies listed below, The Institute of Chartered Accountants > in England and Wales authorises A R Bloom, S Harris and C Hill to act > as Insolvency Practitioners under section 390(2)(a) of the Insolvency > Act > 1986 and the Association of Chartered Certified Accountants authorises > A M Hudson to act as an Insolvency Practitioner under section > 390(2)(a) of the Insolvency Act 1986. > > The affairs, business and property of the Companies are being managed > by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill > who act as agents of the Companies only and without personal liability. > > The Companies are Nortel Networks UK Limited; Nortel Networks SA; > Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel > Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; > Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel > Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks > Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel > Networks Romania SRL; Nortel Networks AB; Nortel Networks > International Finance & Holding BV > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Gonzalo Camarillo > Sent: 19 February 2009 13:57 > To: ecrit@ietf.org > Subject: [Ecrit] Expert review of > draft-patel-ecrit-sos-parameter-03.txt > > Folks, > > I have been asked to perform an expert review of the following draft: > > http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt > > The approach taken by the draft seems OK in general. I have a few > comments though: > > The requirement in Section 3 is too specific because it already > assumes that the solution will be an indication in the SIP header > fields. The requirement does not need to make that assumption. I would > remove "by providing an appropriate indication in the SIP header fields". > > In Section 5, the reference to RFC 2234 should be replaced with one to > RFC 5234. > > Also in Section 5, the formal syntax should be rewritten so that it is > compatible with the ABNF in RFC 3261. RFC 3261 already defines > uri-parameter as follows: > > uri-parameter =3D transport-param / user-param / method-param > / ttl-param / maddr-param / lr-param / > other-param > > other-param =3D pname [ "=3D" pvalue ] > pname =3D 1*paramchar > pvalue =3D 1*paramchar > > This document should simply define a new value for pname. > > The document does not talk about backwards compatibility. What happens > if the registrar does not understand the 'sos' parameter? Will it do > the right thing? Will the UAC detect the failure? Is there a need to > define an option tag?... the document should address these points. > > Cheers, > > Gonzalo > > _______________________________________________ > 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 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From christer.holmberg@ericsson.com Wed May 6 22:03:40 2009 Return-Path: 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 B9FA928C26C for ; Wed, 6 May 2009 22:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.859 X-Spam-Level: X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[AWL=0.390, 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 XMB2Ck7Sv8J0 for ; Wed, 6 May 2009 22:03:39 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 36BFB28B23E for ; Wed, 6 May 2009 22:03:37 -0700 (PDT) X-AuditID: c1b4fb3c-b7b19ae000006089-d4-4a026bff3837 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 61.67.24713.FFB620A4; Thu, 7 May 2009 07:05:03 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 May 2009 07:05:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 May 2009 07:05:01 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Thread-Index: AcmgoqEwGgnKMKiDS8KCxn9Oay/pdQnYyfBwAayUNIAABijoAA== References: <499D6530.9040208@ericsson.com><0913B6CD18F370498CD65864CF254E9008DA24B2@zharhxm1.corp.nortel.com><49B4F019.2020904@ericsson.com><0913B6CD18F370498CD65864CF254E90097B3549@zharhxm1.corp.nortel.com> From: "Christer Holmberg" To: "John-Luc Bakker" , "Milan Patel" , "Gonzalo Camarillo" X-OriginalArrivalTime: 07 May 2009 05:05:02.0857 (UTC) FILETIME=[610E1790:01C9CED1] X-Brightmail-Tracker: AAAAAA== Cc: ecrit@ietf.org Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.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: , X-List-Received-Date: Thu, 07 May 2009 05:03:40 -0000 Hi, My comments between the and tags.=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of John-Luc Bakker > Sent: 7. toukokuuta 2009 6:08 > To: Milan Patel; Gonzalo Camarillo > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Expert review of=20 > draft-patel-ecrit-sos-parameter-03.txt >=20 > Hi Milan, >=20 > I would like to pick up on Gonzalo's comment below: >=20 > > The document does not talk about backwards compatibility.=20 > What happens=20 > > if the registrar does not understand the 'sos' parameter?=20 > Will it do=20 > > the right thing? Will the UAC detect the failure? Is there=20 > a need to=20 > > define an option tag?... the document should address these points. >=20 > In the meanwhile, the document does talk about backwards=20 > compatibility. >=20 > However, the legacy registrar will do the only (right) thing=20 > it can do but from a perspective of the UE that might not be=20 > the anticipated > (right) thing. >=20 > It is my understanding that an emergency registration can=20 > happen at any time and a UE is not required to immediately=20 > follow up the successful registration with an emergency call=20 > or tear down the emergency registration after the emergency call.=20 >=20 > Suppose a UAC has one public user identity and it performs a=20 > normal registration with some feature tags. Subsequently, the=20 > same UAC performs an emergency registration with different=20 > feature tags. Would the legacy registrar "refresh" the=20 > binding, then the S-CSCF would apply "emergency" > feature tags to all session requests. >=20 > An option tag would prevent this. >=20 > If in agreement, I suggest the following changes to the draft=20 > (between and tags): >=20 > 4.1. REGISTER Request >=20 > When the UA sends a REGISTER request for emergency=20 > registration, the > "sos" URI parameter MUST be appended to the URI in the Contact > Header and the option-tag "e-reg" must be included in=20 > the Proxy-Require and Require header. This serves as=20 > an indication to the > registrar that the > request is for emergency registration and it is only=20 > accepted if emergency registration is supported. >=20 > Example: >=20 > Contact: "Alice" ;q=3D0.7; = expires=3D3600 >=20 > In the event that more than one Contact header field is included in > the REGISTER request, only the contact addresses that include the > "sos" URI parameter shall be considered as emergency registered > contact addresses. >=20 > > Upon receipt of a 420 (Bad Extension) response the UAC will=20 > use an existing registration or initiate another registration. > Why would you need to insert the option-tag in the Proxy-Require header) Why do you need intermediates to support the "sos" parameter? Isn't it enough if the registrar, which in this case acts as UAS (and therefor applies the Require header) support the "sos" parameter? Regards, Christer > 4.3. Backwards compatibility issues >=20 > The backwards compatibility scenario considered in this document is > where a legacy registrar does not support the "sos" URI parameter. >=20 > > This document registers an option tag with IANA in section 6.2. > Inclusion of the option tag will prevent a legacy registrar=20 > from handling the request. > >=20 > 6. IANA Considerations > > 6.2 SIP URI parameter > > This specification defines one new SIP URI parameter, as per the > registry created by RFC 3969 [RFC3969] >=20 > Parameter Name: sos >=20 > Predefined Values: none >=20 > Reference: [RFCXXXX] >=20 > [NOTE TO IANA: Please replace XXXX with the RFC number of this > specification.] > > 6.2 SIP Option Tag >=20 > This specification registers a new SIP option tag, as per the=20 > guidelines in Section 27.1 of RFC 3261 [RFC3261]. >=20 > Name: e-reg >=20 > Description: This option tag is used to identify the=20 > emergency registration extension. When used in a Supported=20 > header, it indicates that a User Agent understands the=20 > extension. When used in a Require header field of a REGISTER=20 > request, it indicates that the registrar is not expected to=20 > process the registration unless it supports the emergency=20 > registration extension. > >=20 > Regards, >=20 > John-Luc >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Milan Patel > Sent: Tuesday, April 28, 2009 8:36 AM > To: Gonzalo Camarillo > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Expert review of > draft-patel-ecrit-sos-parameter-03.txt >=20 > Hi Gonzalo, >=20 > Version 4 of draft-patel-ecrit-sos-parameter addresses all=20 > the comments you provided in the expert review. Please can=20 > you confirm that you are OK with its contents and that all=20 > the issues you had previously highlighted are now resolved. > http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-04 > Best regards, > Milan >=20 > Milan Patel > Carrier Networks Core Standards > Nortel > milanpa@nortel.com > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053=20 > 9261 / ESN 748 9261 >=20 > For the Companies listed below, The Institute of Chartered=20 > Accountants in England and Wales authorises A R Bloom, S=20 > Harris and C Hill to act as Insolvency Practitioners under=20 > section 390(2)(a) of the Insolvency Act > 1986 and the Association of Chartered Certified Accountants=20 > authorises A M Hudson to act as an Insolvency Practitioner=20 > under section 390(2)(a) of the Insolvency Act 1986. >=20 > The affairs, business and property of the Companies are being=20 > managed by the Joint Administrators, A R Bloom, S Harris, AM=20 > Hudson and C Hill who act as agents of the Companies only and=20 > without personal liability. >=20 > The Companies are Nortel Networks UK Limited; Nortel Networks=20 > SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks=20 > NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks=20 > Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks=20 > (Austria) GmbH; Nortel Networks sro; Nortel Networks=20 > Engineering Service Kft; Nortel Networks Portugal SA; Nortel=20 > Networks Slovensko sro; Nortel Networks Oy; Nortel Networks=20 > Romania SRL; Nortel Networks AB; Nortel Networks=20 > International Finance & Holding BV >=20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: 09 March 2009 10:32 > To: Patel, Milan (MOP:EP10) > Cc: ecrit@ietf.org; Hannes Tschofenig > Subject: Re: [Ecrit] Expert review of > draft-patel-ecrit-sos-parameter-03.txt >=20 > Hi, >=20 > the problem with this text is that it specifies behavior for=20 > entities that will not implement this specification. The new=20 > section should describe how a legacy registrar will handle,=20 > following regular SIP rules, a REGISTER request with the sos=20 > parameter. However, it cannot specify extra behavior for such=20 > a legacy registrar. That is the whole point of backwards=20 > compatibility: to support unchanged legacy applications that=20 > will not implement the new functionality. >=20 > In any case, I believe you can use most of the text you=20 > proposed below.=20 > It just needs to be rephrased so that it is more descriptive=20 > and non normative. >=20 > Thanks, >=20 > Gonzalo >=20 > Milan Patel wrote: > > Folks, > >=20 > > In response to Gonzalo's comment on backwards=20 > compatibility, I propose >=20 > > a subclause "4.3 Backwards compatibility issues" as follows: > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > > ---------------------------------- > > 4.3 Backwards compatibility issues > > The backwards compatibility scenario considered in this document is=20 > > where the registrar does not support the "sos" URI=20 > parameter. In this=20 > > case, if the registrar receives a REGISTER request that=20 > includes the=20 > > "sos" URI parameter in the Contact header, the registrar=20 > MUST proceed=20 > > with registration procedures and silently ignore the=20 > URI-parameter in=20 > > accordance with RFC 3261. This ensures the user is=20 > registered and thus >=20 > > can successfully initiate an emergency call. > >=20 > > The drawback of proceeding with registration is if the=20 > > address-of-record is barred or has roaming restrictions=20 > applied, then=20 > > these restrictions will not be lifted and thus registration will be=20 > > unsuccessful. This may limit the UAC's ability to successfully place > an emergency call. > >=20 > > If registration is successful, the registrar shall return a=20 > 200 (OK)=20 > > response to the UAC and does not include the "sos" URI parameter in=20 > > the Contact header. The UAC is aware of its registered=20 > contact address >=20 > > and address-of-record, however, cannot distinguish between this=20 > > registration and a non-emergency registration. > >=20 > ---------------------------------------------------------------------- > > -- > > -------------------------------------- > >=20 > > Comments/feedback/suggestions for improvement are=20 > appreciated. I will=20 > > address Gonzalo's other comments in version -04 of the=20 > draft as well. > >=20 > > Best regards, > > Milan > >=20 > > Milan Patel > > Carrier Networks Core Standards > > Nortel > > milanpa@nortel.com > > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 /=20 > > ESN 748 9261 > >=20 > > For the Companies listed below, The Institute of Chartered=20 > Accountants >=20 > > in England and Wales authorises A R Bloom, S Harris and C=20 > Hill to act=20 > > as Insolvency Practitioners under section 390(2)(a) of the=20 > Insolvency=20 > > Act > > 1986 and the Association of Chartered Certified Accountants=20 > authorises >=20 > > A M Hudson to act as an Insolvency Practitioner under section > > 390(2)(a) of the Insolvency Act 1986. > >=20 > > The affairs, business and property of the Companies are=20 > being managed=20 > > by the Joint Administrators, A R Bloom, S Harris, AM Hudson=20 > and C Hill >=20 > > who act as agents of the Companies only and without personal > liability. > >=20 > > The Companies are Nortel Networks UK Limited; Nortel Networks SA;=20 > > Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel=20 > > Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo;=20 > > Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel=20 > > Networks sro; Nortel Networks Engineering Service Kft;=20 > Nortel Networks >=20 > > Portugal SA; Nortel Networks Slovensko sro; Nortel Networks=20 > Oy; Nortel >=20 > > Networks Romania SRL; Nortel Networks AB; Nortel Networks=20 > > International Finance & Holding BV > >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf >=20 > > Of Gonzalo Camarillo > > Sent: 19 February 2009 13:57 > > To: ecrit@ietf.org > > Subject: [Ecrit] Expert review of > > draft-patel-ecrit-sos-parameter-03.txt > >=20 > > Folks, > >=20 > > I have been asked to perform an expert review of the=20 > following draft: > >=20 > > http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt > >=20 > > The approach taken by the draft seems OK in general. I have a few=20 > > comments though: > >=20 > > The requirement in Section 3 is too specific because it already=20 > > assumes that the solution will be an indication in the SIP header=20 > > fields. The requirement does not need to make that=20 > assumption. I would >=20 > > remove "by providing an appropriate indication in the SIP header > fields". > >=20 > > In Section 5, the reference to RFC 2234 should be replaced=20 > with one to >=20 > > RFC 5234. > >=20 > > Also in Section 5, the formal syntax should be rewritten so=20 > that it is >=20 > > compatible with the ABNF in RFC 3261. RFC 3261 already defines=20 > > uri-parameter as follows: > >=20 > > uri-parameter =3D transport-param / user-param / method-param > > / ttl-param / maddr-param / lr-param /=20 > > other-param > >=20 > > other-param =3D pname [ "=3D" pvalue ] > > pname =3D 1*paramchar > > pvalue =3D 1*paramchar > >=20 > > This document should simply define a new value for pname. > >=20 > > The document does not talk about backwards compatibility.=20 > What happens >=20 > > if the registrar does not understand the 'sos' parameter?=20 > Will it do=20 > > the right thing? Will the UAC detect the failure? Is there=20 > a need to=20 > > define an option tag?... the document should address these points. > >=20 > > Cheers, > >=20 > > Gonzalo > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain=20 > confidential information, privileged material (including=20 > material protected by the solicitor-client or other=20 > applicable privileges), or constitute non-public information.=20 > Any use of this information by anyone other than the intended=20 > recipient is prohibited. If you have received this=20 > transmission in error, please immediately reply to the sender=20 > and delete this information from your system. Use,=20 > dissemination, distribution, or reproduction of this=20 > transmission by unintended recipients is not authorized and=20 > may be unlawful. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From MILANPA@nortel.com Thu May 7 03:42:51 2009 Return-Path: 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 11A2B3A6E54 for ; Thu, 7 May 2009 03:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.436, 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 O1wqUp4TQfJk for ; Thu, 7 May 2009 03:42:49 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id F0FD73A6D5F for ; Thu, 7 May 2009 03:42:48 -0700 (PDT) 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 n47Ai5g13666; Thu, 7 May 2009 10:44:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 May 2009 11:43:31 +0100 Message-ID: <0913B6CD18F370498CD65864CF254E9009927A32@zharhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Thread-Index: AcmgoqEwGgnKMKiDS8KCxn9Oay/pdQnYyfBwAayUNIAABijoAAAKf6qw References: <499D6530.9040208@ericsson.com><0913B6CD18F370498CD65864CF254E9008DA24B2@zharhxm1.corp.nortel.com><49B4F019.2020904@ericsson.com><0913B6CD18F370498CD65864CF254E90097B3549@zharhxm1.corp.nortel.com> From: "Milan Patel" To: "Christer Holmberg" , "John-Luc Bakker" , "Gonzalo Camarillo" Cc: ecrit@ietf.org Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.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: , X-List-Received-Date: Thu, 07 May 2009 10:42:51 -0000 Hi John-Luc, Firstly, it is my understanding that emergency registration occurs when the emergency call request is detected by the UE (e.g. user dials 911). The duration of this emergency registration is also not specified to be the same as that of a normal registration.=20 Secondly, if the registrar were to reject the emergency registration because it did not support the "sos" URI parameter, and no other registration existed, the UE would have to initiate an unauthenticated emergency call. Surely, it would make more sense to either register the user, even if it means overriding an existing non-emergency registration or if using 3GPP IMS, the network can return a 380 response to the UE, forcing it to use for example the CS domain.=20 Upon receiving the 420 response, if the UAC attempts registration again, then this registration would be treated as a non-emergency registration. This is the same result as ignoring the URI parameter if the registrar did not support it.=20 Therefore, I still think the current procedures are sufficient.=20 Regards, Milan Milan Patel Carrier Networks Core Standards Nortel milanpa@nortel.com Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 / ESN 748 9261 For the Companies listed below, The Institute of Chartered Accountants in England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act 1986. The affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as agents of the Companies only and without personal liability. The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel Networks AB; Nortel Networks International Finance & Holding BV -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: 07 May 2009 06:05 To: John-Luc Bakker; Patel, Milan (MOP:EP10); Gonzalo Camarillo Cc: ecrit@ietf.org Subject: RE: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Hi, My comments between the and tags.=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of John-Luc Bakker > Sent: 7. toukokuuta 2009 6:08 > To: Milan Patel; Gonzalo Camarillo > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Expert review of=20 > draft-patel-ecrit-sos-parameter-03.txt >=20 > Hi Milan, >=20 > I would like to pick up on Gonzalo's comment below: >=20 > > The document does not talk about backwards compatibility.=20 > What happens=20 > > if the registrar does not understand the 'sos' parameter?=20 > Will it do=20 > > the right thing? Will the UAC detect the failure? Is there=20 > a need to=20 > > define an option tag?... the document should address these points. >=20 > In the meanwhile, the document does talk about backwards=20 > compatibility. >=20 > However, the legacy registrar will do the only (right) thing=20 > it can do but from a perspective of the UE that might not be=20 > the anticipated > (right) thing. >=20 > It is my understanding that an emergency registration can=20 > happen at any time and a UE is not required to immediately=20 > follow up the successful registration with an emergency call=20 > or tear down the emergency registration after the emergency call.=20 >=20 > Suppose a UAC has one public user identity and it performs a=20 > normal registration with some feature tags. Subsequently, the=20 > same UAC performs an emergency registration with different=20 > feature tags. Would the legacy registrar "refresh" the=20 > binding, then the S-CSCF would apply "emergency" > feature tags to all session requests. >=20 > An option tag would prevent this. >=20 > If in agreement, I suggest the following changes to the draft=20 > (between and tags): >=20 > 4.1. REGISTER Request >=20 > When the UA sends a REGISTER request for emergency=20 > registration, the > "sos" URI parameter MUST be appended to the URI in the Contact > Header and the option-tag "e-reg" must be included in=20 > the Proxy-Require and Require header. This serves as=20 > an indication to the > registrar that the > request is for emergency registration and it is only=20 > accepted if emergency registration is supported. >=20 > Example: >=20 > Contact: "Alice" ;q=3D0.7; = expires=3D3600 >=20 > In the event that more than one Contact header field is included in > the REGISTER request, only the contact addresses that include the > "sos" URI parameter shall be considered as emergency registered > contact addresses. >=20 > > Upon receipt of a 420 (Bad Extension) response the UAC will=20 > use an existing registration or initiate another registration. > Why would you need to insert the option-tag in the Proxy-Require header) Why do you need intermediates to support the "sos" parameter? Isn't it enough if the registrar, which in this case acts as UAS (and therefor applies the Require header) support the "sos" parameter? Regards, Christer > 4.3. Backwards compatibility issues >=20 > The backwards compatibility scenario considered in this document is > where a legacy registrar does not support the "sos" URI parameter. >=20 > > This document registers an option tag with IANA in section 6.2. > Inclusion of the option tag will prevent a legacy registrar=20 > from handling the request. > >=20 > 6. IANA Considerations > > 6.2 SIP URI parameter > > This specification defines one new SIP URI parameter, as per the > registry created by RFC 3969 [RFC3969] >=20 > Parameter Name: sos >=20 > Predefined Values: none >=20 > Reference: [RFCXXXX] >=20 > [NOTE TO IANA: Please replace XXXX with the RFC number of this > specification.] > > 6.2 SIP Option Tag >=20 > This specification registers a new SIP option tag, as per the=20 > guidelines in Section 27.1 of RFC 3261 [RFC3261]. >=20 > Name: e-reg >=20 > Description: This option tag is used to identify the=20 > emergency registration extension. When used in a Supported=20 > header, it indicates that a User Agent understands the=20 > extension. When used in a Require header field of a REGISTER=20 > request, it indicates that the registrar is not expected to=20 > process the registration unless it supports the emergency=20 > registration extension. > >=20 > Regards, >=20 > John-Luc >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Milan Patel > Sent: Tuesday, April 28, 2009 8:36 AM > To: Gonzalo Camarillo > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Expert review of > draft-patel-ecrit-sos-parameter-03.txt >=20 > Hi Gonzalo, >=20 > Version 4 of draft-patel-ecrit-sos-parameter addresses all=20 > the comments you provided in the expert review. Please can=20 > you confirm that you are OK with its contents and that all=20 > the issues you had previously highlighted are now resolved. > http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-04 > Best regards, > Milan >=20 > Milan Patel > Carrier Networks Core Standards > Nortel > milanpa@nortel.com > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053=20 > 9261 / ESN 748 9261 >=20 > For the Companies listed below, The Institute of Chartered=20 > Accountants in England and Wales authorises A R Bloom, S=20 > Harris and C Hill to act as Insolvency Practitioners under=20 > section 390(2)(a) of the Insolvency Act > 1986 and the Association of Chartered Certified Accountants=20 > authorises A M Hudson to act as an Insolvency Practitioner=20 > under section 390(2)(a) of the Insolvency Act 1986. >=20 > The affairs, business and property of the Companies are being=20 > managed by the Joint Administrators, A R Bloom, S Harris, AM=20 > Hudson and C Hill who act as agents of the Companies only and=20 > without personal liability. >=20 > The Companies are Nortel Networks UK Limited; Nortel Networks=20 > SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks=20 > NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks=20 > Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks=20 > (Austria) GmbH; Nortel Networks sro; Nortel Networks=20 > Engineering Service Kft; Nortel Networks Portugal SA; Nortel=20 > Networks Slovensko sro; Nortel Networks Oy; Nortel Networks=20 > Romania SRL; Nortel Networks AB; Nortel Networks=20 > International Finance & Holding BV >=20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: 09 March 2009 10:32 > To: Patel, Milan (MOP:EP10) > Cc: ecrit@ietf.org; Hannes Tschofenig > Subject: Re: [Ecrit] Expert review of > draft-patel-ecrit-sos-parameter-03.txt >=20 > Hi, >=20 > the problem with this text is that it specifies behavior for=20 > entities that will not implement this specification. The new=20 > section should describe how a legacy registrar will handle,=20 > following regular SIP rules, a REGISTER request with the sos=20 > parameter. However, it cannot specify extra behavior for such=20 > a legacy registrar. That is the whole point of backwards=20 > compatibility: to support unchanged legacy applications that=20 > will not implement the new functionality. >=20 > In any case, I believe you can use most of the text you=20 > proposed below.=20 > It just needs to be rephrased so that it is more descriptive=20 > and non normative. >=20 > Thanks, >=20 > Gonzalo >=20 > Milan Patel wrote: > > Folks, > >=20 > > In response to Gonzalo's comment on backwards=20 > compatibility, I propose >=20 > > a subclause "4.3 Backwards compatibility issues" as follows: > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > > ---------------------------------- > > 4.3 Backwards compatibility issues > > The backwards compatibility scenario considered in this document is=20 > > where the registrar does not support the "sos" URI=20 > parameter. In this=20 > > case, if the registrar receives a REGISTER request that=20 > includes the=20 > > "sos" URI parameter in the Contact header, the registrar=20 > MUST proceed=20 > > with registration procedures and silently ignore the=20 > URI-parameter in=20 > > accordance with RFC 3261. This ensures the user is=20 > registered and thus >=20 > > can successfully initiate an emergency call. > >=20 > > The drawback of proceeding with registration is if the=20 > > address-of-record is barred or has roaming restrictions=20 > applied, then=20 > > these restrictions will not be lifted and thus registration will be=20 > > unsuccessful. This may limit the UAC's ability to successfully place > an emergency call. > >=20 > > If registration is successful, the registrar shall return a=20 > 200 (OK)=20 > > response to the UAC and does not include the "sos" URI parameter in=20 > > the Contact header. The UAC is aware of its registered=20 > contact address >=20 > > and address-of-record, however, cannot distinguish between this=20 > > registration and a non-emergency registration. > >=20 > ---------------------------------------------------------------------- > > -- > > -------------------------------------- > >=20 > > Comments/feedback/suggestions for improvement are=20 > appreciated. I will=20 > > address Gonzalo's other comments in version -04 of the=20 > draft as well. > >=20 > > Best regards, > > Milan > >=20 > > Milan Patel > > Carrier Networks Core Standards > > Nortel > > milanpa@nortel.com > > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 /=20 > > ESN 748 9261 > >=20 > > For the Companies listed below, The Institute of Chartered=20 > Accountants >=20 > > in England and Wales authorises A R Bloom, S Harris and C=20 > Hill to act=20 > > as Insolvency Practitioners under section 390(2)(a) of the=20 > Insolvency=20 > > Act > > 1986 and the Association of Chartered Certified Accountants=20 > authorises >=20 > > A M Hudson to act as an Insolvency Practitioner under section > > 390(2)(a) of the Insolvency Act 1986. > >=20 > > The affairs, business and property of the Companies are=20 > being managed=20 > > by the Joint Administrators, A R Bloom, S Harris, AM Hudson=20 > and C Hill >=20 > > who act as agents of the Companies only and without personal > liability. > >=20 > > The Companies are Nortel Networks UK Limited; Nortel Networks SA;=20 > > Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel=20 > > Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo;=20 > > Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel=20 > > Networks sro; Nortel Networks Engineering Service Kft;=20 > Nortel Networks >=20 > > Portugal SA; Nortel Networks Slovensko sro; Nortel Networks=20 > Oy; Nortel >=20 > > Networks Romania SRL; Nortel Networks AB; Nortel Networks=20 > > International Finance & Holding BV > >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf >=20 > > Of Gonzalo Camarillo > > Sent: 19 February 2009 13:57 > > To: ecrit@ietf.org > > Subject: [Ecrit] Expert review of > > draft-patel-ecrit-sos-parameter-03.txt > >=20 > > Folks, > >=20 > > I have been asked to perform an expert review of the=20 > following draft: > >=20 > > http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt > >=20 > > The approach taken by the draft seems OK in general. I have a few=20 > > comments though: > >=20 > > The requirement in Section 3 is too specific because it already=20 > > assumes that the solution will be an indication in the SIP header=20 > > fields. The requirement does not need to make that=20 > assumption. I would >=20 > > remove "by providing an appropriate indication in the SIP header > fields". > >=20 > > In Section 5, the reference to RFC 2234 should be replaced=20 > with one to >=20 > > RFC 5234. > >=20 > > Also in Section 5, the formal syntax should be rewritten so=20 > that it is >=20 > > compatible with the ABNF in RFC 3261. RFC 3261 already defines=20 > > uri-parameter as follows: > >=20 > > uri-parameter =3D transport-param / user-param / method-param > > / ttl-param / maddr-param / lr-param /=20 > > other-param > >=20 > > other-param =3D pname [ "=3D" pvalue ] > > pname =3D 1*paramchar > > pvalue =3D 1*paramchar > >=20 > > This document should simply define a new value for pname. > >=20 > > The document does not talk about backwards compatibility.=20 > What happens >=20 > > if the registrar does not understand the 'sos' parameter?=20 > Will it do=20 > > the right thing? Will the UAC detect the failure? Is there=20 > a need to=20 > > define an option tag?... the document should address these points. > >=20 > > Cheers, > >=20 > > Gonzalo > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain=20 > confidential information, privileged material (including=20 > material protected by the solicitor-client or other=20 > applicable privileges), or constitute non-public information.=20 > Any use of this information by anyone other than the intended=20 > recipient is prohibited. If you have received this=20 > transmission in error, please immediately reply to the sender=20 > and delete this information from your system. Use,=20 > dissemination, distribution, or reproduction of this=20 > transmission by unintended recipients is not authorized and=20 > may be unlawful. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From jbakker@rim.com Thu May 7 08:21:50 2009 Return-Path: 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 342613A683D for ; Thu, 7 May 2009 08:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.083 X-Spam-Level: X-Spam-Status: No, score=-5.083 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 GJtXtZFc06Tm for ; Thu, 7 May 2009 08:21:46 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id EA7293A6C1F for ; Thu, 7 May 2009 08:21:02 -0700 (PDT) Received: from mhs04ykf.rim.net (unknown [127.0.0.1]) by mhs04ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id 2262C5C358; Thu, 7 May 2009 11:22:30 -0400 (EDT) X-AuditID: 0a666446-a1c9fbb000002ec5-6c-4a02fcb53bf4 Received: from XCH39YKF.rim.net (unknown [10.64.31.40]) by mhs04ykf.rim.net (Symantec Mail Security) with ESMTP id BFE115C28B; Thu, 7 May 2009 11:22:29 -0400 (EDT) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 11:22:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" content-transfer-encoding: quoted-printable Date: Thu, 7 May 2009 10:22:26 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt thread-index: AcmgoqEwGgnKMKiDS8KCxn9Oay/pdQnYyfBwAayUNIAABijoAAAVZF7g References: <499D6530.9040208@ericsson.com><0913B6CD18F370498CD65864CF254E9008DA24B2@zharhxm1.corp.nortel.com><49B4F019.2020904@ericsson.com><0913B6CD18F370498CD65864CF254E90097B3549@zharhxm1.corp.nortel.com> From: "John-Luc Bakker" To: "Christer Holmberg" , "Milan Patel" , "Gonzalo Camarillo" X-OriginalArrivalTime: 07 May 2009 15:22:29.0754 (UTC) FILETIME=[A2B9F5A0:01C9CF27] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: ecrit@ietf.org Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.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: , X-List-Received-Date: Thu, 07 May 2009 15:21:50 -0000 Hi Christer, I see the XML tutorial has been time well spend! :) Why would you need to insert the option-tag in the Proxy-Require header) Why do you need intermediates to support the "sos" parameter? Isn't it enough if the registrar, which in this case acts as UAS (and therefor applies the Require header) support the "sos" parameter? In my proposed changes below I have a MUST for including the option-tag in the Proxy-Require. It would be useful for an emergency registration attempt to be rejected using a 420 response as soon as possible, i.e. already by the first proxy if the proxy has knowledge the extension is not supported. However, I can agree that mandating inclusion of the option-tag in the Proxy-Require is not required. Regards, John-Luc -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Thursday, May 07, 2009 12:05 AM To: John-Luc Bakker; Milan Patel; Gonzalo Camarillo Cc: ecrit@ietf.org Subject: RE: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Hi, My comments between the and tags. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of John-Luc Bakker > Sent: 7. toukokuuta 2009 6:08 > To: Milan Patel; Gonzalo Camarillo > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Expert review of > draft-patel-ecrit-sos-parameter-03.txt > > Hi Milan, > > I would like to pick up on Gonzalo's comment below: > > > The document does not talk about backwards compatibility. > What happens > > if the registrar does not understand the 'sos' parameter? > Will it do > > the right thing? Will the UAC detect the failure? Is there > a need to > > define an option tag?... the document should address these points. > > In the meanwhile, the document does talk about backwards > compatibility. > > However, the legacy registrar will do the only (right) thing > it can do but from a perspective of the UE that might not be > the anticipated > (right) thing. > > It is my understanding that an emergency registration can > happen at any time and a UE is not required to immediately > follow up the successful registration with an emergency call > or tear down the emergency registration after the emergency call. > > Suppose a UAC has one public user identity and it performs a > normal registration with some feature tags. Subsequently, the > same UAC performs an emergency registration with different > feature tags. Would the legacy registrar "refresh" the > binding, then the S-CSCF would apply "emergency" > feature tags to all session requests. > > An option tag would prevent this. > > If in agreement, I suggest the following changes to the draft > (between and tags): > > 4.1. REGISTER Request > > When the UA sends a REGISTER request for emergency > registration, the > "sos" URI parameter MUST be appended to the URI in the Contact > Header and the option-tag "e-reg" must be included in > the Proxy-Require and Require header. This serves as > an indication to the > registrar that the > request is for emergency registration and it is only > accepted if emergency registration is supported. > > Example: > > Contact: "Alice" ;q=3D0.7; expires=3D3600 > > In the event that more than one Contact header field is included in > the REGISTER request, only the contact addresses that include the > "sos" URI parameter shall be considered as emergency registered > contact addresses. > > > Upon receipt of a 420 (Bad Extension) response the UAC will > use an existing registration or initiate another registration. > Why would you need to insert the option-tag in the Proxy-Require header) Why do you need intermediates to support the "sos" parameter? Isn't it enough if the registrar, which in this case acts as UAS (and therefor applies the Require header) support the "sos" parameter? Regards, Christer > 4.3. Backwards compatibility issues > > The backwards compatibility scenario considered in this document is > where a legacy registrar does not support the "sos" URI parameter. > > > This document registers an option tag with IANA in section 6.2. > Inclusion of the option tag will prevent a legacy registrar > from handling the request. > > > 6. IANA Considerations > > 6.2 SIP URI parameter > > This specification defines one new SIP URI parameter, as per the > registry created by RFC 3969 [RFC3969] > > Parameter Name: sos > > Predefined Values: none > > Reference: [RFCXXXX] > > [NOTE TO IANA: Please replace XXXX with the RFC number of this > specification.] > > 6.2 SIP Option Tag > > This specification registers a new SIP option tag, as per the > guidelines in Section 27.1 of RFC 3261 [RFC3261]. > > Name: e-reg > > Description: This option tag is used to identify the > emergency registration extension. When used in a Supported > header, it indicates that a User Agent understands the > extension. When used in a Require header field of a REGISTER > request, it indicates that the registrar is not expected to > process the registration unless it supports the emergency > registration extension. > > > Regards, > > John-Luc > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Milan Patel > Sent: Tuesday, April 28, 2009 8:36 AM > To: Gonzalo Camarillo > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Expert review of > draft-patel-ecrit-sos-parameter-03.txt > > Hi Gonzalo, > > Version 4 of draft-patel-ecrit-sos-parameter addresses all > the comments you provided in the expert review. Please can > you confirm that you are OK with its contents and that all > the issues you had previously highlighted are now resolved. > http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-04 > Best regards, > Milan > > Milan Patel > Carrier Networks Core Standards > Nortel > milanpa@nortel.com > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 > 9261 / ESN 748 9261 > > For the Companies listed below, The Institute of Chartered > Accountants in England and Wales authorises A R Bloom, S > Harris and C Hill to act as Insolvency Practitioners under > section 390(2)(a) of the Insolvency Act > 1986 and the Association of Chartered Certified Accountants > authorises A M Hudson to act as an Insolvency Practitioner > under section 390(2)(a) of the Insolvency Act 1986. > > The affairs, business and property of the Companies are being > managed by the Joint Administrators, A R Bloom, S Harris, AM > Hudson and C Hill who act as agents of the Companies only and > without personal liability. > > The Companies are Nortel Networks UK Limited; Nortel Networks > SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks > NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks > Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks > (Austria) GmbH; Nortel Networks sro; Nortel Networks > Engineering Service Kft; Nortel Networks Portugal SA; Nortel > Networks Slovensko sro; Nortel Networks Oy; Nortel Networks > Romania SRL; Nortel Networks AB; Nortel Networks > International Finance & Holding BV > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: 09 March 2009 10:32 > To: Patel, Milan (MOP:EP10) > Cc: ecrit@ietf.org; Hannes Tschofenig > Subject: Re: [Ecrit] Expert review of > draft-patel-ecrit-sos-parameter-03.txt > > Hi, > > the problem with this text is that it specifies behavior for > entities that will not implement this specification. The new > section should describe how a legacy registrar will handle, > following regular SIP rules, a REGISTER request with the sos > parameter. However, it cannot specify extra behavior for such > a legacy registrar. That is the whole point of backwards > compatibility: to support unchanged legacy applications that > will not implement the new functionality. > > In any case, I believe you can use most of the text you > proposed below. > It just needs to be rephrased so that it is more descriptive > and non normative. > > Thanks, > > Gonzalo > > Milan Patel wrote: > > Folks, > > > > In response to Gonzalo's comment on backwards > compatibility, I propose > > > a subclause "4.3 Backwards compatibility issues" as follows: > > > > > ---------------------------------------------------------------------- > > -- > > ---------------------------------- > > 4.3 Backwards compatibility issues > > The backwards compatibility scenario considered in this document is > > where the registrar does not support the "sos" URI > parameter. In this > > case, if the registrar receives a REGISTER request that > includes the > > "sos" URI parameter in the Contact header, the registrar > MUST proceed > > with registration procedures and silently ignore the > URI-parameter in > > accordance with RFC 3261. This ensures the user is > registered and thus > > > can successfully initiate an emergency call. > > > > The drawback of proceeding with registration is if the > > address-of-record is barred or has roaming restrictions > applied, then > > these restrictions will not be lifted and thus registration will be > > unsuccessful. This may limit the UAC's ability to successfully place > an emergency call. > > > > If registration is successful, the registrar shall return a > 200 (OK) > > response to the UAC and does not include the "sos" URI parameter in > > the Contact header. The UAC is aware of its registered > contact address > > > and address-of-record, however, cannot distinguish between this > > registration and a non-emergency registration. > > > ---------------------------------------------------------------------- > > -- > > -------------------------------------- > > > > Comments/feedback/suggestions for improvement are > appreciated. I will > > address Gonzalo's other comments in version -04 of the > draft as well. > > > > Best regards, > > Milan > > > > Milan Patel > > Carrier Networks Core Standards > > Nortel > > milanpa@nortel.com > > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 / > > ESN 748 9261 > > > > For the Companies listed below, The Institute of Chartered > Accountants > > > in England and Wales authorises A R Bloom, S Harris and C > Hill to act > > as Insolvency Practitioners under section 390(2)(a) of the > Insolvency > > Act > > 1986 and the Association of Chartered Certified Accountants > authorises > > > A M Hudson to act as an Insolvency Practitioner under section > > 390(2)(a) of the Insolvency Act 1986. > > > > The affairs, business and property of the Companies are > being managed > > by the Joint Administrators, A R Bloom, S Harris, AM Hudson > and C Hill > > > who act as agents of the Companies only and without personal > liability. > > > > The Companies are Nortel Networks UK Limited; Nortel Networks SA; > > Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel > > Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; > > Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel > > Networks sro; Nortel Networks Engineering Service Kft; > Nortel Networks > > > Portugal SA; Nortel Networks Slovensko sro; Nortel Networks > Oy; Nortel > > > Networks Romania SRL; Nortel Networks AB; Nortel Networks > > International Finance & Holding BV > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Gonzalo Camarillo > > Sent: 19 February 2009 13:57 > > To: ecrit@ietf.org > > Subject: [Ecrit] Expert review of > > draft-patel-ecrit-sos-parameter-03.txt > > > > Folks, > > > > I have been asked to perform an expert review of the > following draft: > > > > http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt > > > > The approach taken by the draft seems OK in general. I have a few > > comments though: > > > > The requirement in Section 3 is too specific because it already > > assumes that the solution will be an indication in the SIP header > > fields. The requirement does not need to make that > assumption. I would > > > remove "by providing an appropriate indication in the SIP header > fields". > > > > In Section 5, the reference to RFC 2234 should be replaced > with one to > > > RFC 5234. > > > > Also in Section 5, the formal syntax should be rewritten so > that it is > > > compatible with the ABNF in RFC 3261. RFC 3261 already defines > > uri-parameter as follows: > > > > uri-parameter =3D transport-param / user-param / method-param > > / ttl-param / maddr-param / lr-param / > > other-param > > > > other-param =3D pname [ "=3D" pvalue ] > > pname =3D 1*paramchar > > pvalue =3D 1*paramchar > > > > This document should simply define a new value for pname. > > > > The document does not talk about backwards compatibility. > What happens > > > if the registrar does not understand the 'sos' parameter? > Will it do > > the right thing? Will the UAC detect the failure? Is there > a need to > > define an option tag?... the document should address these points. > > > > Cheers, > > > > Gonzalo > > > > _______________________________________________ > > 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 > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain > confidential information, privileged material (including > material protected by the solicitor-client or other > applicable privileges), or constitute non-public information. > Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender > and delete this information from your system. Use, > dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and > may be unlawful. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From jbakker@rim.com Thu May 7 10:02:31 2009 Return-Path: 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 1FF3228C1B4 for ; Thu, 7 May 2009 10:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.103 X-Spam-Level: X-Spam-Status: No, score=-5.103 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 WHlRRQLquVuF for ; Thu, 7 May 2009 10:02:29 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id ED7DB28C2FB for ; Thu, 7 May 2009 10:02:28 -0700 (PDT) Received: from mhs04ykf.rim.net (unknown [127.0.0.1]) by mhs04ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id AF1635C3A4; Thu, 7 May 2009 13:03:55 -0400 (EDT) X-AuditID: 0a666446-a4ca5bb000002ec5-a4-4a03147b2f99 Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs04ykf.rim.net (Symantec Mail Security) with ESMTP id 50A745C38D; Thu, 7 May 2009 13:03:55 -0400 (EDT) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 May 2009 13:03:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" content-transfer-encoding: quoted-printable Date: Thu, 7 May 2009 12:03:39 -0500 Message-ID: In-Reply-To: <0913B6CD18F370498CD65864CF254E9009927A32@zharhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt thread-index: AcmgoqEwGgnKMKiDS8KCxn9Oay/pdQnYyfBwAayUNIAABijoAAAKf6qwAA1eAXA= References: <499D6530.9040208@ericsson.com><0913B6CD18F370498CD65864CF254E9008DA24B2@zharhxm1.corp.nortel.com><49B4F019.2020904@ericsson.com><0913B6CD18F370498CD65864CF254E90097B3549@zharhxm1.corp.nortel.com> <0913B6CD18F370498CD65864CF254E9009927A32@zharhxm1.corp.nortel.com> From: "John-Luc Bakker" To: "Milan Patel" , "Christer Holmberg" , "Gonzalo Camarillo" X-OriginalArrivalTime: 07 May 2009 17:03:43.0817 (UTC) FILETIME=[C7266B90:01C9CF35] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: ecrit@ietf.org Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.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: , X-List-Received-Date: Thu, 07 May 2009 17:02:31 -0000 Hi Milan, See inline -----Original Message----- From: Milan Patel [mailto:milanpa@nortel.com] Sent: Thursday, May 07, 2009 5:44 AM To: Christer Holmberg; John-Luc Bakker; Gonzalo Camarillo Cc: ecrit@ietf.org Subject: RE: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Hi John-Luc, Firstly, it is my understanding that emergency registration occurs when the emergency call request is detected by the UE (e.g. user dials 911). The duration of this emergency registration is also not specified to be the same as that of a normal registration. My understanding of 23.228 is that it is not specified if emergency registration only occurs during initiation of an emergency call. Indeed, the draft states: The 3GPP IP Multimedia Subsystem (IMS) emergency services architecture, illustrated in 3GPP TS 23.167 [3GPP.23.167], specifies that the User Equipment (UE) performs emergency registration prior to or during the initiation of an emergency call. Secondly, if the registrar were to reject the emergency registration because it did not support the "sos" URI parameter, and no other registration existed, the UE would have to initiate an unauthenticated emergency call. Surely, it would make more sense to either register the user, even if it means overriding an existing non-emergency registration or if using 3GPP IMS, the network can return a 380 response to the UE, forcing it to use for example the CS domain. If the UE has sufficient credentials, the UE can make a normal registration. I don't see a need to require an automatic fall back to unauthenticated emergency call procedures. In most cases, I expect that the normal registration is already in place. The feature tag ensures that a UE doesn't "successfully" connect to a legacy registrar and subsequently gets unanticipated behavior. Upon receiving the 420 response, if the UAC attempts registration again, then this registration would be treated as a non-emergency registration. This is the same result as ignoring the URI parameter if the registrar did not support it. But the UE would still attempt a normal registration either after the emergency registration or before the emergency registration was attempted. In both cases, the registration would be "refreshed", possibly even having a different "q" value (i.e. "q" value not set to 1 is refreshed by "normal" registration with a different "q" value). Therefore, I still think the current procedures are sufficient. Regards, Milan Milan Patel Carrier Networks Core Standards Nortel milanpa@nortel.com Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 / ESN 748 9261 For the Companies listed below, The Institute of Chartered Accountants in England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act 1986. The affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as agents of the Companies only and without personal liability. The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel Networks AB; Nortel Networks International Finance & Holding BV -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 07 May 2009 06:05 To: John-Luc Bakker; Patel, Milan (MOP:EP10); Gonzalo Camarillo Cc: ecrit@ietf.org Subject: RE: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Hi, My comments between the and tags. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of John-Luc Bakker > Sent: 7. toukokuuta 2009 6:08 > To: Milan Patel; Gonzalo Camarillo > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Expert review of > draft-patel-ecrit-sos-parameter-03.txt > > Hi Milan, > > I would like to pick up on Gonzalo's comment below: > > > The document does not talk about backwards compatibility. > What happens > > if the registrar does not understand the 'sos' parameter? > Will it do > > the right thing? Will the UAC detect the failure? Is there > a need to > > define an option tag?... the document should address these points. > > In the meanwhile, the document does talk about backwards > compatibility. > > However, the legacy registrar will do the only (right) thing > it can do but from a perspective of the UE that might not be > the anticipated > (right) thing. > > It is my understanding that an emergency registration can > happen at any time and a UE is not required to immediately > follow up the successful registration with an emergency call > or tear down the emergency registration after the emergency call. > > Suppose a UAC has one public user identity and it performs a > normal registration with some feature tags. Subsequently, the > same UAC performs an emergency registration with different > feature tags. Would the legacy registrar "refresh" the > binding, then the S-CSCF would apply "emergency" > feature tags to all session requests. > > An option tag would prevent this. > > If in agreement, I suggest the following changes to the draft > (between and tags): > > 4.1. REGISTER Request > > When the UA sends a REGISTER request for emergency > registration, the > "sos" URI parameter MUST be appended to the URI in the Contact > Header and the option-tag "e-reg" must be included in > the Proxy-Require and Require header. This serves as > an indication to the > registrar that the > request is for emergency registration and it is only > accepted if emergency registration is supported. > > Example: > > Contact: "Alice" ;q=3D0.7; expires=3D3600 > > In the event that more than one Contact header field is included in > the REGISTER request, only the contact addresses that include the > "sos" URI parameter shall be considered as emergency registered > contact addresses. > > > Upon receipt of a 420 (Bad Extension) response the UAC will > use an existing registration or initiate another registration. > Why would you need to insert the option-tag in the Proxy-Require header) Why do you need intermediates to support the "sos" parameter? Isn't it enough if the registrar, which in this case acts as UAS (and therefor applies the Require header) support the "sos" parameter? Regards, Christer > 4.3. Backwards compatibility issues > > The backwards compatibility scenario considered in this document is > where a legacy registrar does not support the "sos" URI parameter. > > > This document registers an option tag with IANA in section 6.2. > Inclusion of the option tag will prevent a legacy registrar > from handling the request. > > > 6. IANA Considerations > > 6.2 SIP URI parameter > > This specification defines one new SIP URI parameter, as per the > registry created by RFC 3969 [RFC3969] > > Parameter Name: sos > > Predefined Values: none > > Reference: [RFCXXXX] > > [NOTE TO IANA: Please replace XXXX with the RFC number of this > specification.] > > 6.2 SIP Option Tag > > This specification registers a new SIP option tag, as per the > guidelines in Section 27.1 of RFC 3261 [RFC3261]. > > Name: e-reg > > Description: This option tag is used to identify the > emergency registration extension. When used in a Supported > header, it indicates that a User Agent understands the > extension. When used in a Require header field of a REGISTER > request, it indicates that the registrar is not expected to > process the registration unless it supports the emergency > registration extension. > > > Regards, > > John-Luc > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Milan Patel > Sent: Tuesday, April 28, 2009 8:36 AM > To: Gonzalo Camarillo > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Expert review of > draft-patel-ecrit-sos-parameter-03.txt > > Hi Gonzalo, > > Version 4 of draft-patel-ecrit-sos-parameter addresses all > the comments you provided in the expert review. Please can > you confirm that you are OK with its contents and that all > the issues you had previously highlighted are now resolved. > http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-04 > Best regards, > Milan > > Milan Patel > Carrier Networks Core Standards > Nortel > milanpa@nortel.com > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 > 9261 / ESN 748 9261 > > For the Companies listed below, The Institute of Chartered > Accountants in England and Wales authorises A R Bloom, S > Harris and C Hill to act as Insolvency Practitioners under > section 390(2)(a) of the Insolvency Act > 1986 and the Association of Chartered Certified Accountants > authorises A M Hudson to act as an Insolvency Practitioner > under section 390(2)(a) of the Insolvency Act 1986. > > The affairs, business and property of the Companies are being > managed by the Joint Administrators, A R Bloom, S Harris, AM > Hudson and C Hill who act as agents of the Companies only and > without personal liability. > > The Companies are Nortel Networks UK Limited; Nortel Networks > SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks > NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks > Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks > (Austria) GmbH; Nortel Networks sro; Nortel Networks > Engineering Service Kft; Nortel Networks Portugal SA; Nortel > Networks Slovensko sro; Nortel Networks Oy; Nortel Networks > Romania SRL; Nortel Networks AB; Nortel Networks > International Finance & Holding BV > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: 09 March 2009 10:32 > To: Patel, Milan (MOP:EP10) > Cc: ecrit@ietf.org; Hannes Tschofenig > Subject: Re: [Ecrit] Expert review of > draft-patel-ecrit-sos-parameter-03.txt > > Hi, > > the problem with this text is that it specifies behavior for > entities that will not implement this specification. The new > section should describe how a legacy registrar will handle, > following regular SIP rules, a REGISTER request with the sos > parameter. However, it cannot specify extra behavior for such > a legacy registrar. That is the whole point of backwards > compatibility: to support unchanged legacy applications that > will not implement the new functionality. > > In any case, I believe you can use most of the text you > proposed below. > It just needs to be rephrased so that it is more descriptive > and non normative. > > Thanks, > > Gonzalo > > Milan Patel wrote: > > Folks, > > > > In response to Gonzalo's comment on backwards > compatibility, I propose > > > a subclause "4.3 Backwards compatibility issues" as follows: > > > > > ---------------------------------------------------------------------- > > -- > > ---------------------------------- > > 4.3 Backwards compatibility issues > > The backwards compatibility scenario considered in this document is > > where the registrar does not support the "sos" URI > parameter. In this > > case, if the registrar receives a REGISTER request that > includes the > > "sos" URI parameter in the Contact header, the registrar > MUST proceed > > with registration procedures and silently ignore the > URI-parameter in > > accordance with RFC 3261. This ensures the user is > registered and thus > > > can successfully initiate an emergency call. > > > > The drawback of proceeding with registration is if the > > address-of-record is barred or has roaming restrictions > applied, then > > these restrictions will not be lifted and thus registration will be > > unsuccessful. This may limit the UAC's ability to successfully place > an emergency call. > > > > If registration is successful, the registrar shall return a > 200 (OK) > > response to the UAC and does not include the "sos" URI parameter in > > the Contact header. The UAC is aware of its registered > contact address > > > and address-of-record, however, cannot distinguish between this > > registration and a non-emergency registration. > > > ---------------------------------------------------------------------- > > -- > > -------------------------------------- > > > > Comments/feedback/suggestions for improvement are > appreciated. I will > > address Gonzalo's other comments in version -04 of the > draft as well. > > > > Best regards, > > Milan > > > > Milan Patel > > Carrier Networks Core Standards > > Nortel > > milanpa@nortel.com > > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 / > > ESN 748 9261 > > > > For the Companies listed below, The Institute of Chartered > Accountants > > > in England and Wales authorises A R Bloom, S Harris and C > Hill to act > > as Insolvency Practitioners under section 390(2)(a) of the > Insolvency > > Act > > 1986 and the Association of Chartered Certified Accountants > authorises > > > A M Hudson to act as an Insolvency Practitioner under section > > 390(2)(a) of the Insolvency Act 1986. > > > > The affairs, business and property of the Companies are > being managed > > by the Joint Administrators, A R Bloom, S Harris, AM Hudson > and C Hill > > > who act as agents of the Companies only and without personal > liability. > > > > The Companies are Nortel Networks UK Limited; Nortel Networks SA; > > Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel > > Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; > > Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel > > Networks sro; Nortel Networks Engineering Service Kft; > Nortel Networks > > > Portugal SA; Nortel Networks Slovensko sro; Nortel Networks > Oy; Nortel > > > Networks Romania SRL; Nortel Networks AB; Nortel Networks > > International Finance & Holding BV > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Gonzalo Camarillo > > Sent: 19 February 2009 13:57 > > To: ecrit@ietf.org > > Subject: [Ecrit] Expert review of > > draft-patel-ecrit-sos-parameter-03.txt > > > > Folks, > > > > I have been asked to perform an expert review of the > following draft: > > > > http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt > > > > The approach taken by the draft seems OK in general. I have a few > > comments though: > > > > The requirement in Section 3 is too specific because it already > > assumes that the solution will be an indication in the SIP header > > fields. The requirement does not need to make that > assumption. I would > > > remove "by providing an appropriate indication in the SIP header > fields". > > > > In Section 5, the reference to RFC 2234 should be replaced > with one to > > > RFC 5234. > > > > Also in Section 5, the formal syntax should be rewritten so > that it is > > > compatible with the ABNF in RFC 3261. RFC 3261 already defines > > uri-parameter as follows: > > > > uri-parameter =3D transport-param / user-param / method-param > > / ttl-param / maddr-param / lr-param / > > other-param > > > > other-param =3D pname [ "=3D" pvalue ] > > pname =3D 1*paramchar > > pvalue =3D 1*paramchar > > > > This document should simply define a new value for pname. > > > > The document does not talk about backwards compatibility. > What happens > > > if the registrar does not understand the 'sos' parameter? > Will it do > > the right thing? Will the UAC detect the failure? Is there > a need to > > define an option tag?... the document should address these points. > > > > Cheers, > > > > Gonzalo > > > > _______________________________________________ > > 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 > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain > confidential information, privileged material (including > material protected by the solicitor-client or other > applicable privileges), or constitute non-public information. > Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender > and delete this information from your system. Use, > dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and > may be unlawful. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From christer.holmberg@ericsson.com Thu May 7 10:11:47 2009 Return-Path: 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 A348528C2FA for ; Thu, 7 May 2009 10:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.864 X-Spam-Level: X-Spam-Status: No, score=-5.864 tagged_above=-999 required=5 tests=[AWL=0.385, 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 WqKmdtx6Uazg for ; Thu, 7 May 2009 10:11:45 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 3FF7728C2EF for ; Thu, 7 May 2009 10:10:59 -0700 (PDT) X-AuditID: c1b4fb3c-b7b40ae000003af8-71-4a031679b963 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id B1.87.15096.976130A4; Thu, 7 May 2009 19:12:25 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 May 2009 19:12:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 May 2009 19:12:25 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Thread-Index: AcmgoqEwGgnKMKiDS8KCxn9Oay/pdQnYyfBwAayUNIAABijoAAAVZF7gAAQQAaA= References: <499D6530.9040208@ericsson.com><0913B6CD18F370498CD65864CF254E9008DA24B2@zharhxm1.corp.nortel.com><49B4F019.2020904@ericsson.com><0913B6CD18F370498CD65864CF254E90097B3549@zharhxm1.corp.nortel.com> From: "Christer Holmberg" To: "John-Luc Bakker" , "Milan Patel" , "Gonzalo Camarillo" X-OriginalArrivalTime: 07 May 2009 17:12:25.0605 (UTC) FILETIME=[FE28F350:01C9CF36] X-Brightmail-Tracker: AAAAAA== Cc: ecrit@ietf.org Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.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: , X-List-Received-Date: Thu, 07 May 2009 17:11:47 -0000 Hi,=20 >I see the XML tutorial has been time well spend! :) Yes. Why would you need to insert the option-tag in the Proxy-Require header) Why do you need intermediates to support the "sos" parameter? Isn't it enough if the registrar, which in this case acts as UAS (and therefor applies the Require header) support the "sos" parameter? In my proposed changes below I have a MUST for including the option-tag in the Proxy-Require. It would be useful for an emergency registration attempt to be rejected using a 420 response as soon as possible, i.e. already by the first proxy if the proxy has knowledge the extension is not supported. However, I can agree that mandating inclusion of the option-tag in the Proxy-Require is not required.=20 That is not really how Proxy-Require is intented to be used, in my opinion.=20 You use Proxy-Require if you require extension support from a proxy. You do not insert Proxy-Require because you assume proxies will know whether the UAS (the registrar in this case) supports the extension, and can reject the request if they know what the UAS does not support it. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Thursday, May 07, 2009 12:05 AM To: John-Luc Bakker; Milan Patel; Gonzalo Camarillo Cc: ecrit@ietf.org Subject: RE: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Hi, My comments between the and tags.=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of John-Luc Bakker > Sent: 7. toukokuuta 2009 6:08 > To: Milan Patel; Gonzalo Camarillo > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Expert review of=20 > draft-patel-ecrit-sos-parameter-03.txt >=20 > Hi Milan, >=20 > I would like to pick up on Gonzalo's comment below: >=20 > > The document does not talk about backwards compatibility.=20 > What happens=20 > > if the registrar does not understand the 'sos' parameter?=20 > Will it do=20 > > the right thing? Will the UAC detect the failure? Is there=20 > a need to=20 > > define an option tag?... the document should address these points. >=20 > In the meanwhile, the document does talk about backwards=20 > compatibility. >=20 > However, the legacy registrar will do the only (right) thing=20 > it can do but from a perspective of the UE that might not be=20 > the anticipated > (right) thing. >=20 > It is my understanding that an emergency registration can=20 > happen at any time and a UE is not required to immediately=20 > follow up the successful registration with an emergency call=20 > or tear down the emergency registration after the emergency call.=20 >=20 > Suppose a UAC has one public user identity and it performs a=20 > normal registration with some feature tags. Subsequently, the=20 > same UAC performs an emergency registration with different=20 > feature tags. Would the legacy registrar "refresh" the=20 > binding, then the S-CSCF would apply "emergency" > feature tags to all session requests. >=20 > An option tag would prevent this. >=20 > If in agreement, I suggest the following changes to the draft=20 > (between and tags): >=20 > 4.1. REGISTER Request >=20 > When the UA sends a REGISTER request for emergency=20 > registration, the > "sos" URI parameter MUST be appended to the URI in the Contact > Header and the option-tag "e-reg" must be included in=20 > the Proxy-Require and Require header. This serves as=20 > an indication to the > registrar that the > request is for emergency registration and it is only=20 > accepted if emergency registration is supported. >=20 > Example: >=20 > Contact: "Alice" ;q=3D0.7; = expires=3D3600 >=20 > In the event that more than one Contact header field is included in > the REGISTER request, only the contact addresses that include the > "sos" URI parameter shall be considered as emergency registered > contact addresses. >=20 > > Upon receipt of a 420 (Bad Extension) response the UAC will=20 > use an existing registration or initiate another registration. > Why would you need to insert the option-tag in the Proxy-Require header) Why do you need intermediates to support the "sos" parameter? Isn't it enough if the registrar, which in this case acts as UAS (and therefor applies the Require header) support the "sos" parameter? Regards, Christer > 4.3. Backwards compatibility issues >=20 > The backwards compatibility scenario considered in this document is > where a legacy registrar does not support the "sos" URI parameter. >=20 > > This document registers an option tag with IANA in section 6.2. > Inclusion of the option tag will prevent a legacy registrar=20 > from handling the request. > >=20 > 6. IANA Considerations > > 6.2 SIP URI parameter > > This specification defines one new SIP URI parameter, as per the > registry created by RFC 3969 [RFC3969] >=20 > Parameter Name: sos >=20 > Predefined Values: none >=20 > Reference: [RFCXXXX] >=20 > [NOTE TO IANA: Please replace XXXX with the RFC number of this > specification.] > > 6.2 SIP Option Tag >=20 > This specification registers a new SIP option tag, as per the=20 > guidelines in Section 27.1 of RFC 3261 [RFC3261]. >=20 > Name: e-reg >=20 > Description: This option tag is used to identify the=20 > emergency registration extension. When used in a Supported=20 > header, it indicates that a User Agent understands the=20 > extension. When used in a Require header field of a REGISTER=20 > request, it indicates that the registrar is not expected to=20 > process the registration unless it supports the emergency=20 > registration extension. > >=20 > Regards, >=20 > John-Luc >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Milan Patel > Sent: Tuesday, April 28, 2009 8:36 AM > To: Gonzalo Camarillo > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Expert review of > draft-patel-ecrit-sos-parameter-03.txt >=20 > Hi Gonzalo, >=20 > Version 4 of draft-patel-ecrit-sos-parameter addresses all=20 > the comments you provided in the expert review. Please can=20 > you confirm that you are OK with its contents and that all=20 > the issues you had previously highlighted are now resolved. > http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-04 > Best regards, > Milan >=20 > Milan Patel > Carrier Networks Core Standards > Nortel > milanpa@nortel.com > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053=20 > 9261 / ESN 748 9261 >=20 > For the Companies listed below, The Institute of Chartered=20 > Accountants in England and Wales authorises A R Bloom, S=20 > Harris and C Hill to act as Insolvency Practitioners under=20 > section 390(2)(a) of the Insolvency Act > 1986 and the Association of Chartered Certified Accountants=20 > authorises A M Hudson to act as an Insolvency Practitioner=20 > under section 390(2)(a) of the Insolvency Act 1986. >=20 > The affairs, business and property of the Companies are being=20 > managed by the Joint Administrators, A R Bloom, S Harris, AM=20 > Hudson and C Hill who act as agents of the Companies only and=20 > without personal liability. >=20 > The Companies are Nortel Networks UK Limited; Nortel Networks=20 > SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks=20 > NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks=20 > Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks=20 > (Austria) GmbH; Nortel Networks sro; Nortel Networks=20 > Engineering Service Kft; Nortel Networks Portugal SA; Nortel=20 > Networks Slovensko sro; Nortel Networks Oy; Nortel Networks=20 > Romania SRL; Nortel Networks AB; Nortel Networks=20 > International Finance & Holding BV >=20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: 09 March 2009 10:32 > To: Patel, Milan (MOP:EP10) > Cc: ecrit@ietf.org; Hannes Tschofenig > Subject: Re: [Ecrit] Expert review of > draft-patel-ecrit-sos-parameter-03.txt >=20 > Hi, >=20 > the problem with this text is that it specifies behavior for=20 > entities that will not implement this specification. The new=20 > section should describe how a legacy registrar will handle,=20 > following regular SIP rules, a REGISTER request with the sos=20 > parameter. However, it cannot specify extra behavior for such=20 > a legacy registrar. That is the whole point of backwards=20 > compatibility: to support unchanged legacy applications that=20 > will not implement the new functionality. >=20 > In any case, I believe you can use most of the text you=20 > proposed below.=20 > It just needs to be rephrased so that it is more descriptive=20 > and non normative. >=20 > Thanks, >=20 > Gonzalo >=20 > Milan Patel wrote: > > Folks, > >=20 > > In response to Gonzalo's comment on backwards=20 > compatibility, I propose >=20 > > a subclause "4.3 Backwards compatibility issues" as follows: > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > > ---------------------------------- > > 4.3 Backwards compatibility issues > > The backwards compatibility scenario considered in this document is=20 > > where the registrar does not support the "sos" URI=20 > parameter. In this=20 > > case, if the registrar receives a REGISTER request that=20 > includes the=20 > > "sos" URI parameter in the Contact header, the registrar=20 > MUST proceed=20 > > with registration procedures and silently ignore the=20 > URI-parameter in=20 > > accordance with RFC 3261. This ensures the user is=20 > registered and thus >=20 > > can successfully initiate an emergency call. > >=20 > > The drawback of proceeding with registration is if the=20 > > address-of-record is barred or has roaming restrictions=20 > applied, then=20 > > these restrictions will not be lifted and thus registration will be=20 > > unsuccessful. This may limit the UAC's ability to successfully place > an emergency call. > >=20 > > If registration is successful, the registrar shall return a=20 > 200 (OK)=20 > > response to the UAC and does not include the "sos" URI parameter in=20 > > the Contact header. The UAC is aware of its registered=20 > contact address >=20 > > and address-of-record, however, cannot distinguish between this=20 > > registration and a non-emergency registration. > >=20 > ---------------------------------------------------------------------- > > -- > > -------------------------------------- > >=20 > > Comments/feedback/suggestions for improvement are=20 > appreciated. I will=20 > > address Gonzalo's other comments in version -04 of the=20 > draft as well. > >=20 > > Best regards, > > Milan > >=20 > > Milan Patel > > Carrier Networks Core Standards > > Nortel > > milanpa@nortel.com > > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 /=20 > > ESN 748 9261 > >=20 > > For the Companies listed below, The Institute of Chartered=20 > Accountants >=20 > > in England and Wales authorises A R Bloom, S Harris and C=20 > Hill to act=20 > > as Insolvency Practitioners under section 390(2)(a) of the=20 > Insolvency=20 > > Act > > 1986 and the Association of Chartered Certified Accountants=20 > authorises >=20 > > A M Hudson to act as an Insolvency Practitioner under section > > 390(2)(a) of the Insolvency Act 1986. > >=20 > > The affairs, business and property of the Companies are=20 > being managed=20 > > by the Joint Administrators, A R Bloom, S Harris, AM Hudson=20 > and C Hill >=20 > > who act as agents of the Companies only and without personal > liability. > >=20 > > The Companies are Nortel Networks UK Limited; Nortel Networks SA;=20 > > Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel=20 > > Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo;=20 > > Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel=20 > > Networks sro; Nortel Networks Engineering Service Kft;=20 > Nortel Networks >=20 > > Portugal SA; Nortel Networks Slovensko sro; Nortel Networks=20 > Oy; Nortel >=20 > > Networks Romania SRL; Nortel Networks AB; Nortel Networks=20 > > International Finance & Holding BV > >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf >=20 > > Of Gonzalo Camarillo > > Sent: 19 February 2009 13:57 > > To: ecrit@ietf.org > > Subject: [Ecrit] Expert review of > > draft-patel-ecrit-sos-parameter-03.txt > >=20 > > Folks, > >=20 > > I have been asked to perform an expert review of the=20 > following draft: > >=20 > > http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt > >=20 > > The approach taken by the draft seems OK in general. I have a few=20 > > comments though: > >=20 > > The requirement in Section 3 is too specific because it already=20 > > assumes that the solution will be an indication in the SIP header=20 > > fields. The requirement does not need to make that=20 > assumption. I would >=20 > > remove "by providing an appropriate indication in the SIP header > fields". > >=20 > > In Section 5, the reference to RFC 2234 should be replaced=20 > with one to >=20 > > RFC 5234. > >=20 > > Also in Section 5, the formal syntax should be rewritten so=20 > that it is >=20 > > compatible with the ABNF in RFC 3261. RFC 3261 already defines=20 > > uri-parameter as follows: > >=20 > > uri-parameter =3D transport-param / user-param / method-param > > / ttl-param / maddr-param / lr-param /=20 > > other-param > >=20 > > other-param =3D pname [ "=3D" pvalue ] > > pname =3D 1*paramchar > > pvalue =3D 1*paramchar > >=20 > > This document should simply define a new value for pname. > >=20 > > The document does not talk about backwards compatibility.=20 > What happens >=20 > > if the registrar does not understand the 'sos' parameter?=20 > Will it do=20 > > the right thing? Will the UAC detect the failure? Is there=20 > a need to=20 > > define an option tag?... the document should address these points. > >=20 > > Cheers, > >=20 > > Gonzalo > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain=20 > confidential information, privileged material (including=20 > material protected by the solicitor-client or other=20 > applicable privileges), or constitute non-public information.=20 > Any use of this information by anyone other than the intended=20 > recipient is prohibited. If you have received this=20 > transmission in error, please immediately reply to the sender=20 > and delete this information from your system. Use,=20 > dissemination, distribution, or reproduction of this=20 > transmission by unintended recipients is not authorized and=20 > may be unlawful. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. From john.elwell@siemens-enterprise.com Fri May 8 06:31:40 2009 Return-Path: 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 5F2213A6CDA for ; Fri, 8 May 2009 06:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 bXqJ6PGNNZgh for ; Fri, 8 May 2009 06:31:39 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id BD0BB28C1B2 for ; Fri, 8 May 2009 06:30:53 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KJB0076WUXVAZ@siemenscomms.co.uk> for ecrit@ietf.org; Fri, 08 May 2009 14:32:19 +0100 (BST) Date: Fri, 08 May 2009 14:32:19 +0100 From: "Elwell, John" To: ecrit@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001DE2430@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Comment on inserted-by Thread-Index: AcnP4Wj0VKJEQnKNQIeP6QYczAEjiQ== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Ecrit] Comment on inserted-by 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: , X-List-Received-Date: Fri, 08 May 2009 13:31:40 -0000 The phone-bcp draft refers to the inserted-by parameter in the Geolocation header field. It recommends or mandates including "inserted-by=3Dendpoint" and "inserted-by=3Dserver". I take these = values "endpoint" and "server" to be literal values. However, the location-conveyance draft defines inserted-by as: geoloc-param =3D "inserted-by" EQUAL geoloc-inserter / "used-for-routing" / generic-param ; (from RFC 3261) geoloc-inserter =3D DQUOTE hostport DQUOTE So are the values "endpoint" and "server" really meant to be the hostports of those devices? John From br@brianrosen.net Fri May 8 06:38:10 2009 Return-Path: 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 123BC3A7115 for ; Fri, 8 May 2009 06:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 uZ3J1TFfw2K6 for ; Fri, 8 May 2009 06:38:09 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 5A62A3A6855 for ; Fri, 8 May 2009 06:38:09 -0700 (PDT) Received: from [209.173.57.233] (helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1M2QIU-00052F-Tw; Fri, 08 May 2009 08:39:31 -0500 From: "Brian Rosen" To: "'Elwell, John'" , References: <0D5F89FAC29E2C41B98A6A762007F5D001DE2430@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001DE2430@GBNTHT12009MSX.gb002.siemens.net> Date: Fri, 8 May 2009 09:39:35 -0400 Message-ID: <00c501c9cfe2$6f0559f0$4d100dd0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnP4Wj0VKJEQnKNQIeP6QYczAEjiQAAOSgw 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] Comment on inserted-by 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: , X-List-Received-Date: Fri, 08 May 2009 13:38:10 -0000 Yes. That part of text in -conveyence changed a couple of times, and I didn't track the changes in -phonebcp. We could make it clearer. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Elwell, John Sent: Friday, May 08, 2009 9:32 AM To: ecrit@ietf.org Subject: [Ecrit] Comment on inserted-by The phone-bcp draft refers to the inserted-by parameter in the Geolocation header field. It recommends or mandates including "inserted-by=endpoint" and "inserted-by=server". I take these values "endpoint" and "server" to be literal values. However, the location-conveyance draft defines inserted-by as: geoloc-param = "inserted-by" EQUAL geoloc-inserter / "used-for-routing" / generic-param ; (from RFC 3261) geoloc-inserter = DQUOTE hostport DQUOTE So are the values "endpoint" and "server" really meant to be the hostports of those devices? John _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Mon May 11 05:46:55 2009 Return-Path: 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 E05FC3A6D7E for ; Mon, 11 May 2009 05:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[AWL=-1.122, BAYES_40=-0.185] 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 IyCtVKZ8EOKx for ; Mon, 11 May 2009 05:46:55 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 055F93A6D1F for ; Mon, 11 May 2009 05:46:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1242046104; x=1242132504; h=From:Date:Subject:Message-ID:Content-Type:Content-Transfer-Encoding:Content-cl ass; b=Jfllq/sKx9pYk6x1TkuRpK8lmaoTrsdDOB5W9uSjsg2u03tVwGIoXJgfIQfdRaf5TVS4Xn8vy085Bh xIkG1WLw== Received: from ([10.31.13.50]) by stihiron2.va.neustar.com with ESMTP id 5202732.18307537; Mon, 11 May 2009 08:48:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {0F198781-9DD6-46FA-92A0-2B863BC4C110} x-cr-hashedpuzzle: AEuj Apxy A77Y A9kM BSHC BxQW C+Pv DWVB E+X6 GUjz Gdo9 G/tQ HaHb Iht3 JWxz JZtD; 1; ZQBjAHIAaQB0AEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {0F198781-9DD6-46FA-92A0-2B863BC4C110}; YgByAGkAYQBuAC4AcgBvAHMAZQBuAEAAbgBlAHUAcwB0AGEAcgAuAGIAaQB6AA==; Mon, 11 May 2009 12:48:04 GMT; VwBpAHIAZQBkACAARQB0AGgAZQByAG4AZQB0ACAAcABoAG8AbgBlACAAaQBuACAAYQBuACAAUgBWAA== Content-class: urn:content-classes:message Date: Mon, 11 May 2009 08:48:04 -0400 Message-ID: <580F3FFD9207B545B48957A92BECEE0A0E20BF@STNTEXCH11.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wired Ethernet phone in an RV Thread-index: AcnSNrndfZ32a/QiT+qBFFLt1c575A== From: "Rosen, Brian" To: Subject: [Ecrit] Wired Ethernet phone in an RV 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: , X-List-Received-Date: Mon, 11 May 2009 12:46:56 -0000 Anyone who doubts the viability of a wired phone on a mobile network, and thus requiring a -phonebcp LCP should check out: http://www.nytimes.com/2009/05/07/technology/personaltech/07pogue.html?_ r=3D1 From Hannes.Tschofenig@gmx.net Tue May 12 09:10:33 2009 Return-Path: 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 0BD4C3A6D36 for ; Tue, 12 May 2009 09:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.145 X-Spam-Level: X-Spam-Status: No, score=-1.145 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_00=-2.599, MANGLED_ONLINE=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 o+hwczrLtmWw for ; Tue, 12 May 2009 09:10:31 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 20EE03A6D80 for ; Tue, 12 May 2009 09:10:30 -0700 (PDT) Received: (qmail invoked by alias); 12 May 2009 16:12:01 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp011) with SMTP; 12 May 2009 18:12:01 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1880gAXpKI8mjIksg3LxLWv4iX7/TRmz1HuuELIrV YTXMOmrm2mi1xe From: "Hannes Tschofenig" To: "'ECRIT'" Date: Tue, 12 May 2009 19:13:41 +0300 Message-ID: <00e801c9d31c$9df95d00$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnPYXNNttuRG1Q7QPeA5YK3H2BbnwDuyEnQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.48 Subject: [Ecrit] FW: Gen-ART LC review of draft-ietf-ecrit-location-hiding-req-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: , X-List-Received-Date: Tue, 12 May 2009 16:10:33 -0000 FYI >-----Original Message----- >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On >Behalf Of Ben Campbell >Sent: 08 May, 2009 01:16 >To: hgs+ecrit@cs.columbia.edu; Laura.Liess@t-systems.com; >Hannes.Tschofenig@gmx.net; barbara.stark@att.com; >andres.kytt@skype.net; General Area Review Team >Cc: Cullen Jennings; marc.linsner@cisco.com; ietf@ietf.org >Subject: Gen-ART LC review of draft-ietf-ecrit-location-hiding-req-01 > >I have been selected as the General Area Review Team (Gen-ART) >reviewer for this draft (for background on Gen-ART, please see >http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > >Please resolve these comments along with any other Last Call >comments you may receive. > >Document: draft-ietf-ecrit-location-hiding-req-01 >Reviewer: Ben Campbell >Review Date: 20090507 >IETF LC End Date: 20090511 >IESG Telechat date: (if known) > >Summary: > >This document is almost ready for publication as an >informational RFC. >There are some minor clarity issues where the reader is left >to infer some things that could be more explicit. > >Major issues: > >None > > > >Minor issues: > >-- 1.1, last paragraph: > >Can you expand on how withholding information information >needed for call routing concretely differs from withholding >information from emergency personnel? I assume there is more >to this than the intent of the ISP. Also, by saying an ISP is >"not interested", I think the point is to say that they have >legal obligations to disclose to emergency personnel, >regardless of any interest otherwise, right? > >-- 1.2, first paragraph: > >I think this leaves out what I assume to be the actual problem >statement, which is we need a way that an ISP/IAP can hide >location info from the user agent of the VSP in such a fashion >that it is still available for PSAP routing, correct? I can >infer that pretty easily, but I don't see where it is >explicitly stated in one place. > >Is there a case where an ISP is simply unable to provide >location information? I assume that would be out of scope for >this document, but it should be stated as such. > > > >-- 1.3, fourth paragraph: > >This paragraph could be more clear--how does the PSAP having >credentials meet a requirement to _hide_ information? I infer >the assumption is that the caller does _not_ have the >necessary credentials. If so, it would be better to state it explicitly > >-- Fifth paragraph: > >is compatibility with LoST a requirement? > >-- Req-B > >Is it appropriate for this document to put requirements on the >ISP/ IAP? Or do you mean to say they MUST be _able_ to support >this, while hiding information location from the VSP and/or UA? > >-- Req-C > >I don't really understand what is being said here. Is the >point to say that they must be able to validate that the URI >identifies a "bona fide" emergency service contact, and that a >call to that URI actually routes to the right place? How does >this interact with the later requirement that the entities >need not be SIP aware? > >-- Req-D > >this is stated as a requirement on the ISP rather than a >statement about the solution. I _think_ you are saying there >is a requirement to be _able_ to provide location info to the >PSAP while withholding it from the caller. Is that correct?. >Also how does "by value or by reference" interact with the >previous statement concerning LoST requiring LbyV? > >-- Req-5 > >How does the requirement that the ISP/IAP not need to know SIP >interact with the statement in Req-D that the ISP must be able >to determine if a call is being routed to a bona-fide location >service? >Also, does Req-5 imply a requirement to work with non-SIP VoIP >services? > >-- Req-6 > >What does it mean for a PSAP boundary to have holes? > >-- Req 12: > >"Minimal impact" is vague--can you add clarifying text to make >this more concrete? > >-- Req 15: > >Is that really a requirement, or just an observation of fact? > >-- Security Considerations: > >I'm a little skeptical of this statement that this does not >raise additional considerations. For example, would you >consider that a human might be endangered because an ISP >wanted to reserve location information as a "for pay" service >a security consideration, in that it requires the solution to >be more fail-safe than other protocols? On the other hand, is >the need to keep the UA from inferring location when an ISP >wants to hide it a security consideration? > >Nits/editorial comments: > >-- Abstract, paragraph 2: > >It's not clear to me that the document described architectural >impacts. It refers to architecture, but I don't see explicit >statements about how the architecture breaks if the ISP is not >willing to disclose. > >-- 1.1, list item "3." > >Please expand VSP on first use. > >-- Req-A: > >I don't think the requirement is to be able to withold >location from "any entity it wishes", since that would include >the PSAP, etc. > >-- Req-2: "jurisdiction of the PSAP" > >Geographical jurisdiction? > >-- Req-10: The solution MUST allow the end host to determine >PSAP/ ESRP URLs prior to the call, for all emergency services. > >Who is the "end host"? > >-- 3.3, first bullet: > >Is it appropriate to have "MUST"s in a section on "desirable >properties"? > >-- Third bullet: > >That's an implementation detail. I think you mean to say >something to the effect of the presence of NATs SHOULD not >break the mechanism. > > > > > > >-- idnits reports the following (which I include without prejudice): > >idnits 2.11.11 > >tmp/draft-ietf-ecrit-location-hiding-req-01.txt: > > Checking boilerplate required by RFC 5378 and the IETF Trust (see > http://trustee.ietf.org/license-info): > >--------------------------------------------------------------- >------------- > > ** 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. > > -- Found old boilerplate from RFC 3978 Section 5.1 on line 22. > > -- Found old boilerplate from RFC 3978 Section 5.5 updated by RFC >4748 on > line 377. > > -- Found old boilerplate from RFC 3979 Section 5 paragraph >1 on line 388. > > -- Found old boilerplate from RFC 3979 Section 5 paragraph >2 on line 395. > > -- Found old boilerplate from RFC 3979 Section 5 paragraph >3 on line 401. > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf > From gonzalo.camarillo@ericsson.com Fri May 1 12:24:52 2009 Return-Path: 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 6CC5728C1A7 for ; Fri, 1 May 2009 12:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.37 X-Spam-Level: X-Spam-Status: No, score=-5.37 tagged_above=-999 required=5 tests=[AWL=0.879, 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 GtnrjSCZ1hKk for ; Fri, 1 May 2009 12:24:51 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 639D528C18D for ; Fri, 1 May 2009 12:24:50 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-4d-49fb4cd4a0c0 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id FE.14.19078.4DC4BF94; Fri, 1 May 2009 21:26:12 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 21:25:12 +0200 Received: from [131.160.126.150] ([131.160.126.150]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 21:25:12 +0200 Message-ID: <49FB4C97.7030007@ericsson.com> Date: Fri, 01 May 2009 22:25:11 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Milan Patel References: <499D6530.9040208@ericsson.com> <0913B6CD18F370498CD65864CF254E9008DA24B2@zharhxm1.corp.nortel.com> <49B4F019.2020904@ericsson.com> <0913B6CD18F370498CD65864CF254E90097B3549@zharhxm1.corp.nortel.com> In-Reply-To: <0913B6CD18F370498CD65864CF254E90097B3549@zharhxm1.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2009 19:25:12.0151 (UTC) FILETIME=[8C1CE670:01C9CA92] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 13 May 2009 10:23:51 -0700 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.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: , X-List-Received-Date: Fri, 01 May 2009 19:24:52 -0000 Hi, thanks for putting together a new version of the draft. I still have a couple of minor comments on the following paragraph: "If registration is successful, the 200 (OK) response from a legacy registrar is unlikely to include the "sos" URI parameter in the Contact header. The UAC is aware of its registered contact address and address-of-record, however, is unable to distinguish between this registration and a non-emergency registration." Clarifying why it is "unlikely" would be useful. Is it because RFC 3261 gives registrars the freedom to do so, or because current implementation behave in different ways, or ...? Also, the last sentence says that the UAC will not be able to distinguish this registration from a non-emergency registration. Well, that is because this indeed is a non-emergency registration for the legacy registrar. I would remove that whole sentence or, if you want to include that information, clarify that the registrar will treat this registration as any non-emergency registration. Thanks, Gonzalo Milan Patel wrote: > Hi Gonzalo, > > Version 4 of draft-patel-ecrit-sos-parameter addresses all the comments > you provided in the expert review. Please can you confirm that you are > OK with its contents and that all the issues you had previously > highlighted are now resolved. > http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-04 > Best regards, > Milan > > Milan Patel > Carrier Networks Core Standards > Nortel > milanpa@nortel.com > Telephone +44 162 843 2381 / ESN 560 2381 > Mobile +44 774 053 9261 / ESN 748 9261 > > For the Companies listed below, The Institute of Chartered Accountants > in England and Wales authorises A R Bloom, S Harris and C Hill to act as > Insolvency Practitioners under section 390(2)(a) of the Insolvency Act > 1986 and the Association of Chartered Certified Accountants authorises A > M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of > the Insolvency Act 1986. > > The affairs, business and property of the Companies are being managed by > the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who > act as agents of the Companies only and without personal liability. > > The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel > GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks > SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks > Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel > Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel > Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; > Nortel Networks AB; Nortel Networks International Finance & Holding BV > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: 09 March 2009 10:32 > To: Patel, Milan (MOP:EP10) > Cc: ecrit@ietf.org; Hannes Tschofenig > Subject: Re: [Ecrit] Expert review of > draft-patel-ecrit-sos-parameter-03.txt > > Hi, > > the problem with this text is that it specifies behavior for entities > that will not implement this specification. The new section should > describe how a legacy registrar will handle, following regular SIP > rules, a REGISTER request with the sos parameter. However, it cannot > specify extra behavior for such a legacy registrar. That is the whole > point of backwards compatibility: to support unchanged legacy > applications that will not implement the new functionality. > > In any case, I believe you can use most of the text you proposed below. > It just needs to be rephrased so that it is more descriptive and non > normative. > > Thanks, > > Gonzalo > > Milan Patel wrote: >> Folks, >> >> In response to Gonzalo's comment on backwards compatibility, I propose > >> a subclause "4.3 Backwards compatibility issues" as follows: >> >> ---------------------------------------------------------------------- >> -- >> ---------------------------------- >> 4.3 Backwards compatibility issues >> The backwards compatibility scenario considered in this document is >> where the registrar does not support the "sos" URI parameter. In this >> case, if the registrar receives a REGISTER request that includes the >> "sos" URI parameter in the Contact header, the registrar MUST proceed >> with registration procedures and silently ignore the URI-parameter in >> accordance with RFC 3261. This ensures the user is registered and thus > >> can successfully initiate an emergency call. >> >> The drawback of proceeding with registration is if the >> address-of-record is barred or has roaming restrictions applied, then >> these restrictions will not be lifted and thus registration will be >> unsuccessful. This may limit the UAC's ability to successfully place > an emergency call. >> If registration is successful, the registrar shall return a 200 (OK) >> response to the UAC and does not include the "sos" URI parameter in >> the Contact header. The UAC is aware of its registered contact address > >> and address-of-record, however, cannot distinguish between this >> registration and a non-emergency registration. >> ---------------------------------------------------------------------- >> -- >> -------------------------------------- >> >> Comments/feedback/suggestions for improvement are appreciated. I will >> address Gonzalo's other comments in version -04 of the draft as well. >> >> Best regards, >> Milan >> >> Milan Patel >> Carrier Networks Core Standards >> Nortel >> milanpa@nortel.com >> Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 / >> ESN 748 9261 >> >> For the Companies listed below, The Institute of Chartered Accountants > >> in England and Wales authorises A R Bloom, S Harris and C Hill to act >> as Insolvency Practitioners under section 390(2)(a) of the Insolvency >> Act >> 1986 and the Association of Chartered Certified Accountants authorises > >> A M Hudson to act as an Insolvency Practitioner under section >> 390(2)(a) of the Insolvency Act 1986. >> >> The affairs, business and property of the Companies are being managed >> by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill > >> who act as agents of the Companies only and without personal > liability. >> The Companies are Nortel Networks UK Limited; Nortel Networks SA; >> Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel >> Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; >> Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel >> Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks > >> Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel > >> Networks Romania SRL; Nortel Networks AB; Nortel Networks >> International Finance & Holding BV >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >> Of Gonzalo Camarillo >> Sent: 19 February 2009 13:57 >> To: ecrit@ietf.org >> Subject: [Ecrit] Expert review of >> draft-patel-ecrit-sos-parameter-03.txt >> >> Folks, >> >> I have been asked to perform an expert review of the following draft: >> >> http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt >> >> The approach taken by the draft seems OK in general. I have a few >> comments though: >> >> The requirement in Section 3 is too specific because it already >> assumes that the solution will be an indication in the SIP header >> fields. The requirement does not need to make that assumption. I would > >> remove "by providing an appropriate indication in the SIP header > fields". >> In Section 5, the reference to RFC 2234 should be replaced with one to > >> RFC 5234. >> >> Also in Section 5, the formal syntax should be rewritten so that it is > >> compatible with the ABNF in RFC 3261. RFC 3261 already defines >> uri-parameter as follows: >> >> uri-parameter = transport-param / user-param / method-param >> / ttl-param / maddr-param / lr-param / >> other-param >> >> other-param = pname [ "=" pvalue ] >> pname = 1*paramchar >> pvalue = 1*paramchar >> >> This document should simply define a new value for pname. >> >> The document does not talk about backwards compatibility. What happens > >> if the registrar does not understand the 'sos' parameter? Will it do >> the right thing? Will the UAC detect the failure? Is there a need to >> define an option tag?... the document should address these points. >> >> Cheers, >> >> Gonzalo >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > From gonzalo.camarillo@ericsson.com Fri May 1 12:29:10 2009 Return-Path: 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 3D1D53A6CB2 for ; Fri, 1 May 2009 12:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.378 X-Spam-Level: X-Spam-Status: No, score=-5.378 tagged_above=-999 required=5 tests=[AWL=0.871, 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 KCpFGv1O033Q for ; Fri, 1 May 2009 12:29:09 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E46D63A6BF4 for ; Fri, 1 May 2009 12:29:08 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-90-49fb4dd7c87f Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 27.34.19078.7DD4BF94; Fri, 1 May 2009 21:30:31 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 21:30:31 +0200 Received: from [131.160.126.150] ([131.160.126.150]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 21:30:30 +0200 Message-ID: <49FB4DD6.6010102@ericsson.com> Date: Fri, 01 May 2009 22:30:30 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Dawes, Peter, VF-Group" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2009 19:30:31.0024 (UTC) FILETIME=[4A2D0F00:01C9CA93] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 13 May 2009 10:23:51 -0700 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.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: , X-List-Received-Date: Fri, 01 May 2009 19:29:10 -0000 Hi, inline: Dawes, Peter, VF-Group wrote: > Hello Milan, Gonzalo, > I have read through draft-patel-ecrit-sos-parameter-04 and I have a few > comments: > > Section 4.2 says: > The "sos" URI parameter is appended to the URI included in the > Contact header, thus indicating to the UA that this contact address > will be included in the Contact header of an INVITE for emergency > call initiation. > > I think it would be clearer to say: > > The "sos" URI parameter is appended to the URI included in the > Contact header, thus indicating to the UA that it MUST include this > contact address > in the Contact header of an INVITE for emergency call initiation. defining normative behavior in this way is not very clear. I would say "it needs to include" instead. Defining what the UA MUST do could be placed in a different paragraph or section if needed. The point is that separating the specification of UAC behavior from the specification of UAS behavior is typically a good thing. > Also, 4.2 says nothing about whether the PSAP uses the URI in the > Contact: header for > callback. At the end of section 1., it says: > > A call back from a PSAP would be routed to the registered contact > address. > > So it seems that for any subsequent callback session initiated by the > PSAP, the address > in the From: or P-Asserted-Identity header fields will be used. I am > not sure that > draft-ietf-ecrit-framework-09 is clear on what to include in the > Request URI for callback, > but it suggests that for dropped calls the URI from the Contact: header > field may be used. > > > Section 4.3 says: > If registration is successful, the 200 (OK) response from a legacy > registrar is unlikely to include the "sos" URI parameter in the > Contact header. The UAC is aware of its registered contact address > and address-of-record, however, is unable to distinguish between this > registration and a non-emergency registration. > > Does it matter if the UAC gets the "sos" URI parameter back from the > registrar? I would > have thought that the disadvantage of a non-supporting registrar is > limited to not > routing callbacks to the contact address marked for emergency use. The > UAC can still use > the emergency registered contact address in the Contact: header field of > an INVITE request > for an emergency call. the thing is that a legacy registrar will treat this registration as a non-emergency registration. That is what the text needs to capture. Cheers, Gonzalo From root@core3.amsl.com Mon May 11 10:00:01 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 64C913A693A; Mon, 11 May 2009 10:00:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090511170001.64C913A693A@core3.amsl.com> Date: Mon, 11 May 2009 10:00:01 -0700 (PDT) X-Mailman-Approved-At: Wed, 13 May 2009 10:23:50 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] ECRIT Interim Teleconference 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: , X-List-Received-Date: Mon, 11 May 2009 17:00:01 -0000 On Wednesday, June 3, 2009, 13:00-14:30 EDT (17:00-18:30 GMT), ECRIT will be having a teleconference interim meeting. The agenda, slides and dial-in information for this meeting will be posted to the ECRIT wiki page at: http://trac.tools.ietf.org/wg/ecrit/trac/wiki From drage@alcatel-lucent.com Thu May 14 06:51:16 2009 Return-Path: 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 B562F3A68DD for ; Thu, 14 May 2009 06:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.938 X-Spam-Level: X-Spam-Status: No, score=-5.938 tagged_above=-999 required=5 tests=[AWL=0.311, 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 atBQkrAEZM3U for ; Thu, 14 May 2009 06:51:14 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id D0FE63A6F43 for ; Thu, 14 May 2009 06:51:11 -0700 (PDT) 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 n4EDqKeu015730 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 14 May 2009 15:52:21 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 14 May 2009 15:52:20 +0200 From: "DRAGE, Keith (Keith)" To: Ted Hardie , Marc Linsner , "ecrit@ietf.org" Date: Thu, 14 May 2009 15:52:20 +0200 Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnJzZrx+zBl7/KrQ4uT6eqEZHtnnAKzQ12A Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6759ED5FD@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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 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: , X-List-Received-Date: Thu, 14 May 2009 13:51:16 -0000 In general, I have trouble thinking of any SIP RFC that cannot be applied, = or attempted to be applied somehow in the IMS environment. Not all operator= s may deploy all capabilities, but that applies to all of SIP. Even somethi= ng like RFC 4474 can be applied across the top of IMS if one so wished, ass= suming someone had not stuck an SBC in the way. Those considerations do not apply for Phone BCP, where if attached in an IM= S environment, in order to make an emergency call, the sequence followed is= somewhat different, and the IETF procedures just will not work. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Ted Hardie > Sent: Thursday, April 30, 2009 8:55 PM > To: Marc Linsner; ecrit@ietf.org > Subject: Re: [Ecrit] PhoneBCP > > At 12:52 PM -0700 4/30/09, Marc Linsner wrote: > >Ted, > > > >I searched a small amount for comparison type language in > other IETF drafts. > >I'm struggling with the notion that anyone who would read > IETF drafts > >would get confused as to their solution/applicability space. > > > >Since my search was small and cycles are short, are you > aware if there > >is any such language in any of the ream of SIP drafts that point out > >the solution space and explicitly exclude IMS? > > > >-Marc- > > Besides the long-running argument over SBCs? I am not sure; > possibly Keith would be able to point to comparison text. > > Ted > > > > > > >On 4/30/09 1:40 PM, "Ted Hardie" wrote: > > > >> At 9:48 AM -0700 4/30/09, Dawson, Martin wrote: > >>> Understanding ECRIT means understanding that broadband Internet > >>> access is broadband Internet access is broadband Internet access. > >> > >> To put it mildy, this is far from true. There is a whole class of > >> offerings that is voice-as-a-service (the IMS/NGN group) which > >> absolutely do not act like > >> voice-as-an-application. The solution we've defined is for > >> voice-as-an-application, > >> which has the natural result that the end user device has > the primary role. > >> > >> The root of the problem we're facing is that there is a difference > >> between using IP and using the Internet model. IMS uses > IP, but uses > >> a different model entirely (Whatever you think of that > model, I don't > >> think anyone who looked at how it works could argue that it is the > >> same as the Internet > >> model.) > >> > >> The documents we're dealing with contrast the offering > with PSTN, but > >> don't really see any differentiation among > "packet-switched networks". > >> Take this early text from the Framework document: > >> > >>> It is beyond the scope of this document to enumerate and > discuss all > >>> the differences between traditional (Public Switched Telephone > >>> Network) and IP-based telephony, but calling on the Internet is > >>> characterized by: > >>> o the interleaving over the same infrastructure of a > wider variety > >>> of services; > >>> o the separation of the access provider from the application > >>> provider; > >>> o media other than voice (e.g. video and text in > several forms); > >>> o the potential mobility of all end systems, including > endpoints > >>> nominally thought of as fixed systems and not just > those using > >>> radio access technology. For example, consider a wired phone > >>> connected to a router using a mobile data network > such as EV-DO as > >>> an uplink. > >>> > >>> This document focuses on how devices using the Internet > can place > >>> emergency calls and how PSAPs can handle Internet multimedia > >>> emergency calls natively, rather than describing how > circuit-switched > >>> PSAPs can handle VoIP calls. In many cases, PSAPs making the > >>> transition from circuit-switched interfaces to packet-switched > >>> interfaces may be able to use some of the mechanisms > described here, > >>> in combination with gateways that translate > packet-switched calls > >>> into legacy interfaces, e.g., to continue to be able to > use existing > >>> call taker equipment. There are many legacy telephone > networks that > >>> will persist long after most systems have been upgraded to IP > >>> origination and termination of emergency calls. Many > of these legacy > >>> systems route calls based on telephone numbers. Gateways and > >>> conversions between existing systems and newer systems > defined by > >>> this document will be required. Since existing systems > are governed > >>> primarily by local government regulations and national > standards, the > >>> gateway and conversion details will be governed by > national standards > >>> and thus are out of scope for this document. > >> > >> The real contrast being made is between circuit-switched > and Internet > >> model, but the terms used mix "packet-switched", "IP-based", and > >> "Internet"; there is even an explicit mention of EV-DO, > but in a mode > >> that treats it as a pure IP bearer (which is not what is > being sold > >> in most markets > > > today). The reality on the ground today is that there > are at least > >> circuit-switched, > >> Internet model IP, and IP with operator services out there in the > >> real world. This document set doesn't acknowledge that, and it > >> treats all packet-switched services/IP-based services as > if they were Internet model. > >> That's simply not true. > >> > >> The argument that Steven and others have made is that the document > >> set needs to have an explicit acknowledgement of the other > model, so > >> that there is a realization by those reading them that > just because they have > >> IP, doesn't mean they are dealing with the Internet model. > You could > >> argue that everyone knows that, but the document itself muddies it > >> far enough that it is far from evident. > >> > >> Do I, personally believe the Internet model version is > better? Yep. > >> Do I, personally believe that it will eventually subsume other > >> versions? Maybe, and I think it would be nice. But I > also recognize > >> that it is not the case now, and we're trying to define a > system that > >> will actually work to deliver emergency calls in the real world. > >> Explicit acknowledgement seems to me valuable in that case. The > >> other option is to re-write the documents to clarify that not any > >> packet-switched network nor any network using IP fits this set of > >> assumptions; that seems to me likely to take longer and > not add much. > >> > >> You've already had Keith note that he would object to the > documents > >> if they did not contain language like that which was in > -09. If it > >> is taken out, I believe the documents will need a major > editing pass > >> to accomplish the clarification without the explicit text. > This text > >> is a compromise already, and the issue it deals with is > important. > >> Unless we are going to pretend that the IMS model simply doesn't > >> exist and won't be used to deliver a substantial fraction of > >> emergency calls for a good long time to come, we need it. > If we are > >> going to pretend that, I think we are being very foolish indeed. > >> > >> Ted > >> > >> > >> > >>> Having to change the way the device initiates an > emergency call when > >>> something as prosaic as the access technology changes is akin to > >>> having to change your web browser just because the access > technology > >>> has changed. It's neither helpful nor harmless to have > such a restriction. > >>> > >>> A helpful statement to put in the BCP might be "Other > architectures, > >>> such as IMS Emergency calling defined by 3GPP and 3GPP2, > which are > >>> not based on the ECRIT framework are likely to not be compatible > >>> with devices and emergency networks which assume this framework - > >>> e.g. such as is defined by NENA as i3." > >>> > >>> I don't endorse the inclusion of such a statement; it's > commentary - > >>> as is the proposed "applicability statement" and > commentary is unnecessary. > >>> Nevertheless, I think it's a more accurate characterization. That > >>> is, it's more the case that the 3GPP IMS emergency architecture > >>> doesn't fit ECRIT than it is that ECRIT doesn't fit a > 3GPP access network. > >>> > >>> Cheers, > >>> Martin > >>> > >>> > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>> Behalf Of Edge, Stephen > >>> Sent: Friday, 1 May 2009 2:29 AM > >>> To: Bernard Aboba; Thomson, Martin; ecrit@ietf.org > >>> Subject: Re: [Ecrit] PhoneBCP > >>> > >>> Bernard and others > >>> > >>> This is an interesting view - an admission that the Ecrit > solution > >>> will probably not be universally applied and when it is may be > >>> subject to modification. On the 3GPP/3GPP2 sides, solutions are > >>> defined with a specific and explicit scope and are > expected to be - > >>> and nearly always actually are - supported exactly as > defined in the > >>> appropriate spec.s for all scenarios covered by the scope. A > >>> solution whose deployment is unpredictable will be less useful > >>> because of the implied interworking problems between incompatible > >>> implementations. That is a main reason why I and others initially > >>> tried to include a more precise applicability/scope > statement than > >>> the one we are now discussing. Specifically, the Ecrit > solution will > >>> probably not be deployed by > >>> 3GPP/3GPP2 operators for cellular terminals because they have > >>> defined a > > >> somewhat different solution more suitable for cellular > operation. > > >> That means > >>> that a terminal supporting only the Ecrit solution (based on an > >>> assertion of universal ap > >> plicability) will encounter problems when its user attempts an > >> emergency call on a 3GPP/3GPP2 network. If I can extend your > >> analogies, this would be like not including a precise menu > >> description for a meal containing meat and/or fish in a > restaurant catering to both vegetarians and non-vegetarians. > >>> > >>> Kind Regards > >>> > >>> Stephen > >>> > >>> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > >>> Sent: Thursday, April 30, 2009 1:13 AM > >>> To: Edge, Stephen; martin.thomson@andrew.com; ecrit@ietf.org > >>> Subject: RE: [Ecrit] PhoneBCP > >>> > >>>> Your interpretation of applicability is certainly > extreme (yes or > >>>> qualified yes to all questions) - removing any dependence on > >>>> suitability or feasibility (which are the more normal > benchmarks) > >>>> and simply making a legalistic blanket assertion. (I can > now more > >>>> understand incidentally why the fictitious protocol > police are so > >>>> often invoked on matters of > >>>> conformance.) > >>>> > >>>> But do others have any views on this? > >>> > >>> Here is my 2 pence. As noted in the Introduction, the > Phone BCP document > >>> and framework documents are closely related documents > that need to > >>> be read (and understood) together. In looking at Phone > BCP, there > >>> have been many situations in which I wondered what the > >>> justification was for a requirement, only to find the (usually > >>> persuasive) explanation in the corresponding section of > the framework document. > >>> > >>> IMHO, the separation of the two documents is somewhat unnatural. > >>> It's a bit like taking a meal, freeze drying it, and then > presenting > >>> the diner with a cup of powder and a cup of water and > wondering why > >>> they are left with a quizical look on their faces. Including > >>> cooking instructions along with the two cups is not a > fully satisfactory answer. > >>> > >>> Given this reality, if there is a need for text explaining the > >>> fundamental assumptions of the architecture, the place > for that text > >>> is not in the BCP document, but in the framework > document. As has > >>> been noted by others, the entire BCP document is an applicability > >>> statement, and when viewed in that way, the proposed text is not > >>> only unnecessary, but somewhat confusing since required > context for > >>> the BCP document belongs in the framework document. If anything > >>> more is necesary, it would probably be some additional > instructions for the reader delving into the document set > for the first time. > >>> > >>> Like any IETF effort, the framework and BCP documents will be > >>> evaluated on their own merits. Athough this is an area with a > >>> considerable regulatory component, I see little evidence that the > >>> world at large is so in awe of the IETF that every word will be > >>> taken as immutable truth. No doubt other SDOs will take > issue with > >>> these documents in whole or in part and will explain the basis of > >>> their assessments and where necessary, their alternatives. As a > >>> result, some portions of the architecture may be adopted, some > >>> portions may be ignored, and others will be revised in an > effort to address the issues encountered and improve their > chances for deployment. > >>> > >>> With respect to this process, the addition of cautionary > text is a > >>> bit like the warning labels that we find on consumer products. > >>> While it may be necessary in some legalistic sense, given the > >>> expertise of the individuals assessing these documents, > one wonders what the practical effect will be. > >>> Typically these are individuals who already understand > that it is a > >>> good idea to double-cup hot coffee. > >>> > >>> > >>> > >>> > -------------------------------------------------------------------- > >>> --------- > >>> ------------------- > >>> This message is for the designated recipient only and may contain > >>> privileged, proprietary, or otherwise private information. > >>> If you have received it in error, please notify the sender > >>> immediately and delete the original. Any unauthorized > use of this > >>> email is prohibited. > >>> > -------------------------------------------------------------------- > >>> --------- > > >> ------------------- > >>> [mf2] > >>> > >>> Content-Type: text/plain; name=3D"ATT00001.txt" > >>> Content-Description: ATT00001.txt > >>> Content-Disposition: attachment; filename=3D"ATT00001.txt"; > size=3D194; > >>> creation-date=3D"Thu, 30 Apr 2009 09:49:15 GMT"; > >>> modification-date=3D"Thu, 30 Apr 2009 09:49:15 GMT" > >>> > >>> Attachment converted: Macintosh HD:ATT00001 5257.txt (TEXT/ttxt) > >>> (0040366B) > >> > >> _______________________________________________ > >> 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 br@brianrosen.net Thu May 14 07:12:33 2009 Return-Path: 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 20E6E28C248 for ; Thu, 14 May 2009 07:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 MUOcLNI9bt3i for ; Thu, 14 May 2009 07:12:31 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 3D9AF3A6CE3 for ; Thu, 14 May 2009 07:12:31 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1M4bh5-0001Wb-PA; Thu, 14 May 2009 09:13:56 -0500 From: "Brian Rosen" To: "'DRAGE, Keith \(Keith\)'" , "'Ted Hardie'" , "'Marc Linsner'" , References: <28B7C3AA2A7ABA4A841F11217ABE78D6759ED5FD@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D6759ED5FD@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Thu, 14 May 2009 10:13:59 -0400 Message-ID: <029001c9d49e$3bdf6ff0$b39e4fd0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnJzZrx+zBl7/KrQ4uT6eqEZHtnnAKzQ12AAAC8bnA= 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] 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: , X-List-Received-Date: Thu, 14 May 2009 14:12:33 -0000 Please be careful. What you mean is that 3GPP has chosen to go a different direction. The phonebcp procedures would work fine in IMS systems if operators chose to implement them. There is no inherent disconnect. At the moment, it would seem that IMS operators will have to provide all the tools to allow devices and services on their underlying packet network to be phonebcp compliant. The mobile WiFi to wireless network bridge plus any standard phonebcp compliant client for example. The services that the operators provide directly may use different procedures, given the current 3GPP standards direction. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of DRAGE, Keith (Keith) > Sent: Thursday, May 14, 2009 9:52 AM > To: Ted Hardie; Marc Linsner; ecrit@ietf.org > Subject: Re: [Ecrit] PhoneBCP > > In general, I have trouble thinking of any SIP RFC that cannot be > applied, or attempted to be applied somehow in the IMS environment. Not > all operators may deploy all capabilities, but that applies to all of > SIP. Even something like RFC 4474 can be applied across the top of IMS > if one so wished, asssuming someone had not stuck an SBC in the way. > > Those considerations do not apply for Phone BCP, where if attached in > an IMS environment, in order to make an emergency call, the sequence > followed is somewhat different, and the IETF procedures just will not > work. > > regards > > Keith > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Ted Hardie > > Sent: Thursday, April 30, 2009 8:55 PM > > To: Marc Linsner; ecrit@ietf.org > > Subject: Re: [Ecrit] PhoneBCP > > > > At 12:52 PM -0700 4/30/09, Marc Linsner wrote: > > >Ted, > > > > > >I searched a small amount for comparison type language in > > other IETF drafts. > > >I'm struggling with the notion that anyone who would read > > IETF drafts > > >would get confused as to their solution/applicability space. > > > > > >Since my search was small and cycles are short, are you > > aware if there > > >is any such language in any of the ream of SIP drafts that point out > > >the solution space and explicitly exclude IMS? > > > > > >-Marc- > > > > Besides the long-running argument over SBCs? I am not sure; > > possibly Keith would be able to point to comparison text. > > > > Ted > > > > > > > > > > > >On 4/30/09 1:40 PM, "Ted Hardie" wrote: > > > > > >> At 9:48 AM -0700 4/30/09, Dawson, Martin wrote: > > >>> Understanding ECRIT means understanding that broadband Internet > > >>> access is broadband Internet access is broadband Internet access. > > >> > > >> To put it mildy, this is far from true. There is a whole class of > > >> offerings that is voice-as-a-service (the IMS/NGN group) which > > >> absolutely do not act like > > >> voice-as-an-application. The solution we've defined is for > > >> voice-as-an-application, > > >> which has the natural result that the end user device has > > the primary role. > > >> > > >> The root of the problem we're facing is that there is a difference > > >> between using IP and using the Internet model. IMS uses > > IP, but uses > > >> a different model entirely (Whatever you think of that > > model, I don't > > >> think anyone who looked at how it works could argue that it is the > > >> same as the Internet > > >> model.) > > >> > > >> The documents we're dealing with contrast the offering > > with PSTN, but > > >> don't really see any differentiation among > > "packet-switched networks". > > >> Take this early text from the Framework document: > > >> > > >>> It is beyond the scope of this document to enumerate and > > discuss all > > >>> the differences between traditional (Public Switched Telephone > > >>> Network) and IP-based telephony, but calling on the Internet is > > >>> characterized by: > > >>> o the interleaving over the same infrastructure of a > > wider variety > > >>> of services; > > >>> o the separation of the access provider from the application > > >>> provider; > > >>> o media other than voice (e.g. video and text in > > several forms); > > >>> o the potential mobility of all end systems, including > > endpoints > > >>> nominally thought of as fixed systems and not just > > those using > > >>> radio access technology. For example, consider a wired > phone > > >>> connected to a router using a mobile data network > > such as EV-DO as > > >>> an uplink. > > >>> > > >>> This document focuses on how devices using the Internet > > can place > > >>> emergency calls and how PSAPs can handle Internet multimedia > > >>> emergency calls natively, rather than describing how > > circuit-switched > > >>> PSAPs can handle VoIP calls. In many cases, PSAPs making the > > >>> transition from circuit-switched interfaces to packet-switched > > >>> interfaces may be able to use some of the mechanisms > > described here, > > >>> in combination with gateways that translate > > packet-switched calls > > >>> into legacy interfaces, e.g., to continue to be able to > > use existing > > >>> call taker equipment. There are many legacy telephone > > networks that > > >>> will persist long after most systems have been upgraded to IP > > >>> origination and termination of emergency calls. Many > > of these legacy > > >>> systems route calls based on telephone numbers. Gateways and > > >>> conversions between existing systems and newer systems > > defined by > > >>> this document will be required. Since existing systems > > are governed > > >>> primarily by local government regulations and national > > standards, the > > >>> gateway and conversion details will be governed by > > national standards > > >>> and thus are out of scope for this document. > > >> > > >> The real contrast being made is between circuit-switched > > and Internet > > >> model, but the terms used mix "packet-switched", "IP-based", and > > >> "Internet"; there is even an explicit mention of EV-DO, > > but in a mode > > >> that treats it as a pure IP bearer (which is not what is > > being sold > > >> in most markets > > > > today). The reality on the ground today is that there > > are at least > > >> circuit-switched, > > >> Internet model IP, and IP with operator services out there in the > > >> real world. This document set doesn't acknowledge that, and it > > >> treats all packet-switched services/IP-based services as > > if they were Internet model. > > >> That's simply not true. > > >> > > >> The argument that Steven and others have made is that the document > > >> set needs to have an explicit acknowledgement of the other > > model, so > > >> that there is a realization by those reading them that > > just because they have > > >> IP, doesn't mean they are dealing with the Internet model. > > You could > > >> argue that everyone knows that, but the document itself muddies it > > >> far enough that it is far from evident. > > >> > > >> Do I, personally believe the Internet model version is > > better? Yep. > > >> Do I, personally believe that it will eventually subsume other > > >> versions? Maybe, and I think it would be nice. But I > > also recognize > > >> that it is not the case now, and we're trying to define a > > system that > > >> will actually work to deliver emergency calls in the real world. > > >> Explicit acknowledgement seems to me valuable in that case. The > > >> other option is to re-write the documents to clarify that not any > > >> packet-switched network nor any network using IP fits this set of > > >> assumptions; that seems to me likely to take longer and > > not add much. > > >> > > >> You've already had Keith note that he would object to the > > documents > > >> if they did not contain language like that which was in > > -09. If it > > >> is taken out, I believe the documents will need a major > > editing pass > > >> to accomplish the clarification without the explicit text. > > This text > > >> is a compromise already, and the issue it deals with is > > important. > > >> Unless we are going to pretend that the IMS model simply doesn't > > >> exist and won't be used to deliver a substantial fraction of > > >> emergency calls for a good long time to come, we need it. > > If we are > > >> going to pretend that, I think we are being very foolish indeed. > > >> > > >> Ted > > >> > > >> > > >> > > >>> Having to change the way the device initiates an > > emergency call when > > >>> something as prosaic as the access technology changes is akin to > > >>> having to change your web browser just because the access > > technology > > >>> has changed. It's neither helpful nor harmless to have > > such a restriction. > > >>> > > >>> A helpful statement to put in the BCP might be "Other > > architectures, > > >>> such as IMS Emergency calling defined by 3GPP and 3GPP2, > > which are > > >>> not based on the ECRIT framework are likely to not be compatible > > >>> with devices and emergency networks which assume this framework - > > >>> e.g. such as is defined by NENA as i3." > > >>> > > >>> I don't endorse the inclusion of such a statement; it's > > commentary - > > >>> as is the proposed "applicability statement" and > > commentary is unnecessary. > > >>> Nevertheless, I think it's a more accurate characterization. That > > >>> is, it's more the case that the 3GPP IMS emergency architecture > > >>> doesn't fit ECRIT than it is that ECRIT doesn't fit a > > 3GPP access network. > > >>> > > >>> Cheers, > > >>> Martin > > >>> > > >>> > > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > >>> Behalf Of Edge, Stephen > > >>> Sent: Friday, 1 May 2009 2:29 AM > > >>> To: Bernard Aboba; Thomson, Martin; ecrit@ietf.org > > >>> Subject: Re: [Ecrit] PhoneBCP > > >>> > > >>> Bernard and others > > >>> > > >>> This is an interesting view - an admission that the Ecrit > > solution > > >>> will probably not be universally applied and when it is may be > > >>> subject to modification. On the 3GPP/3GPP2 sides, solutions are > > >>> defined with a specific and explicit scope and are > > expected to be - > > >>> and nearly always actually are - supported exactly as > > defined in the > > >>> appropriate spec.s for all scenarios covered by the scope. A > > >>> solution whose deployment is unpredictable will be less useful > > >>> because of the implied interworking problems between incompatible > > >>> implementations. That is a main reason why I and others initially > > >>> tried to include a more precise applicability/scope > > statement than > > >>> the one we are now discussing. Specifically, the Ecrit > > solution will > > >>> probably not be deployed by > > >>> 3GPP/3GPP2 operators for cellular terminals because they have > > >>> defined a > > > >> somewhat different solution more suitable for cellular > > operation. > > > >> That means > > >>> that a terminal supporting only the Ecrit solution (based on an > > >>> assertion of universal ap > > >> plicability) will encounter problems when its user attempts an > > >> emergency call on a 3GPP/3GPP2 network. If I can extend your > > >> analogies, this would be like not including a precise menu > > >> description for a meal containing meat and/or fish in a > > restaurant catering to both vegetarians and non-vegetarians. > > >>> > > >>> Kind Regards > > >>> > > >>> Stephen > > >>> > > >>> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > >>> Sent: Thursday, April 30, 2009 1:13 AM > > >>> To: Edge, Stephen; martin.thomson@andrew.com; ecrit@ietf.org > > >>> Subject: RE: [Ecrit] PhoneBCP > > >>> > > >>>> Your interpretation of applicability is certainly > > extreme (yes or > > >>>> qualified yes to all questions) - removing any dependence on > > >>>> suitability or feasibility (which are the more normal > > benchmarks) > > >>>> and simply making a legalistic blanket assertion. (I can > > now more > > >>>> understand incidentally why the fictitious protocol > > police are so > > >>>> often invoked on matters of > > >>>> conformance.) > > >>>> > > >>>> But do others have any views on this? > > >>> > > >>> Here is my 2 pence. As noted in the Introduction, the > > Phone BCP document > > >>> and framework documents are closely related documents > > that need to > > >>> be read (and understood) together. In looking at Phone > > BCP, there > > >>> have been many situations in which I wondered what the > > >>> justification was for a requirement, only to find the (usually > > >>> persuasive) explanation in the corresponding section of > > the framework document. > > >>> > > >>> IMHO, the separation of the two documents is somewhat unnatural. > > >>> It's a bit like taking a meal, freeze drying it, and then > > presenting > > >>> the diner with a cup of powder and a cup of water and > > wondering why > > >>> they are left with a quizical look on their faces. Including > > >>> cooking instructions along with the two cups is not a > > fully satisfactory answer. > > >>> > > >>> Given this reality, if there is a need for text explaining the > > >>> fundamental assumptions of the architecture, the place > > for that text > > >>> is not in the BCP document, but in the framework > > document. As has > > >>> been noted by others, the entire BCP document is an applicability > > >>> statement, and when viewed in that way, the proposed text is not > > >>> only unnecessary, but somewhat confusing since required > > context for > > >>> the BCP document belongs in the framework document. If anything > > >>> more is necesary, it would probably be some additional > > instructions for the reader delving into the document set > > for the first time. > > >>> > > >>> Like any IETF effort, the framework and BCP documents will be > > >>> evaluated on their own merits. Athough this is an area with a > > >>> considerable regulatory component, I see little evidence that the > > >>> world at large is so in awe of the IETF that every word will be > > >>> taken as immutable truth. No doubt other SDOs will take > > issue with > > >>> these documents in whole or in part and will explain the basis of > > >>> their assessments and where necessary, their alternatives. As a > > >>> result, some portions of the architecture may be adopted, some > > >>> portions may be ignored, and others will be revised in an > > effort to address the issues encountered and improve their > > chances for deployment. > > >>> > > >>> With respect to this process, the addition of cautionary > > text is a > > >>> bit like the warning labels that we find on consumer products. > > >>> While it may be necessary in some legalistic sense, given the > > >>> expertise of the individuals assessing these documents, > > one wonders what the practical effect will be. > > >>> Typically these are individuals who already understand > > that it is a > > >>> good idea to double-cup hot coffee. > > >>> > > >>> > > >>> > > >>> > > -------------------------------------------------------------------- > > >>> --------- > > >>> ------------------- > > >>> This message is for the designated recipient only and may contain > > >>> privileged, proprietary, or otherwise private information. > > >>> If you have received it in error, please notify the sender > > >>> immediately and delete the original. Any unauthorized > > use of this > > >>> email is prohibited. > > >>> > > -------------------------------------------------------------------- > > >>> --------- > > > >> ------------------- > > >>> [mf2] > > >>> > > >>> Content-Type: text/plain; name="ATT00001.txt" > > >>> Content-Description: ATT00001.txt > > >>> Content-Disposition: attachment; filename="ATT00001.txt"; > > size=194; > > >>> creation-date="Thu, 30 Apr 2009 09:49:15 GMT"; > > >>> modification-date="Thu, 30 Apr 2009 09:49:15 GMT" > > >>> > > >>> Attachment converted: Macintosh HD:ATT00001 5257.txt (TEXT/ttxt) > > >>> (0040366B) > > >> > > >> _______________________________________________ > > >> 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 randy@qualcomm.com Thu May 14 18:07:06 2009 Return-Path: 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 DA65C3A6CA7 for ; Thu, 14 May 2009 18:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.618 X-Spam-Level: X-Spam-Status: No, score=-105.618 tagged_above=-999 required=5 tests=[AWL=0.981, 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 yJlCfrANmgIp for ; Thu, 14 May 2009 18:07:06 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id EA0143A6C79 for ; Thu, 14 May 2009 18:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1242349719; x=1273885719; h=mime-version:message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:content-type: x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<029001c9d49e$3bdf6ff0$b 39e4fd0$@net>|References:=20=0D=0A=20=0D=0A =20<28B7C3AA2A7ABA4A841F11217ABE78D6759ED5FD@FRMRSSXCHMBS B3.dc-m.alcatel-=0D=0A=20lucent.com>=20<029001c9d49e$3bdf 6ff0$b39e4fd0$@net>|X-Mailer:=20Eudora=20for=20Mac=20OS =20X|X-message-Note:=20Warning:=20Outlook=20in=20use.=20 =20Upgrade=20to=20Eudora:=20|Date: =20Thu,=2014=20May=202009=2018:04:02=20-0700|To:=20Brian =20Rosen=20,=0D=0A=20=20=20=20=20=20 =20=20"'DRAGE,=20Keith=20(Keith)'"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"'Ted=20Hardie '"=20,=0D=0A=20=20=20=20=20=20=20=20 "'Marc=0D=0A=20Linsner'"=20,=20|From:=20Randall=20Gellens=20|Subject:=20Re:=20[Ecrit]=20PhoneBCP|Content-Type:=20te xt/plain=3B=20charset=3D"us-ascii"=3B=20format=3Dflowed |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5615"=3B=20 a=3D"18197400"; bh=9ir4qYwdmNGifTcYtG+Z+w7RGarMnmln8s4V6TaKqDc=; b=AzVvQEL9wXjWZJX3ZI4n6i0zF6R2FkGtuTWeP3JkOGaGAKF3cGwqhyO0 FUTvG2mYMZNztU404TNy+v3hriqdTRo3QpsmnjjgxXHcQWlDzwND6uTR5 /zrpmlClvuZMrbRfrJ9GtPirU3Y0mUMk6p3U0ORObh3TWhNljoVLxSlPk M=; X-IronPort-AV: E=McAfee;i="5300,2777,5615"; a="18197400" 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; 14 May 2009 18:08:39 -0700 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 n4F18cCp009780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 May 2009 18:08:39 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4F18Xa4016822 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 14 May 2009 18:08:38 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 14 May 2009 18:08:37 -0700 Received: from [192.168.99.14] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 14 May 2009 18:08:36 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <029001c9d49e$3bdf6ff0$b39e4fd0$@net> References: <28B7C3AA2A7ABA4A841F11217ABE78D6759ED5FD@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> <029001c9d49e$3bdf6ff0$b39e4fd0$@net> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 14 May 2009 18:04:02 -0700 To: Brian Rosen , "'DRAGE, Keith (Keith)'" , "'Ted Hardie'" , "'Marc Linsner'" , From: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , X-List-Received-Date: Fri, 15 May 2009 01:07:06 -0000 At 10:13 AM -0400 5/14/09, Brian Rosen wrote: > What you mean is that 3GPP has chosen to go a different direction. The > phonebcp procedures would work fine in IMS systems if operators chose to > implement them. There is no inherent disconnect. Phonebcp makes pretty sweeping statements about the way that emergency calls are placed, and makes a large number of statements instructing phone-centric behavior which doesn't work well for cellular phones. There are very small number of statements allowing in some cases for network elements to handle some of the phone-centric tasks. From br@brianrosen.net Thu May 14 18:36:25 2009 Return-Path: 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 08A8228C350 for ; Thu, 14 May 2009 18:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 QFVA3qUobQt3 for ; Thu, 14 May 2009 18:36:24 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 544583A6B80 for ; Thu, 14 May 2009 18:36:24 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1M4mMo-0007JI-Nl; Thu, 14 May 2009 20:37:43 -0500 From: "Brian Rosen" To: "'Randall Gellens'" , "'DRAGE, Keith \(Keith\)'" , "'Ted Hardie'" , "'Marc Linsner'" , References: <28B7C3AA2A7ABA4A841F11217ABE78D6759ED5FD@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> <029001c9d49e$3bdf6ff0$b39e4fd0$@net> In-Reply-To: Date: Thu, 14 May 2009 21:37:53 -0400 Message-ID: <039a01c9d4fd$c60e4c50$522ae4f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnU+ab4hVVu+0obQT64USULyPrljgAA5qqw 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] 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: , X-List-Received-Date: Fri, 15 May 2009 01:36:25 -0000 Please cite an instance. We do not believe that the requirement for the endpoint to query the LIS or the LoST server is onerous on any cellular network. In the scheme of things that IP based devices (we are talking about IP connected devices, not current GSM/CDMA systems) are expected to do, a HELD and LoST query is very modest in bandwidth, code size and compute power. Brian > -----Original Message----- > From: Randall Gellens [mailto:randy@qualcomm.com] > Sent: Thursday, May 14, 2009 9:04 PM > To: Brian Rosen; 'DRAGE, Keith (Keith)'; 'Ted Hardie'; 'Marc Linsner'; > ecrit@ietf.org > Subject: Re: [Ecrit] PhoneBCP > > At 10:13 AM -0400 5/14/09, Brian Rosen wrote: > > > What you mean is that 3GPP has chosen to go a different direction. > The > > phonebcp procedures would work fine in IMS systems if operators > chose to > > implement them. There is no inherent disconnect. > > Phonebcp makes pretty sweeping statements about the way that > emergency calls are placed, and makes a large number of statements > instructing phone-centric behavior which doesn't work well for > cellular phones. There are very small number of statements allowing > in some cases for network elements to handle some of the > phone-centric tasks. From jmpolk@cisco.com Thu May 14 18:37:36 2009 Return-Path: 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 010CA3A6C79 for ; Thu, 14 May 2009 18:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 eoFPtGbP5HDi for ; Thu, 14 May 2009 18:37:35 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0C9A03A6B80 for ; Thu, 14 May 2009 18:37:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,197,1241395200"; d="scan'208";a="304779408" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 15 May 2009 01:39:04 +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 n4F1d4BP004027; Thu, 14 May 2009 18:39:04 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4F1d4dE017369; Fri, 15 May 2009 01:39:04 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 May 2009 18:39:04 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.75.211]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 May 2009 18:39:04 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 14 May 2009 20:39:02 -0500 To: Randall Gellens , Brian Rosen , "'DRAGE, Keith (Keith)'" , "'Ted Hardie'" , "'Marc Linsner'" , From: "James M. Polk" In-Reply-To: References: <28B7C3AA2A7ABA4A841F11217ABE78D6759ED5FD@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> <029001c9d49e$3bdf6ff0$b39e4fd0$@net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 15 May 2009 01:39:04.0083 (UTC) FILETIME=[EDF4D630:01C9D4FD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1285; t=1242351544; x=1243215544; 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]=20PhoneBCP |Sender:=20; bh=YyBv1pVPsBnNb9C0GL7KqNN9B9jOJpdKcI+Eq9zrO3c=; b=N4/mcJq8et5rLRYgvt33HxgMbIJc0oeaEgUrwhpmm2CkrBQzWz4hbvRHAt 6DPBjpmD2dnN0xhz44K6js3llQSyUDXH78MZNHTyTURbK9+JdmxuEo+GXOb3 YxXtlqdklk; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 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: , X-List-Received-Date: Fri, 15 May 2009 01:37:36 -0000 At 08:04 PM 5/14/2009, Randall Gellens wrote: >At 10:13 AM -0400 5/14/09, Brian Rosen wrote: > >> What you mean is that 3GPP has chosen to go a different direction. The >> phonebcp procedures would work fine in IMS systems if operators chose to >> implement them. There is no inherent disconnect. > >Phonebcp makes pretty sweeping statements about the way that >emergency calls are placed, and makes a large number of statements >instructing phone-centric behavior which doesn't work well for >cellular phones. There are very small number of statements allowing >in some cases for network elements to handle some of the phone-centric tasks. I'm beginning to think the worst mistake we've made (possibly as an SDO) is to call anything a "phone", which is legacy and has a whole host of baggage attached. We should just say "UA" (or UAC or UAS) and let the reader figure out what we mean... At least IMS doesn't call their endpoints UAs, choosing UEs instead - hence, eliminating the confusion (if we use different acronyms) ...you can continue with your regularly scheduled programming now.... >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From randy@qualcomm.com Thu May 14 21:51:17 2009 Return-Path: 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 0CEF53A7067 for ; Thu, 14 May 2009 21:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.67 X-Spam-Level: X-Spam-Status: No, score=-103.67 tagged_above=-999 required=5 tests=[AWL=-1.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJnajHHvyt0a for ; Thu, 14 May 2009 21:51:15 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id C2C073A6E09 for ; Thu, 14 May 2009 21:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1242363156; x=1273899156; h=mime-version:message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:content-type: x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<039a01c9d4fd$c60e4c50$5 22ae4f0$@net>|References:=20=0D=0A=20=0D=0A =20<28B7C3AA2A7ABA4A841F11217ABE78D6759ED5FD@FRMRSSXCHMBS B3.dc-m.alcatel-=0D=0A=20lucent.com>=20<029001c9d49e$3bdf 6ff0$b39e4fd0$@net>=0D=0A=20=0D=0A=20<039a01c9d4fd$c60e4c50$522ae4f0$@net> |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|X-message-Note: =20Warning:=20Outlook=20in=20use.=20=20Upgrade=20to=20Eud ora:=20|Date:=20Thu,=2014=20May=20 2009=2021:47:00=20-0700|To:=20Brian=20Rosen=20,=0D=0A=20=20=20=20=20=20=20=20"'DRAGE,=20Keith =20(Keith)'"=0D=0A=09,=0D=0A=20 =20=20=20=20=20=20=20"'Ted=20Hardie'"=20,=0D=0A=20=20=20=20=20=20=20=20"'Marc=0D=0A=20=20Lins ner'"=20,=20|From:=20 Randall=20Gellens=20|Subject:=20Re: =20[Ecrit]=20PhoneBCP|Content-Type:=20text/plain=3B=20cha rset=3D"us-ascii"=3B=20format=3Dflowed|X-IronPort-AV:=20E =3DMcAfee=3Bi=3D"5300,2777,5615"=3B=20a=3D"18201386"; bh=Eqfvz/hPvoDqdshaBoQNrmh0oCqF1vTJilvXMpnVrhE=; b=aoFb9VkJYJYbMaF8fTGCxLaLvuwnyyQ9al73QNQdOmwZxRm2noLlefYO yqnBR5FV2CEVt47sqZyv17zeVeKY6cuBnw08FBjPFGO7I1U6eKjRIDlFn tFg57dEwx28xF/bz7aVqhE/XelWDZ3YbPHjGLGfouHLBJkHfb5IF4OESX c=; X-IronPort-AV: E=McAfee;i="5300,2777,5615"; a="18201386" 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 May 2009 21:52:36 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4F4qZAE016034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 May 2009 21:52:35 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4F4qZRW025526 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 14 May 2009 21:52:35 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 14 May 2009 21:52:35 -0700 Received: from [192.168.99.14] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 14 May 2009 21:52:34 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <039a01c9d4fd$c60e4c50$522ae4f0$@net> References: <28B7C3AA2A7ABA4A841F11217ABE78D6759ED5FD@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> <029001c9d49e$3bdf6ff0$b39e4fd0$@net> <039a01c9d4fd$c60e4c50$522ae4f0$@net> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 14 May 2009 21:47:00 -0700 To: Brian Rosen , "'DRAGE, Keith (Keith)'" , "'Ted Hardie'" , "'Marc Linsner'" , From: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , X-List-Received-Date: Fri, 15 May 2009 04:51:17 -0000 At 9:37 PM -0400 5/14/09, Brian Rosen wrote: > Please cite an instance. > > We do not believe that the requirement for the endpoint to query the LIS or > the LoST server is onerous on any cellular network. In the scheme of things > that IP based devices (we are talking about IP connected devices, not > current GSM/CDMA systems) are expected to do, a HELD and LoST query is very > modest in bandwidth, code size and compute power. The instructions are for devices to determine their location when powered on and frequently thereafter, and do LoST queries afterwards. This may be fine for many devices, but not for cellphones. From James.Winterbottom@andrew.com Thu May 14 22:07:52 2009 Return-Path: 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 3E3B83A701F for ; Thu, 14 May 2009 22:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.245 X-Spam-Level: X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 GO3ohDo8C4Kw for ; Thu, 14 May 2009 22:07:51 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 309503A6AFA for ; Thu, 14 May 2009 22:07:51 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_05_15_00_30_29 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 15 May 2009 00:30:29 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 May 2009 00:09:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 May 2009 00:09:22 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnVGQJJlNZ8SA94TauHL9U+qo1Z7QAAD/yQ References: <28B7C3AA2A7ABA4A841F11217ABE78D6759ED5FD@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <029001c9d49e$3bdf6ff0$b39e4fd0$@net><039a01c9d4fd$c60e4c50$522ae4f0$@net> From: "Winterbottom, James" To: "Randall Gellens" , "Brian Rosen" , "DRAGE, Keith (Keith)" , "Ted Hardie" , "MarcLinsner" , X-OriginalArrivalTime: 15 May 2009 05:09:23.0612 (UTC) FILETIME=[4FC825C0:01C9D51B] 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: , X-List-Received-Date: Fri, 15 May 2009 05:07:52 -0000 Randy,=0D=0A=0D=0ADo you agree that when a call is made from a mobile devic= e (IP or=0D=0Aotherwise), that the steps of acquiring the device's location= , then=0D=0Adetermining the route to the correct PSAP are necessary=3F=0D=0A=0D= =0A23.167 allows the device to acquire its location ahead of time from the=0D= =0AIP can, how is this different to ECRIT=3F Are you saying that 23.167=0D=0A= requires explicit wording to say that if the device is a cellphone it=0D=0A= must not do this=3F=0D=0A=0D=0APerhaps the rules in phone BCP surrounding w= ireless devices needing to=0D=0Apoll periodically is not desired behaviour.= Perhaps the correct=0D=0Abehaviour is do it when you first connect, do it = at call time, do it if=0D=0Ayou change networks because your LIS will have = changed. In each of these=0D=0Acases the device will need to be active anyw= ay, so the argument of=0D=0Aconsuming more battery because the device has t= o move out of idle mode=0D=0Ais totally moot.=0D=0A=0D=0ABrian, do you take= exception to my proposed change=3F=0D=0AIt still provides a fallback optio= n if the attempt fails at call time,=0D=0Aand it still allows the device to= route with the best data possible if=0D=0Aeverything is working okay.=0D=0A=0D= =0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A-----Original Message-----=0D=0AFrom:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf R= andall Gellens=0D=0ASent: Friday, 15 May 2009 2:47 PM=0D=0ATo: Brian Rosen;= 'DRAGE, Keith (Keith)'; 'Ted Hardie'; 'MarcLinsner';=0D=0Aecrit@ietf.org=0D= =0ASubject: Re: [Ecrit] PhoneBCP=0D=0A=0D=0AAt 9:37 PM -0400 5/14/09, Brian= Rosen wrote:=0D=0A=0D=0A> Please cite an instance.=0D=0A>=0D=0A> We do n= ot believe that the requirement for the endpoint to query the=0D=0ALIS or=0D= =0A> the LoST server is onerous on any cellular network. In the scheme of=0D= =0Athings=0D=0A> that IP based devices (we are talking about IP connected = devices, not=0D=0A> current GSM/CDMA systems) are expected to do, a HELD a= nd LoST query=0D=0Ais very=0D=0A> modest in bandwidth, code size and compu= te power.=0D=0A=0D=0AThe instructions are for devices to determine their lo= cation when=20=0D=0Apowered on and frequently thereafter, and do LoST queri= es afterwards.=20=0D=0AThis may be fine for many devices, but not for cellp= hones.=0D=0A=0D=0A_______________________________________________=0D=0AEcri= t mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/listin= fo/ecrit=0D=0A=0D=0A-------------------------------------------------------= -----------------------------------------=0D=0AThis message is for the desi= gnated recipient only and may=0D=0Acontain privileged, proprietary, or othe= rwise private information. =20=0D=0AIf you have received it in error, pleas= e notify the sender=0D=0Aimmediately and delete the original. Any unauthor= ized use of=0D=0Athis email is prohibited.=0D=0A---------------------------= ---------------------------------------------------------------------=0D=0A= [mf2]=0D=0A From Martin.Dawson@andrew.com Fri May 15 00:10:27 2009 Return-Path: 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 59BBC28C16D for ; Fri, 15 May 2009 00:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.159 X-Spam-Level: X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 LpC2VLEUW3ir for ; Fri, 15 May 2009 00:10:26 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id E68453A6B2B for ; Fri, 15 May 2009 00:10:25 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_05_15_02_33_05 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 15 May 2009 02:33:04 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 May 2009 02:11:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 May 2009 02:11:57 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnVGQJIi+KsTvOtT+Cz/vVGEjORNgAEvJ1A References: <28B7C3AA2A7ABA4A841F11217ABE78D6759ED5FD@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <029001c9d49e$3bdf6ff0$b39e4fd0$@net><039a01c9d4fd$c60e4c50$522ae4f0$@net> From: "Dawson, Martin" To: "Randall Gellens" , "Brian Rosen" , "DRAGE, Keith (Keith)" , "Ted Hardie" , "MarcLinsner" , X-OriginalArrivalTime: 15 May 2009 07:11:59.0175 (UTC) FILETIME=[7009FD70:01C9D52C] 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: , X-List-Received-Date: Fri, 15 May 2009 07:10:27 -0000 I've got a G1 here that says you're wrong...=0D=0A=0D=0AAnd an iPhone on so= meone else's desk over there... though those devices=0D=0Aare not to my tas= te.=0D=0A=0D=0AIt's all IP to them and the clients are dead easy to make.=0D= =0A=0D=0AIs 3G somehow "fake Internet" in your opinion then=3F=0D=0A=0D=0AC= heers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-b= ounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf Randall G= ellens=0D=0ASent: Friday, 15 May 2009 2:47 PM=0D=0ATo: Brian Rosen; 'DRAGE,= Keith (Keith)'; 'Ted Hardie'; 'MarcLinsner';=0D=0Aecrit@ietf.org=0D=0ASubj= ect: Re: [Ecrit] PhoneBCP=0D=0A=0D=0AAt 9:37 PM -0400 5/14/09, Brian Rosen = wrote:=0D=0A=0D=0A> Please cite an instance.=0D=0A>=0D=0A> We do not beli= eve that the requirement for the endpoint to query the=0D=0ALIS or=0D=0A> = the LoST server is onerous on any cellular network. In the scheme of=0D=0A= things=0D=0A> that IP based devices (we are talking about IP connected dev= ices, not=0D=0A> current GSM/CDMA systems) are expected to do, a HELD and = LoST query=0D=0Ais very=0D=0A> modest in bandwidth, code size and compute = power.=0D=0A=0D=0AThe instructions are for devices to determine their locat= ion when=20=0D=0Apowered on and frequently thereafter, and do LoST queries = afterwards.=20=0D=0AThis may be fine for many devices, but not for cellphon= es.=0D=0A=0D=0A_______________________________________________=0D=0AEcrit m= ailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo/= ecrit=0D=0A=0D=0A----------------------------------------------------------= --------------------------------------=0D=0AThis message is for the designa= ted recipient only and may=0D=0Acontain privileged, proprietary, or otherwi= se private information. =20=0D=0AIf you have received it in error, please n= otify the sender=0D=0Aimmediately and delete the original. Any unauthorize= d use of=0D=0Athis email is prohibited.=0D=0A------------------------------= ------------------------------------------------------------------=0D=0A[mf= 2]=0D=0A From Martin.Dawson@andrew.com Fri May 15 00:25:02 2009 Return-Path: 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 5DEF53A6B2B for ; Fri, 15 May 2009 00:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 jvoyGnhGrMBD for ; Fri, 15 May 2009 00:24:57 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id D07FB3A6BF7 for ; Fri, 15 May 2009 00:24:56 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_05_15_02_31_48 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 15 May 2009 02:31:47 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 May 2009 02:10:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 May 2009 02:10:40 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PhoneBCP Thread-Index: AcnU/fKU9IK+41VoR6KMUUGlTP+LmAALcZFg References: <28B7C3AA2A7ABA4A841F11217ABE78D6759ED5FD@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <029001c9d49e$3bdf6ff0$b39e4fd0$@net> From: "Dawson, Martin" To: "James M. Polk" , "Randall Gellens" , "Brian Rosen" , "DRAGE, Keith (Keith)" , "Ted Hardie" , "Marc Linsner" , X-OriginalArrivalTime: 15 May 2009 07:10:41.0956 (UTC) FILETIME=[42034E40:01C9D52C] 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: , X-List-Received-Date: Fri, 15 May 2009 07:25:02 -0000 Amen.=0D=0A=0D=0AThe whole concept of a phone is so... 20th century.=0D=0A=0D= =0AAt best it's anachronistic term. In not too many more years, it'll just=0D= =0Asound quaint.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Me= ssage-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf=0D=0AOf James M. Polk=0D=0ASent: Friday, 15 May 2009 11:39 AM=0D= =0ATo: Randall Gellens; Brian Rosen; 'DRAGE, Keith (Keith)'; 'Ted Hardie';=0D= =0A'Marc Linsner'; ecrit@ietf.org=0D=0ASubject: Re: [Ecrit] PhoneBCP=0D=0A=0D= =0AAt 08:04 PM 5/14/2009, Randall Gellens wrote:=0D=0A>At 10:13 AM -0400 5/= 14/09, Brian Rosen wrote:=0D=0A>=0D=0A>> What you mean is that 3GPP has ch= osen to go a different direction.=0D=0AThe=0D=0A>> phonebcp procedures wou= ld work fine in IMS systems if operators=0D=0Achose to=0D=0A>> implement t= hem. There is no inherent disconnect.=0D=0A>=0D=0A>Phonebcp makes pretty s= weeping statements about the way that=20=0D=0A>emergency calls are placed, = and makes a large number of statements=20=0D=0A>instructing phone-centric b= ehavior which doesn't work well for=20=0D=0A>cellular phones. There are ve= ry small number of statements allowing=20=0D=0A>in some cases for network e= lements to handle some of the phone-centric=0D=0Atasks.=0D=0A=0D=0AI'm begi= nning to think the worst mistake we've made (possibly as an=20=0D=0ASDO) is= to call anything a "phone", which is legacy and has a whole=20=0D=0Ahost o= f baggage attached.=0D=0A=0D=0AWe should just say "UA" (or UAC or UAS) and = let the reader figure out=20=0D=0Awhat we mean... At least IMS doesn't cal= l their endpoints UAs,=20=0D=0Achoosing UEs instead - hence, eliminating th= e confusion (if we use=20=0D=0Adifferent acronyms)=0D=0A=0D=0A=0D=0A=0D= =0A...you can continue with your regularly scheduled programming now....=0D= =0A=0D=0A=0D=0A>_______________________________________________=0D=0A>Ecrit= mailing list=0D=0A>Ecrit@ietf.org=0D=0A>https://www.ietf.org/mailman/listi= nfo/ecrit=0D=0A=0D=0A_______________________________________________=0D=0AE= crit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/lis= tinfo/ecrit=0D=0A=0D=0A----------------------------------------------------= --------------------------------------------=0D=0AThis message is for the d= esignated recipient only and may=0D=0Acontain privileged, proprietary, or o= therwise private information. =20=0D=0AIf you have received it in error, pl= ease notify the sender=0D=0Aimmediately and delete the original. Any unaut= horized use of=0D=0Athis email is prohibited.=0D=0A------------------------= ------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A From br@brianrosen.net Fri May 15 05:10:39 2009 Return-Path: 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 EC15D3A70CC for ; Fri, 15 May 2009 05:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 ZLzHDmtlGETV for ; Fri, 15 May 2009 05:10:39 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 3E7753A6768 for ; Fri, 15 May 2009 05:10:39 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1M4wGk-0007lw-Iz; Fri, 15 May 2009 07:12:06 -0500 From: "Brian Rosen" To: "'Randall Gellens'" , "'DRAGE, Keith \(Keith\)'" , "'Ted Hardie'" , "'Marc Linsner'" , References: <28B7C3AA2A7ABA4A841F11217ABE78D6759ED5FD@FRMRSSXCHMBSB3.dc-m.alcatel- lucent.com> <029001c9d49e$3bdf6ff0$b39e4fd0$@net> <039a01c9d4fd$c60e4c50$522ae4f0$@net> In-Reply-To: Date: Fri, 15 May 2009 08:12:09 -0400 Message-ID: <045f01c9d556$60eb58f0$22c20ad0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnVGPaaldy+WM/zSbCDdv0JgPIq/gAPS3Kw 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] 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: , X-List-Received-Date: Fri, 15 May 2009 12:10:40 -0000 Since an increasing proportion of devices are used with location based services, that would seem to be incorrect. The text says "periodically" not "frequently", and the location you acquire is routing location, which is cell tower based for most mobiles. That is not in the least onerous. Brian > -----Original Message----- > From: Randall Gellens [mailto:randy@qualcomm.com] > Sent: Friday, May 15, 2009 12:47 AM > To: Brian Rosen; 'DRAGE, Keith (Keith)'; 'Ted Hardie'; 'Marc Linsner'; > ecrit@ietf.org > Subject: Re: [Ecrit] PhoneBCP > > At 9:37 PM -0400 5/14/09, Brian Rosen wrote: > > > Please cite an instance. > > > > We do not believe that the requirement for the endpoint to query the > LIS or > > the LoST server is onerous on any cellular network. In the scheme > of things > > that IP based devices (we are talking about IP connected devices, > not > > current GSM/CDMA systems) are expected to do, a HELD and LoST query > is very > > modest in bandwidth, code size and compute power. > > The instructions are for devices to determine their location when > powered on and frequently thereafter, and do LoST queries afterwards. > This may be fine for many devices, but not for cellphones. From drage@alcatel-lucent.com Fri May 15 07:29:41 2009 Return-Path: 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 A8DC728C304 for ; Fri, 15 May 2009 07:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.905 X-Spam-Level: X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=0.344, 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 vp0CVU8MWDum for ; Fri, 15 May 2009 07:29:39 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 117A028C432 for ; Fri, 15 May 2009 07:28:44 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n4FEUFse002368 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 15 May 2009 16:30:15 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 15 May 2009 16:30:15 +0200 From: "DRAGE, Keith (Keith)" To: Milan Patel , Christer Holmberg , John-Luc Bakker , Gonzalo Camarillo Date: Fri, 15 May 2009 16:30:11 +0200 Thread-Topic: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Thread-Index: AcmgoqEwGgnKMKiDS8KCxn9Oay/pdQnYyfBwAayUNIAABijoAAAKf6qwAZu1eWA= Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6759ED819@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <499D6530.9040208@ericsson.com><0913B6CD18F370498CD65864CF254E9008DA24B2@zharhxm1.corp.nortel.com><49B4F019.2020904@ericsson.com><0913B6CD18F370498CD65864CF254E90097B3549@zharhxm1.corp.nortel.com> <0913B6CD18F370498CD65864CF254E9009927A32@zharhxm1.corp.nortel.com> In-Reply-To: <0913B6CD18F370498CD65864CF254E9009927A32@zharhxm1.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.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: , X-List-Received-Date: Fri, 15 May 2009 14:29:41 -0000 I would like to support Milan's reasoning here. I do not believe use of an option-tag helps. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Milan Patel > Sent: Thursday, May 07, 2009 11:44 AM > To: Christer Holmberg; John-Luc Bakker; Gonzalo Camarillo > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Expert review of > draft-patel-ecrit-sos-parameter-03.txt > > Hi John-Luc, > > Firstly, it is my understanding that emergency registration > occurs when the emergency call request is detected by the UE > (e.g. user dials 911). > The duration of this emergency registration is also not > specified to be the same as that of a normal registration. > > Secondly, if the registrar were to reject the emergency > registration because it did not support the "sos" URI > parameter, and no other registration existed, the UE would > have to initiate an unauthenticated emergency call. Surely, > it would make more sense to either register the user, even if > it means overriding an existing non-emergency registration or > if using 3GPP IMS, the network can return a 380 response to > the UE, forcing it to use for example the CS domain. > > Upon receiving the 420 response, if the UAC attempts > registration again, then this registration would be treated > as a non-emergency registration. > This is the same result as ignoring the URI parameter if the > registrar did not support it. > > Therefore, I still think the current procedures are sufficient. > > Regards, > Milan > > Milan Patel > Carrier Networks Core Standards > Nortel > milanpa@nortel.com > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 > 9261 / ESN 748 9261 > > For the Companies listed below, The Institute of Chartered > Accountants in England and Wales authorises A R Bloom, S > Harris and C Hill to act as Insolvency Practitioners under > section 390(2)(a) of the Insolvency Act > 1986 and the Association of Chartered Certified Accountants > authorises A M Hudson to act as an Insolvency Practitioner > under section 390(2)(a) of the Insolvency Act 1986. > > The affairs, business and property of the Companies are being > managed by the Joint Administrators, A R Bloom, S Harris, AM > Hudson and C Hill who act as agents of the Companies only and > without personal liability. > > The Companies are Nortel Networks UK Limited; Nortel Networks > SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks > NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks > Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks > (Austria) GmbH; Nortel Networks sro; Nortel Networks > Engineering Service Kft; Nortel Networks Portugal SA; Nortel > Networks Slovensko sro; Nortel Networks Oy; Nortel Networks > Romania SRL; Nortel Networks AB; Nortel Networks > International Finance & Holding BV > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 07 May 2009 06:05 > To: John-Luc Bakker; Patel, Milan (MOP:EP10); Gonzalo Camarillo > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Expert review of > draft-patel-ecrit-sos-parameter-03.txt > > > Hi, > > My comments between the and tags. > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of John-Luc Bakker > > Sent: 7. toukokuuta 2009 6:08 > > To: Milan Patel; Gonzalo Camarillo > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Expert review of > > draft-patel-ecrit-sos-parameter-03.txt > > > > Hi Milan, > > > > I would like to pick up on Gonzalo's comment below: > > > > > The document does not talk about backwards compatibility. > > What happens > > > if the registrar does not understand the 'sos' parameter? > > Will it do > > > the right thing? Will the UAC detect the failure? Is there > > a need to > > > define an option tag?... the document should address these points. > > > > In the meanwhile, the document does talk about backwards > > compatibility. > > > > However, the legacy registrar will do the only (right) thing > > it can do but from a perspective of the UE that might not be > > the anticipated > > (right) thing. > > > > It is my understanding that an emergency registration can > > happen at any time and a UE is not required to immediately > > follow up the successful registration with an emergency call > > or tear down the emergency registration after the emergency call. > > > > Suppose a UAC has one public user identity and it performs a > > normal registration with some feature tags. Subsequently, the > > same UAC performs an emergency registration with different > > feature tags. Would the legacy registrar "refresh" the > > binding, then the S-CSCF would apply "emergency" > > feature tags to all session requests. > > > > An option tag would prevent this. > > > > If in agreement, I suggest the following changes to the draft > > (between and tags): > > > > 4.1. REGISTER Request > > > > When the UA sends a REGISTER request for emergency > > registration, the > > "sos" URI parameter MUST be appended to the URI in the Contact > > Header and the option-tag "e-reg" must be included in > > the Proxy-Require and Require header. This serves as > > an indication to the > > registrar that the > > request is for emergency registration and it is only > > accepted if emergency registration is supported. > > > > Example: > > > > Contact: "Alice" ;q=3D0.7; expires=3D360= 0 > > > > In the event that more than one Contact header field is > included in > > the REGISTER request, only the contact addresses that include the > > "sos" URI parameter shall be considered as emergency registered > > contact addresses. > > > > > > Upon receipt of a 420 (Bad Extension) response the UAC will > > use an existing registration or initiate another registration. > > > > > Why would you need to insert the option-tag in the > Proxy-Require header) > Why do you need intermediates to support the "sos" parameter? Isn't it > enough if the registrar, which in this case acts as UAS (and therefor > applies the Require header) support the "sos" parameter? > > > Regards, > > Christer > > > > > > > > > > > > 4.3. Backwards compatibility issues > > > > The backwards compatibility scenario considered in this > document is > > where a legacy registrar does not support the "sos" URI > parameter. > > > > > > This document registers an option tag with IANA in section 6.2. > > Inclusion of the option tag will prevent a legacy registrar > > from handling the request. > > > > > > 6. IANA Considerations > > > > 6.2 SIP URI parameter > > > > This specification defines one new SIP URI parameter, as per the > > registry created by RFC 3969 [RFC3969] > > > > Parameter Name: sos > > > > Predefined Values: none > > > > Reference: [RFCXXXX] > > > > [NOTE TO IANA: Please replace XXXX with the RFC number of this > > specification.] > > > > 6.2 SIP Option Tag > > > > This specification registers a new SIP option tag, as per the > > guidelines in Section 27.1 of RFC 3261 [RFC3261]. > > > > Name: e-reg > > > > Description: This option tag is used to identify the > > emergency registration extension. When used in a Supported > > header, it indicates that a User Agent understands the > > extension. When used in a Require header field of a REGISTER > > request, it indicates that the registrar is not expected to > > process the registration unless it supports the emergency > > registration extension. > > > > > > Regards, > > > > John-Luc > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Milan Patel > > Sent: Tuesday, April 28, 2009 8:36 AM > > To: Gonzalo Camarillo > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Expert review of > > draft-patel-ecrit-sos-parameter-03.txt > > > > Hi Gonzalo, > > > > Version 4 of draft-patel-ecrit-sos-parameter addresses all > > the comments you provided in the expert review. Please can > > you confirm that you are OK with its contents and that all > > the issues you had previously highlighted are now resolved. > > http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-04 > > Best regards, > > Milan > > > > Milan Patel > > Carrier Networks Core Standards > > Nortel > > milanpa@nortel.com > > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 > > 9261 / ESN 748 9261 > > > > For the Companies listed below, The Institute of Chartered > > Accountants in England and Wales authorises A R Bloom, S > > Harris and C Hill to act as Insolvency Practitioners under > > section 390(2)(a) of the Insolvency Act > > 1986 and the Association of Chartered Certified Accountants > > authorises A M Hudson to act as an Insolvency Practitioner > > under section 390(2)(a) of the Insolvency Act 1986. > > > > The affairs, business and property of the Companies are being > > managed by the Joint Administrators, A R Bloom, S Harris, AM > > Hudson and C Hill who act as agents of the Companies only and > > without personal liability. > > > > The Companies are Nortel Networks UK Limited; Nortel Networks > > SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks > > NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks > > Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks > > (Austria) GmbH; Nortel Networks sro; Nortel Networks > > Engineering Service Kft; Nortel Networks Portugal SA; Nortel > > Networks Slovensko sro; Nortel Networks Oy; Nortel Networks > > Romania SRL; Nortel Networks AB; Nortel Networks > > International Finance & Holding BV > > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > Sent: 09 March 2009 10:32 > > To: Patel, Milan (MOP:EP10) > > Cc: ecrit@ietf.org; Hannes Tschofenig > > Subject: Re: [Ecrit] Expert review of > > draft-patel-ecrit-sos-parameter-03.txt > > > > Hi, > > > > the problem with this text is that it specifies behavior for > > entities that will not implement this specification. The new > > section should describe how a legacy registrar will handle, > > following regular SIP rules, a REGISTER request with the sos > > parameter. However, it cannot specify extra behavior for such > > a legacy registrar. That is the whole point of backwards > > compatibility: to support unchanged legacy applications that > > will not implement the new functionality. > > > > In any case, I believe you can use most of the text you > > proposed below. > > It just needs to be rephrased so that it is more descriptive > > and non normative. > > > > Thanks, > > > > Gonzalo > > > > Milan Patel wrote: > > > Folks, > > > > > > In response to Gonzalo's comment on backwards > > compatibility, I propose > > > > > a subclause "4.3 Backwards compatibility issues" as follows: > > > > > > > > > ---------------------------------------------------------------------- > > > -- > > > ---------------------------------- > > > 4.3 Backwards compatibility issues > > > The backwards compatibility scenario considered in this > document is > > > where the registrar does not support the "sos" URI > > parameter. In this > > > case, if the registrar receives a REGISTER request that > > includes the > > > "sos" URI parameter in the Contact header, the registrar > > MUST proceed > > > with registration procedures and silently ignore the > > URI-parameter in > > > accordance with RFC 3261. This ensures the user is > > registered and thus > > > > > can successfully initiate an emergency call. > > > > > > The drawback of proceeding with registration is if the > > > address-of-record is barred or has roaming restrictions > > applied, then > > > these restrictions will not be lifted and thus > registration will be > > > unsuccessful. This may limit the UAC's ability to > successfully place > > an emergency call. > > > > > > If registration is successful, the registrar shall return a > > 200 (OK) > > > response to the UAC and does not include the "sos" URI > parameter in > > > the Contact header. The UAC is aware of its registered > > contact address > > > > > and address-of-record, however, cannot distinguish between this > > > registration and a non-emergency registration. > > > > > > ---------------------------------------------------------------------- > > > -- > > > -------------------------------------- > > > > > > Comments/feedback/suggestions for improvement are > > appreciated. I will > > > address Gonzalo's other comments in version -04 of the > > draft as well. > > > > > > Best regards, > > > Milan > > > > > > Milan Patel > > > Carrier Networks Core Standards > > > Nortel > > > milanpa@nortel.com > > > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 > 053 9261 / > > > ESN 748 9261 > > > > > > For the Companies listed below, The Institute of Chartered > > Accountants > > > > > in England and Wales authorises A R Bloom, S Harris and C > > Hill to act > > > as Insolvency Practitioners under section 390(2)(a) of the > > Insolvency > > > Act > > > 1986 and the Association of Chartered Certified Accountants > > authorises > > > > > A M Hudson to act as an Insolvency Practitioner under section > > > 390(2)(a) of the Insolvency Act 1986. > > > > > > The affairs, business and property of the Companies are > > being managed > > > by the Joint Administrators, A R Bloom, S Harris, AM Hudson > > and C Hill > > > > > who act as agents of the Companies only and without personal > > liability. > > > > > > The Companies are Nortel Networks UK Limited; Nortel Networks SA; > > > Nortel GmbH; Nortel Networks France SAS; Nortel Networks > NV; Nortel > > > Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; > > > Nortel Networks Hispania SA; Nortel Networks (Austria) > GmbH; Nortel > > > Networks sro; Nortel Networks Engineering Service Kft; > > Nortel Networks > > > > > Portugal SA; Nortel Networks Slovensko sro; Nortel Networks > > Oy; Nortel > > > > > Networks Romania SRL; Nortel Networks AB; Nortel Networks > > > International Finance & Holding BV > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Gonzalo Camarillo > > > Sent: 19 February 2009 13:57 > > > To: ecrit@ietf.org > > > Subject: [Ecrit] Expert review of > > > draft-patel-ecrit-sos-parameter-03.txt > > > > > > Folks, > > > > > > I have been asked to perform an expert review of the > > following draft: > > > > > > http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt > > > > > > The approach taken by the draft seems OK in general. I have a few > > > comments though: > > > > > > The requirement in Section 3 is too specific because it already > > > assumes that the solution will be an indication in the SIP header > > > fields. The requirement does not need to make that > > assumption. I would > > > > > remove "by providing an appropriate indication in the SIP header > > fields". > > > > > > In Section 5, the reference to RFC 2234 should be replaced > > with one to > > > > > RFC 5234. > > > > > > Also in Section 5, the formal syntax should be rewritten so > > that it is > > > > > compatible with the ABNF in RFC 3261. RFC 3261 already defines > > > uri-parameter as follows: > > > > > > uri-parameter =3D transport-param / user-param / method-param > > > / ttl-param / maddr-param / lr-param / > > > other-param > > > > > > other-param =3D pname [ "=3D" pvalue ] > > > pname =3D 1*paramchar > > > pvalue =3D 1*paramchar > > > > > > This document should simply define a new value for pname. > > > > > > The document does not talk about backwards compatibility. > > What happens > > > > > if the registrar does not understand the 'sos' parameter? > > Will it do > > > the right thing? Will the UAC detect the failure? Is there > > a need to > > > define an option tag?... the document should address these points. > > > > > > Cheers, > > > > > > Gonzalo > > > > > > _______________________________________________ > > > 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 > > > > > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain > > confidential information, privileged material (including > > material protected by the solicitor-client or other > > applicable privileges), or constitute non-public information. > > Any use of this information by anyone other than the intended > > recipient is prohibited. If you have received this > > transmission in error, please immediately reply to the sender > > and delete this information from your system. Use, > > dissemination, distribution, or reproduction of this > > transmission by unintended recipients is not authorized and > > may be unlawful. > > _______________________________________________ > > 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 christer.holmberg@ericsson.com Mon May 18 05:37:05 2009 Return-Path: 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 010773A6AE0 for ; Mon, 18 May 2009 05:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.57 X-Spam-Level: X-Spam-Status: No, score=-4.57 tagged_above=-999 required=5 tests=[AWL=-0.921, BAYES_50=0.001, 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 fQOAvNolTtdZ for ; Mon, 18 May 2009 05:36:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 374DA3A68C0 for ; Mon, 18 May 2009 05:36:52 -0700 (PDT) X-AuditID: c1b4fb3c-b7bc6ae0000009e3-6e-4a1156b234d6 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id C7.CB.02531.2B6511A4; Mon, 18 May 2009 14:38:10 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 May 2009 14:38:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 May 2009 14:38:06 +0200 Message-ID: In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D6759ED819@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Thread-Index: AcmgoqEwGgnKMKiDS8KCxn9Oay/pdQnYyfBwAayUNIAABijoAAAKf6qwAZu1eWAAkvMHEA== References: <499D6530.9040208@ericsson.com><0913B6CD18F370498CD65864CF254E9008DA24B2@zharhxm1.corp.nortel.com><49B4F019.2020904@ericsson.com><0913B6CD18F370498CD65864CF254E90097B3549@zharhxm1.corp.nortel.com> <0913B6CD18F370498CD65864CF254E9009927A32@zharhxm1.corp.nortel.com> <28B7C3AA2A7ABA4A841F11217ABE78D6759ED819@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "Milan Patel" , "John-Luc Bakker" , "Gonzalo Camarillo" X-OriginalArrivalTime: 18 May 2009 12:38:07.0971 (UTC) FILETIME=[7F308B30:01C9D7B5] X-Brightmail-Tracker: AAAAAA== Cc: ecrit@ietf.org Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.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: , X-List-Received-Date: Mon, 18 May 2009 12:37:05 -0000 Hi, I agree with Milan and Keith. Regards, Christer=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: 15. toukokuuta 2009 17:30 > To: Milan Patel; Christer Holmberg; John-Luc Bakker; Gonzalo Camarillo > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Expert review of=20 > draft-patel-ecrit-sos-parameter-03.txt >=20 > I would like to support Milan's reasoning here. >=20 > I do not believe use of an option-tag helps. >=20 > Keith >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Milan Patel > > Sent: Thursday, May 07, 2009 11:44 AM > > To: Christer Holmberg; John-Luc Bakker; Gonzalo Camarillo > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Expert review of > > draft-patel-ecrit-sos-parameter-03.txt > > > > Hi John-Luc, > > > > Firstly, it is my understanding that emergency registration occurs=20 > > when the emergency call request is detected by the UE (e.g.=20 > user dials=20 > > 911). > > The duration of this emergency registration is also not=20 > specified to=20 > > be the same as that of a normal registration. > > > > Secondly, if the registrar were to reject the emergency=20 > registration=20 > > because it did not support the "sos" URI parameter, and no other=20 > > registration existed, the UE would have to initiate an=20 > unauthenticated=20 > > emergency call. Surely, it would make more sense to either register=20 > > the user, even if it means overriding an existing non-emergency=20 > > registration or if using 3GPP IMS, the network can return a 380=20 > > response to the UE, forcing it to use for example the CS domain. > > > > Upon receiving the 420 response, if the UAC attempts registration=20 > > again, then this registration would be treated as a non-emergency=20 > > registration. > > This is the same result as ignoring the URI parameter if=20 > the registrar=20 > > did not support it. > > > > Therefore, I still think the current procedures are sufficient. > > > > Regards, > > Milan > > > > Milan Patel > > Carrier Networks Core Standards > > Nortel > > milanpa@nortel.com > > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 > > 9261 / ESN 748 9261 > > > > For the Companies listed below, The Institute of Chartered=20 > Accountants=20 > > in England and Wales authorises A R Bloom, S Harris and C=20 > Hill to act=20 > > as Insolvency Practitioners under section 390(2)(a) of the=20 > Insolvency=20 > > Act > > 1986 and the Association of Chartered Certified Accountants=20 > authorises=20 > > A M Hudson to act as an Insolvency Practitioner under section=20 > > 390(2)(a) of the Insolvency Act 1986. > > > > The affairs, business and property of the Companies are=20 > being managed=20 > > by the Joint Administrators, A R Bloom, S Harris, AM Hudson=20 > and C Hill=20 > > who act as agents of the Companies only and without personal=20 > > liability. > > > > The Companies are Nortel Networks UK Limited; Nortel Networks SA;=20 > > Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel=20 > > Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo;=20 > > Nortel Networks Hispania SA; Nortel Networks > > (Austria) GmbH; Nortel Networks sro; Nortel Networks Engineering=20 > > Service Kft; Nortel Networks Portugal SA; Nortel Networks Slovensko=20 > > sro; Nortel Networks Oy; Nortel Networks Romania SRL;=20 > Nortel Networks=20 > > AB; Nortel Networks International Finance & Holding BV > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: 07 May 2009 06:05 > > To: John-Luc Bakker; Patel, Milan (MOP:EP10); Gonzalo Camarillo > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Expert review of > > draft-patel-ecrit-sos-parameter-03.txt > > > > > > Hi, > > > > My comments between the and tags. > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > > > Behalf Of John-Luc Bakker > > > Sent: 7. toukokuuta 2009 6:08 > > > To: Milan Patel; Gonzalo Camarillo > > > Cc: ecrit@ietf.org > > > Subject: Re: [Ecrit] Expert review of=20 > > > draft-patel-ecrit-sos-parameter-03.txt > > > > > > Hi Milan, > > > > > > I would like to pick up on Gonzalo's comment below: > > > > > > > The document does not talk about backwards compatibility. > > > What happens > > > > if the registrar does not understand the 'sos' parameter? > > > Will it do > > > > the right thing? Will the UAC detect the failure? Is there > > > a need to > > > > define an option tag?... the document should address=20 > these points. > > > > > > In the meanwhile, the document does talk about backwards=20 > > > compatibility. > > > > > > However, the legacy registrar will do the only (right)=20 > thing it can=20 > > > do but from a perspective of the UE that might not be the=20 > > > anticipated > > > (right) thing. > > > > > > It is my understanding that an emergency registration can=20 > happen at=20 > > > any time and a UE is not required to immediately follow up the=20 > > > successful registration with an emergency call or tear down the=20 > > > emergency registration after the emergency call. > > > > > > Suppose a UAC has one public user identity and it=20 > performs a normal=20 > > > registration with some feature tags. Subsequently, the same UAC=20 > > > performs an emergency registration with different feature tags.=20 > > > Would the legacy registrar "refresh" the binding, then the S-CSCF=20 > > > would apply "emergency" > > > feature tags to all session requests. > > > > > > An option tag would prevent this. > > > > > > If in agreement, I suggest the following changes to the draft=20 > > > (between and tags): > > > > > > 4.1. REGISTER Request > > > > > > When the UA sends a REGISTER request for emergency=20 > registration,=20 > > > the > > > "sos" URI parameter MUST be appended to the URI in the Contact > > > Header and the option-tag "e-reg" must be included in the=20 > > > Proxy-Require and Require header. This serves as an=20 > > > indication to the > > > registrar that the > > > request is for emergency registration and it is only=20 > > > accepted if emergency registration is supported. > > > > > > Example: > > > > > > Contact: "Alice" ;q=3D0.7;=20 > expires=3D3600 > > > > > > In the event that more than one Contact header field is > > included in > > > the REGISTER request, only the contact addresses that=20 > include the > > > "sos" URI parameter shall be considered as emergency registered > > > contact addresses. > > > > > > > > > Upon receipt of a 420 (Bad Extension) response the UAC=20 > will use an=20 > > > existing registration or initiate another registration. > > > > > > > > > Why would you need to insert the option-tag in the Proxy-Require=20 > > header) Why do you need intermediates to support the "sos"=20 > parameter?=20 > > Isn't it enough if the registrar, which in this case acts=20 > as UAS (and=20 > > therefor applies the Require header) support the "sos" parameter? > > > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > 4.3. Backwards compatibility issues > > > > > > The backwards compatibility scenario considered in this > > document is > > > where a legacy registrar does not support the "sos" URI > > parameter. > > > > > > > > > This document registers an option tag with IANA in section 6.2. > > > Inclusion of the option tag will prevent a legacy registrar from=20 > > > handling the request. > > > > > > > > > 6. IANA Considerations > > > > > > 6.2 SIP URI parameter > > > > > > This specification defines one new SIP URI parameter,=20 > as per the > > > registry created by RFC 3969 [RFC3969] > > > > > > Parameter Name: sos > > > > > > Predefined Values: none > > > > > > Reference: [RFCXXXX] > > > > > > [NOTE TO IANA: Please replace XXXX with the RFC number of this > > > specification.] > > > > > > 6.2 SIP Option Tag > > > > > > This specification registers a new SIP option tag, as per the=20 > > > guidelines in Section 27.1 of RFC 3261 [RFC3261]. > > > > > > Name: e-reg > > > > > > Description: This option tag is used to identify the emergency=20 > > > registration extension. When used in a Supported header, it=20 > > > indicates that a User Agent understands the extension. =20 > When used in=20 > > > a Require header field of a REGISTER request, it=20 > indicates that the=20 > > > registrar is not expected to process the registration unless it=20 > > > supports the emergency registration extension. > > > > > > > > > Regards, > > > > > > John-Luc > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > > > Behalf Of Milan Patel > > > Sent: Tuesday, April 28, 2009 8:36 AM > > > To: Gonzalo Camarillo > > > Cc: ecrit@ietf.org > > > Subject: Re: [Ecrit] Expert review of=20 > > > draft-patel-ecrit-sos-parameter-03.txt > > > > > > Hi Gonzalo, > > > > > > Version 4 of draft-patel-ecrit-sos-parameter addresses all the=20 > > > comments you provided in the expert review. Please can=20 > you confirm=20 > > > that you are OK with its contents and that all the issues you had=20 > > > previously highlighted are now resolved. > > > http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-04 > > > Best regards, > > > Milan > > > > > > Milan Patel > > > Carrier Networks Core Standards > > > Nortel > > > milanpa@nortel.com > > > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 > > > 9261 / ESN 748 9261 > > > > > > For the Companies listed below, The Institute of Chartered=20 > > > Accountants in England and Wales authorises A R Bloom, S=20 > Harris and=20 > > > C Hill to act as Insolvency Practitioners under section=20 > 390(2)(a) of=20 > > > the Insolvency Act > > > 1986 and the Association of Chartered Certified Accountants=20 > > > authorises A M Hudson to act as an Insolvency Practitioner under=20 > > > section 390(2)(a) of the Insolvency Act 1986. > > > > > > The affairs, business and property of the Companies are being=20 > > > managed by the Joint Administrators, A R Bloom, S Harris,=20 > AM Hudson=20 > > > and C Hill who act as agents of the Companies only and without=20 > > > personal liability. > > > > > > The Companies are Nortel Networks UK Limited; Nortel Networks SA;=20 > > > Nortel GmbH; Nortel Networks France SAS; Nortel Networks=20 > NV; Nortel=20 > > > Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo;=20 > > > Nortel Networks Hispania SA; Nortel Networks > > > (Austria) GmbH; Nortel Networks sro; Nortel Networks Engineering=20 > > > Service Kft; Nortel Networks Portugal SA; Nortel Networks=20 > Slovensko=20 > > > sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel=20 > > > Networks AB; Nortel Networks International Finance & Holding BV > > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > > Sent: 09 March 2009 10:32 > > > To: Patel, Milan (MOP:EP10) > > > Cc: ecrit@ietf.org; Hannes Tschofenig > > > Subject: Re: [Ecrit] Expert review of=20 > > > draft-patel-ecrit-sos-parameter-03.txt > > > > > > Hi, > > > > > > the problem with this text is that it specifies behavior for=20 > > > entities that will not implement this specification. The=20 > new section=20 > > > should describe how a legacy registrar will handle, following=20 > > > regular SIP rules, a REGISTER request with the sos parameter.=20 > > > However, it cannot specify extra behavior for such a legacy=20 > > > registrar. That is the whole point of backwards > > > compatibility: to support unchanged legacy applications that will=20 > > > not implement the new functionality. > > > > > > In any case, I believe you can use most of the text you proposed=20 > > > below. > > > It just needs to be rephrased so that it is more=20 > descriptive and non=20 > > > normative. > > > > > > Thanks, > > > > > > Gonzalo > > > > > > Milan Patel wrote: > > > > Folks, > > > > > > > > In response to Gonzalo's comment on backwards > > > compatibility, I propose > > > > > > > a subclause "4.3 Backwards compatibility issues" as follows: > > > > > > > > > > > > >=20 > ---------------------------------------------------------------------- > > > > -- > > > > ---------------------------------- > > > > 4.3 Backwards compatibility issues > > > > The backwards compatibility scenario considered in this > > document is > > > > where the registrar does not support the "sos" URI > > > parameter. In this > > > > case, if the registrar receives a REGISTER request that > > > includes the > > > > "sos" URI parameter in the Contact header, the registrar > > > MUST proceed > > > > with registration procedures and silently ignore the > > > URI-parameter in > > > > accordance with RFC 3261. This ensures the user is > > > registered and thus > > > > > > > can successfully initiate an emergency call. > > > > > > > > The drawback of proceeding with registration is if the=20 > > > > address-of-record is barred or has roaming restrictions > > > applied, then > > > > these restrictions will not be lifted and thus > > registration will be > > > > unsuccessful. This may limit the UAC's ability to > > successfully place > > > an emergency call. > > > > > > > > If registration is successful, the registrar shall return a > > > 200 (OK) > > > > response to the UAC and does not include the "sos" URI > > parameter in > > > > the Contact header. The UAC is aware of its registered > > > contact address > > > > > > > and address-of-record, however, cannot distinguish between this=20 > > > > registration and a non-emergency registration. > > > > > > > > >=20 > ---------------------------------------------------------------------- > > > > -- > > > > -------------------------------------- > > > > > > > > Comments/feedback/suggestions for improvement are > > > appreciated. I will > > > > address Gonzalo's other comments in version -04 of the > > > draft as well. > > > > > > > > Best regards, > > > > Milan > > > > > > > > Milan Patel > > > > Carrier Networks Core Standards > > > > Nortel > > > > milanpa@nortel.com > > > > Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 > > 053 9261 / > > > > ESN 748 9261 > > > > > > > > For the Companies listed below, The Institute of Chartered > > > Accountants > > > > > > > in England and Wales authorises A R Bloom, S Harris and C > > > Hill to act > > > > as Insolvency Practitioners under section 390(2)(a) of the > > > Insolvency > > > > Act > > > > 1986 and the Association of Chartered Certified Accountants > > > authorises > > > > > > > A M Hudson to act as an Insolvency Practitioner under section > > > > 390(2)(a) of the Insolvency Act 1986. > > > > > > > > The affairs, business and property of the Companies are > > > being managed > > > > by the Joint Administrators, A R Bloom, S Harris, AM Hudson > > > and C Hill > > > > > > > who act as agents of the Companies only and without personal > > > liability. > > > > > > > > The Companies are Nortel Networks UK Limited; Nortel=20 > Networks SA;=20 > > > > Nortel GmbH; Nortel Networks France SAS; Nortel Networks > > NV; Nortel > > > > Networks SpA; Nortel Networks BV; Nortel Networks=20 > Polska SP Zoo;=20 > > > > Nortel Networks Hispania SA; Nortel Networks (Austria) > > GmbH; Nortel > > > > Networks sro; Nortel Networks Engineering Service Kft; > > > Nortel Networks > > > > > > > Portugal SA; Nortel Networks Slovensko sro; Nortel Networks > > > Oy; Nortel > > > > > > > Networks Romania SRL; Nortel Networks AB; Nortel Networks=20 > > > > International Finance & Holding BV > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of Gonzalo Camarillo > > > > Sent: 19 February 2009 13:57 > > > > To: ecrit@ietf.org > > > > Subject: [Ecrit] Expert review of > > > > draft-patel-ecrit-sos-parameter-03.txt > > > > > > > > Folks, > > > > > > > > I have been asked to perform an expert review of the > > > following draft: > > > > > > > > http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt > > > > > > > > The approach taken by the draft seems OK in general. I=20 > have a few=20 > > > > comments though: > > > > > > > > The requirement in Section 3 is too specific because it already=20 > > > > assumes that the solution will be an indication in the=20 > SIP header=20 > > > > fields. The requirement does not need to make that > > > assumption. I would > > > > > > > remove "by providing an appropriate indication in the SIP header > > > fields". > > > > > > > > In Section 5, the reference to RFC 2234 should be replaced > > > with one to > > > > > > > RFC 5234. > > > > > > > > Also in Section 5, the formal syntax should be rewritten so > > > that it is > > > > > > > compatible with the ABNF in RFC 3261. RFC 3261 already defines=20 > > > > uri-parameter as follows: > > > > > > > > uri-parameter =3D transport-param / user-param /=20 > method-param > > > > / ttl-param / maddr-param / lr-param /=20 > > > > other-param > > > > > > > > other-param =3D pname [ "=3D" pvalue ] > > > > pname =3D 1*paramchar > > > > pvalue =3D 1*paramchar > > > > > > > > This document should simply define a new value for pname. > > > > > > > > The document does not talk about backwards compatibility. > > > What happens > > > > > > > if the registrar does not understand the 'sos' parameter? > > > Will it do > > > > the right thing? Will the UAC detect the failure? Is there > > > a need to > > > > define an option tag?... the document should address=20 > these points. > > > > > > > > Cheers, > > > > > > > > Gonzalo > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > >=20 > --------------------------------------------------------------------- > > > This transmission (including any attachments) may contain=20 > > > confidential information, privileged material (including material=20 > > > protected by the solicitor-client or other applicable=20 > privileges),=20 > > > or constitute non-public information. > > > Any use of this information by anyone other than the intended=20 > > > recipient is prohibited. If you have received this=20 > transmission in=20 > > > error, please immediately reply to the sender and delete this=20 > > > information from your system. Use, dissemination,=20 > distribution, or=20 > > > reproduction of this transmission by unintended recipients is not=20 > > > authorized and may be unlawful. > > > _______________________________________________ > > > 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 > > >=20 From Hannes.Tschofenig@gmx.net Tue May 19 06:28:24 2009 Return-Path: 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 F261B28C30C for ; Tue, 19 May 2009 06:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.039 X-Spam-Level: * X-Spam-Status: No, score=1.039 tagged_above=-999 required=5 tests=[AWL=1.038, 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 Zx5KK7jJkMRv for ; Tue, 19 May 2009 06:28:24 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 979CE3A6D12 for ; Tue, 19 May 2009 06:28:23 -0700 (PDT) Received: (qmail invoked by alias); 19 May 2009 13:29:58 -0000 Received: from 207.47.37.13.static.nextweb.net (EHLO 4FIL42860) [207.47.37.13] by mail.gmx.net (mp018) with SMTP; 19 May 2009 15:29:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+qvNFWrdCq0OT4RqSsiTha1nV44cg9xapRCQ82IU 6kGpHyMixRkXJB From: "Hannes Tschofenig" To: "'ECRIT'" Date: Tue, 19 May 2009 16:31:41 +0300 Message-ID: <016101c9d886$26c8c940$1d00a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcnYhiS53q9RbPEGRK+w9H+wBb/mrQ== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68 Subject: [Ecrit] Twitter saves Woman 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: , X-List-Received-Date: Tue, 19 May 2009 13:28:25 -0000 FYI: An Atlanta city councilman used Twitter to help save the life of a woman who suffered a seizure in northeast Atlanta. Kwanza Hall tweeted instead of dialing 911 Friday evening when he spotted a woman in need of medical assistance at the corner of John Wesley Dobbs Avenue and Jackson Street. He said he used Twitter because his cell phone battery was running low and he didn't want to end up stuck on hold with 911. More: http://www.wsbtv.com/news/19492556/detail.html From spencer@wonderhamster.org Tue May 19 08:39:08 2009 Return-Path: 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 A86B33A6BA0 for ; Tue, 19 May 2009 08:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.912 X-Spam-Level: X-Spam-Status: No, score=-0.912 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eb2PAK0mfQal for ; Tue, 19 May 2009 08:39:07 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id B71493A6AC9 for ; Tue, 19 May 2009 08:39:07 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1M6RQn15Bg-000fox; Tue, 19 May 2009 11:40:43 -0400 Message-ID: <7F02169203364CFB9FF250790CA74619@china.huawei.com> From: "Spencer Dawkins" To: "Hannes Tschofenig" , "'ECRIT'" References: <016101c9d886$26c8c940$1d00a8c0@nsnintra.net> Date: Tue, 19 May 2009 10:40:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/NBNNH6+RLmoWO4pLbjHwfnWIaFMWOYQ7pJhX NU4lDY6XZNG64wa2qXEazqmPCws0i+ATKoWVSXUKBfI140mL0y INAI96iQcgVUTbpw2gRU9Tpvk3dnE2tseuIxMEf36M= Subject: Re: [Ecrit] Twitter saves Woman 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: , X-List-Received-Date: Tue, 19 May 2009 15:39:08 -0000 Hi, Hannes, Thanks for sharing! > FYI: > > An Atlanta city councilman used Twitter to help save the life of a woman > who > suffered a seizure in northeast Atlanta. > > Kwanza Hall tweeted instead of dialing 911 Friday evening when he spotted > a > woman in need of medical assistance at the corner of John Wesley Dobbs > Avenue and Jackson Street. > > He said he used Twitter because his cell phone battery was running low and > he didn't want to end up stuck on hold with 911. Great. The ultimate premature call termination - deciding to hang up before you start dialing ... :D > More: > http://www.wsbtv.com/news/19492556/detail.html Thanks, Spencer From wwwrun@core3.amsl.com Tue May 19 13:15:40 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 59D4628C142; Tue, 19 May 2009 13:15:40 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090519201540.59D4628C142@core3.amsl.com> Date: Tue, 19 May 2009 13:15:40 -0700 (PDT) X-Mailman-Approved-At: Tue, 19 May 2009 14:07:57 -0700 Cc: ecrit chair , Internet Architecture Board , ecrit mailing list , RFC Editor Subject: [Ecrit] Document Action: 'Location-to-URL Mapping Architecture and Framework' to Informational RFC 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: , X-List-Received-Date: Tue, 19 May 2009 20:15:40 -0000 The IESG has approved the following document: - 'Location-to-URL Mapping Architecture and Framework ' as an Informational RFC This document is the product of the Emergency Context Resolution with Internet Technologies Working Group. The IESG contact persons are Cullen Jennings and Robert Sparks. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-04.txt Technical Summary The Location-to-URL mapping architecture document describes an architecture for a global, scalable, resilient and administratively distributed system for mapping geographic location information to URLs, using the Location-to-Service (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. Working Group Summary There is consensus in the WG to publish this document. Protocol Quality The LoST protocol has been implemented and the interaction between LoST nodes, as described in this document, has been tested. From rbarnes@bbn.com Thu May 28 04:26:21 2009 Return-Path: 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 AC8463A6C01 for ; Thu, 28 May 2009 04:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.317 X-Spam-Level: X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[AWL=-1.318, 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 3wkSHlxo3Ngy for ; Thu, 28 May 2009 04:26:15 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 108553A6C90 for ; Thu, 28 May 2009 04:25:48 -0700 (PDT) Received: from [128.89.254.143] (helo=Richard-Barnes-Laptop.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1M9dlf-0003OJ-C8 for ecrit@ietf.org; Thu, 28 May 2009 07:27:27 -0400 Message-ID: <4A1E751E.8070402@bbn.com> Date: Thu, 28 May 2009 07:27:26 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Ecrit] [Fwd: [ng112] no more emergency calls from non-activated SIM card mobile phones] 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: , X-List-Received-Date: Thu, 28 May 2009 11:26:21 -0000 Some news on the unauthenticated access problem (courtesy of Yacine Rebahi, via the ng112 list): HEISE News on May 27, 2009: No more emergency calls from mobile phones without activated SIM card (in Germany, from July on) Those who keep an old cell phone without a SIM card in the glove compartment of their car or in a hiking backpack for making emergency calls, should highlight 1st July red in the calendar. From this date on the emergency number 112 works only with a loaded and activated SIM card, said Rudolf Boll, speaker of the Federal Bundesnetzagentur in Bonn, in a conversation with DPA (Deutsche Presse Agentur). The SIM-card allows identification of the caller. "The call centers are often bombed with faked emergency calls, "Boll said with respect to the reasons of the change. We hope that the inhibition threshold will be raised when callers know that they can be identified. Previously, emergency calls could be made from any phone even without a SIM card. "There is still some way to clarify," said Boll. Technically should be regulated, for example, cases when emergency calls are made via prepaid SIM cards without deductible credit. Moreover, an emergency telephone connection should also be possible in case when only foreign networks without roaming agreement are available. Despite the restriction, the regulation will try to ensure that as many people as possible can make mobile emergency calls. Therefore, from 1 January 2010 on, it should be possible to make mobile emergency calls also by using SIM cards, for example, which have been turned off (e.g. after an end of contract). Technically, those SIM cards also allow for identification of the users. Without a SIM card in the phone from July 1, 2009, 112 calls will be no longer routed to the PSAPs. Link (in German): http://www.heise.de/mobil/Handy-Notruf-ab-Juli-nur-noch-mit-aktivierter- SIM-Karte-moeglich--/newsticker/meldung/139491 From mlinsner@cisco.com Thu May 28 11:50:39 2009 Return-Path: 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 D71CB3A69A4 for ; Thu, 28 May 2009 11:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.739 X-Spam-Level: X-Spam-Status: No, score=-5.739 tagged_above=-999 required=5 tests=[AWL=-0.537, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 m9B2zv50Lsvv for ; Thu, 28 May 2009 11:50:33 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E8DD03A6E19 for ; Thu, 28 May 2009 11:50:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,266,1241395200"; d="scan'208,217";a="45495920" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 28 May 2009 18:52:15 +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 n4SIqF7i004269 for ; Thu, 28 May 2009 14:52:15 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4SIqFIg002527 for ; Thu, 28 May 2009 18:52:15 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 May 2009 14:52:15 -0400 Received: from [10.116.195.120] ([10.116.195.120]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 14:52:14 -0400 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 28 May 2009 14:52:13 -0400 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: Reminder: Virtual Interim Meeting June 3 Thread-Index: AcnfxWmZVWPKe8eJkUKSdnQMNW3oJw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3326367134_1346599" X-OriginalArrivalTime: 28 May 2009 18:52:14.0902 (UTC) FILETIME=[6ABBE560:01C9DFC5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=790; t=1243536735; x=1244400735; 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:=20Reminder=3A=20Virtual=20Interim=20Meeting=20Jun e=203 |Sender:=20 |To:=20=22ecrit@ietf.org=22=20; bh=5Oo4e/xb2dv1uA74P7lIV3L6anfpc3IpuTHFdd91fIY=; b=URVgcMAtJeFSuF9C8+zXkxW9DMC5QZvDlzX7vLhCxuGP2BhvYUk5uhemcd pQpcmdTZP/vMt05pF/TRBoa2C69mH2Vd7GLPCQ9nKMt0yRcR8PiRcwHTFFT9 mEBNlLQgCU; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Ecrit] Reminder: Virtual Interim Meeting June 3 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: , X-List-Received-Date: Thu, 28 May 2009 18:50:39 -0000 > 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_3326367134_1346599 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Details at: http://trac.tools.ietf.org/wg/ecrit/trac/wiki -Hannes & Marc- --B_3326367134_1346599 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Reminder: Virtual Interim Meeting June 3 Details at: http:/= /trac.tools.ietf.org/wg/ecrit/trac/wiki

-Hannes & Marc- --B_3326367134_1346599-- From hannes.tschofenig@nsn.com Sun May 31 13:37:41 2009 Return-Path: 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 7F18E3A69FF for ; Sun, 31 May 2009 13:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 TTOaKW+oHncR for ; Sun, 31 May 2009 13:37:40 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 51E363A63EC for ; Sun, 31 May 2009 13:37:39 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n4VKbch3022566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 31 May 2009 22:37:38 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n4VKbccO017316 for ; Sun, 31 May 2009 22:37:38 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 31 May 2009 22:37:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 31 May 2009 23:39:28 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450164DA7A@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT Status Update (May 2009) Thread-Index: AcniL+SMqMBryu8sSFmGDggl5TPaOg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 31 May 2009 20:37:38.0319 (UTC) FILETIME=[A30601F0:01C9E22F] Subject: [Ecrit] ECRIT Status Update (May 2009) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 20:37:41 -0000 ECRIT Status Update (May 2009) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Last Thursday we had a chat with our ADs about the current status of the work in ECRIT. This status update provides some information regarding that chat. 1) ECRIT Virtual Interim Meeting We are going to have an interim meeting June 3rd. Marc sent a reminder around:=20 http://www.ietf.org/mail-archive/web/ecrit/current/msg06379.html 2) Framework and Phone BCP document=20 http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-framework/ http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-phonebcp/ Marc started a hum regarding the applicability statement, see http://www.ietf.org/mail-archive/web/ecrit/current/msg06245.html.=20 After attempts to come to resolution around the issue of the 'Applicability Statement', it's clear that we don't have consensus to include the current statement in the draft. The chairs are looking for discussion/contributions towards resolving this issue.=20 3) =20 Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-lost-sync/ We are still in the phase of waiting for implementers feedback.=20 Action Item: Hannes to query feedback from implementers.=20 4) SOS Uniform Resource Identifier (URI) Parameter for Marking of Session Initiation Protocol (SIP) Requests related to Emergency Services http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-06.txt Cullen is the document shepherd. Milan submitted another update last week and the PROTO writeup is ready. Cullen may ask for further reviews. Action Item: Hannes will submit updated PROTO writeup to Cullen with a pointer to the expert review by Gonzalo.=20 5) Location Hiding: Problem Statement and Requirements http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-location-hiding-req/ Review comments (e.g., by GenArt) received. Updated document needed.=20 Action item: Draft authors to update the draft.=20 6) Specifying Holes in LoST Service Boundaries http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-specifying-holes/ =20 Currently the document is in "Publication requested" state and Cullen did a review. He has a punch of comments that he needs to check with Martin Thomson.=20 Action item: Cullen to talk to Martin about his review before getting back to the group.=20 =20 7) Location-to-URL Mapping Architecture and Framework http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-mapping-arch/ Document is in RFC Editor Queue! 8) Premature Disconnect Indication Discussion seemed to have gotten stuck again. No new progress.=20 Action item: Hannes and Marc to provide a writeup on potential next steps.=20 =20 9) Milestone Update The following documents are not listed as milestones on our ECRIT charter. =20 - LoST Sync - Specifying Holes in LoST Service Boundaries - Location Hiding: Problem Statement and Requirements The milestone update last year must have gotten lost and nobody recognized it! Action Item: Hannes & Marc will submit a milestone update ASAP. 10) ECRIT Charter Update The ADs are still holding us to getting PhoneBCP and Framework out before adding more work to the group (via charter / milestone change). The following items are currently listed as pending for inclusion into the new charter:=20 * IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications =20 http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph -namespace-03.txt * Using Imprecise Location for Emergency Context Resolution http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc-02.txt * Policy for defining new service-identifying labels http://tools.ietf.org/id/draft-forte-ecrit-service-urn-policy-00.txt * Location-to-Service Translation Protocol (LoST) Extension: ServiceListBoundary http://tools.ietf.org/id/draft-wolf-ecrit-lost-servicelistboundary-01.tx t * Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-acces s * Marking of Calls initiated by Public Safety Answering Points (PSAPs) http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-00.txt Action Item: Hannes and Marc to compile a charter proposal that will become relevant once Phone BCP / Framework left the group.=20