From john.elwell@siemens-enterprise.com Fri Apr 8 00:48:43 2011 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 298EC3A6A55 for ; Fri, 8 Apr 2011 00:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 395g4ZBKr6cR for ; Fri, 8 Apr 2011 00:48:42 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 531E83A6972 for ; Fri, 8 Apr 2011 00:48:42 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4063232 for ecrit@ietf.org; Fri, 8 Apr 2011 09:50:26 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id F2EE51EB82B0 for ; Fri, 8 Apr 2011 09:50:25 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 8 Apr 2011 09:50:26 +0200 From: "Elwell, John" To: "ecrit@ietf.org" Date: Fri, 8 Apr 2011 09:50:25 +0200 Thread-Topic: Comment on latest changes to phone bcp - dial strings Thread-Index: Acv1wZ7CgjJeis2/QBWxcOfJnDfgTQ== Message-ID: 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: [Ecrit] Comment on latest changes to phone bcp - dial strings X-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 Apr 2011 07:48:43 -0000 In 9.2: "ED-63 The initial SIP signaling method is an INVITE request: 1. The Request URI SHOULD be the service URN in the "sos" tree. If the device does not interpret local dial strings, the Request- URI MUST be a dial string URI [RFC4967] with the dialed digits." I have a concern about the "MUST" in the last sentence (previously it was S= HOULD). If the device does not interpret local dial strings, it will not re= cognise an emergency call, and therefore cannot be expected to comply with = the requirements of this BCP. I am not aware of any RFC that updates RFC 3261 to mandate the use of RFC 4= 967 when sending a dial string, so therefore this statement in phone BCP is= effectively changing the behaviour of RFC 3261 for all calls (not just eme= rgency calls), which I believe should be outside the scope of the BCP. Different practices exist today for submitting dial strings, and acceptable= forms will depend on the local proxy. For example, often a URI in the form= "SIP:12345@example.com" is used in practice, and therefore for an emergenc= y call it would be, for example, "SIP:112@example.com". An example of acceptable text would be: "If the device does not interpret local dial strings and therefore is unabl= e to recognise a request for an emergency call, it will behave as for any o= ther call request for which the dial string cannot be interpreted. Normally= this will involve submitting the dial string in the INVITE request in a fo= rm acceptable to the local proxy (e.g., in the form of a dial string URI [R= FC4967])." John= From br@brianrosen.net Fri Apr 8 06:27:44 2011 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 65CD428C11D for ; Fri, 8 Apr 2011 06:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 QAdOtFWC03Fq for ; Fri, 8 Apr 2011 06:27:43 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by core3.amsl.com (Postfix) with ESMTP id 7939828C11C for ; Fri, 8 Apr 2011 06:27:43 -0700 (PDT) X-ASG-Debug-ID: 1302269366-011a9f5811213e0001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id pKPSVrjhDHzNxKpZ; Fri, 08 Apr 2011 06:29:26 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=ctho-lt61.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q8Bkb-0000C6-Er; Fri, 08 Apr 2011 06:29:26 -0700 Mime-Version: 1.0 (Apple Message framework v1084) X-ASG-Orig-Subj: Re: [Ecrit] Comment on latest changes to phone bcp - dial strings Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Fri, 8 Apr 2011 09:29:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3F2BF77F-027C-404D-9150-65D0396862C3@brianrosen.net> References: To: "Elwell, John" X-Mailer: Apple Mail (2.1084) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1302269366 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.60260 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Comment on latest changes to phone bcp - dial strings X-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 Apr 2011 13:27:44 -0000 The BCP can't cover devices that don't conform to it, so the fact that = some existing devices don't do what it says isn't relevant. This = doesn't update 3261. It says if you do emergency calls, do it this way. = The same applies to downstream proxies. Standardizing behavior makes = sure that regardless of the device and the proxy, the call will be = recognize as an emergency call and the right processing done for it. Emergency calls have some special processing. I'd love to mandate that = all devices conforming to it recognize dial strings, and process them = into the urn. There was objection to going that far, and thus we have = this alternate path. Your text won't work as is: it would have to be = followed by a new requirement on proxies to recognize anything the = device could put out. Brian On Apr 8, 2011, at 3:50 AM, Elwell, John wrote: > In 9.2: > "ED-63 The initial SIP signaling method is an INVITE request: > 1. The Request URI SHOULD be the service URN in the "sos" tree. = If > the device does not interpret local dial strings, the Request- > URI MUST be a dial string URI [RFC4967] with the dialed = digits." > I have a concern about the "MUST" in the last sentence (previously it = was SHOULD). If the device does not interpret local dial strings, it = will not recognise an emergency call, and therefore cannot be expected = to comply with the requirements of this BCP. >=20 > I am not aware of any RFC that updates RFC 3261 to mandate the use of = RFC 4967 when sending a dial string, so therefore this statement in = phone BCP is effectively changing the behaviour of RFC 3261 for all = calls (not just emergency calls), which I believe should be outside the = scope of the BCP. >=20 > Different practices exist today for submitting dial strings, and = acceptable forms will depend on the local proxy. For example, often a = URI in the form "SIP:12345@example.com" is used in practice, and = therefore for an emergency call it would be, for example, = "SIP:112@example.com". >=20 > An example of acceptable text would be: > "If the device does not interpret local dial strings and therefore is = unable to recognise a request for an emergency call, it will behave as = for any other call request for which the dial string cannot be = interpreted. Normally this will involve submitting the dial string in = the INVITE request in a form acceptable to the local proxy (e.g., in the = form of a dial string URI [RFC4967])." >=20 > John > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From john.elwell@siemens-enterprise.com Fri Apr 8 07:03:15 2011 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 1D92D3A6A0B for ; Fri, 8 Apr 2011 07:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.537 X-Spam-Level: X-Spam-Status: No, score=-104.537 tagged_above=-999 required=5 tests=[AWL=2.062, 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 LtwU+6EykgT3 for ; Fri, 8 Apr 2011 07:03:14 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by core3.amsl.com (Postfix) with SMTP id 8D5C43A690C for ; Fri, 8 Apr 2011 07:03:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1302271492!41871169!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 20723 invoked from network); 8 Apr 2011 14:04:52 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-14.tower-21.messagelabs.com with SMTP; 8 Apr 2011 14:04:52 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 7B7A523F02E6; Fri, 8 Apr 2011 16:04:57 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 8 Apr 2011 16:04:57 +0200 From: "Elwell, John" To: Brian Rosen Date: Fri, 8 Apr 2011 16:04:56 +0200 Thread-Topic: [Ecrit] Comment on latest changes to phone bcp - dial strings Thread-Index: Acv18P1wdhjc/E14R1a0aDbPdAwcKAAArO9Q Message-ID: References: <3F2BF77F-027C-404D-9150-65D0396862C3@brianrosen.net> In-Reply-To: <3F2BF77F-027C-404D-9150-65D0396862C3@brianrosen.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 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Comment on latest changes to phone bcp - dial strings X-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 Apr 2011 14:03:15 -0000 Brian, The problem with the text in the draft at present is it modifies behaviour = for non-emergency calls, and I don't think that is acceptable. I can imagine 3 types of devices: 1) Devices that comply with phonebcp, recognise an emergency dial string an= d convert to a service URN. 2) Devices that comply with phonebcp but do not recognise certain emergency= dial strings. 3) Devices that do not comply with phonebcp. To support type 3 devices, there will have to be some form of agreement bet= ween the device and the proxy as to how dial strings are delivered to the p= roxy. This applies to any dial string, whether it is for an emergency call = or something else. This is common practice today, and generally does not in= volve RFC 4967 Tel URIs. Many working implementations pre-date RFC 4967. To= support type 3 devices making emergency calls, proxies will presumably nee= d to recognise emergency dial strings when delivered by whatever means dial= strings are delivered by those devices.=20 So I don't see the sense of upgrading those proxies to also support RFC 496= 7 dial stings from type 2 devices. It would be better for proxies to treat = type 2 and type 3 devices the same. John > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: 08 April 2011 14:29 > To: Elwell, John > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Comment on latest changes to phone bcp -=20 > dial strings >=20 > The BCP can't cover devices that don't conform to it, so the=20 > fact that some existing devices don't do what it says isn't=20 > relevant. This doesn't update 3261. It says if you do=20 > emergency calls, do it this way. The same applies to=20 > downstream proxies. Standardizing behavior makes sure that=20 > regardless of the device and the proxy, the call will be=20 > recognize as an emergency call and the right processing done for it. >=20 > Emergency calls have some special processing. I'd love to=20 > mandate that all devices conforming to it recognize dial=20 > strings, and process them into the urn. There was objection=20 > to going that far, and thus we have this alternate path. =20 > Your text won't work as is: it would have to be followed by a=20 > new requirement on proxies to recognize anything the device=20 > could put out. >=20 > Brian > On Apr 8, 2011, at 3:50 AM, Elwell, John wrote: >=20 > > In 9.2: > > "ED-63 The initial SIP signaling method is an INVITE request: > > 1. The Request URI SHOULD be the service URN in the=20 > "sos" tree. If > > the device does not interpret local dial strings,=20 > the Request- > > URI MUST be a dial string URI [RFC4967] with the=20 > dialed digits." > > I have a concern about the "MUST" in the last sentence=20 > (previously it was SHOULD). If the device does not interpret=20 > local dial strings, it will not recognise an emergency call,=20 > and therefore cannot be expected to comply with the=20 > requirements of this BCP. > >=20 > > I am not aware of any RFC that updates RFC 3261 to mandate=20 > the use of RFC 4967 when sending a dial string, so therefore=20 > this statement in phone BCP is effectively changing the=20 > behaviour of RFC 3261 for all calls (not just emergency=20 > calls), which I believe should be outside the scope of the BCP. > >=20 > > Different practices exist today for submitting dial=20 > strings, and acceptable forms will depend on the local proxy.=20 > For example, often a URI in the form "SIP:12345@example.com"=20 > is used in practice, and therefore for an emergency call it=20 > would be, for example, "SIP:112@example.com". > >=20 > > An example of acceptable text would be: > > "If the device does not interpret local dial strings and=20 > therefore is unable to recognise a request for an emergency=20 > call, it will behave as for any other call request for which=20 > the dial string cannot be interpreted. Normally this will=20 > involve submitting the dial string in the INVITE request in a=20 > form acceptable to the local proxy (e.g., in the form of a=20 > dial string URI [RFC4967])." > >=20 > > John > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > = From br@brianrosen.net Fri Apr 8 07:30:54 2011 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 5F11E3A690C for ; Fri, 8 Apr 2011 07:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 bouCoSgzdsr7 for ; Fri, 8 Apr 2011 07:30:53 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by core3.amsl.com (Postfix) with ESMTP id 38B523A67B2 for ; Fri, 8 Apr 2011 07:30:53 -0700 (PDT) X-ASG-Debug-ID: 1302273157-011a9f581126180001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id 4bkXowb9VLX10fIN; Fri, 08 Apr 2011 07:32:37 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=ctho-lt61.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q8Cji-0004Ji-33; Fri, 08 Apr 2011 07:32:37 -0700 Mime-Version: 1.0 (Apple Message framework v1084) X-ASG-Orig-Subj: Re: [Ecrit] Comment on latest changes to phone bcp - dial strings Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Fri, 8 Apr 2011 10:32:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <098DD62E-BB38-4C7C-88F1-5CFF512AB573@brianrosen.net> References: <3F2BF77F-027C-404D-9150-65D0396862C3@brianrosen.net> To: "Elwell, John" X-Mailer: Apple Mail (2.1084) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1302273157 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.60264 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Comment on latest changes to phone bcp - dial strings X-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 Apr 2011 14:30:54 -0000 phonebcp can't really deal in any sensible way with type 3, because = there isn't any way to write "do the right thing" in the text, and the = range of what "the right thing" could be is large. What it deals with is type 2 (and of course, type 1). It says that devices don't have to handle dial string interpretation, = but if they don't, they must code dial strings as 4967 says in order = that all proxies can recognize emergency calls and do correct = processing. =20 If we don't mandate specific behavior for conforming devices, we condemn = any device that doesn't do full emergency processing to be subject to = "do the right thing" at the proxy. We've tried to avoid saying things in the text that basically amounts = to: proxies and their associated registrars must refuse service to = devices that don't allow the proxy to meet it's obligations to do the = right thing for emergency calls. Of course there is no way to write = such requirements, and mostly, there is no way to even discover what the = registrar would need to know to make a decision. Brian On Apr 8, 2011, at 10:04 AM, Elwell, John wrote: > Brian, >=20 > The problem with the text in the draft at present is it modifies = behaviour for non-emergency calls, and I don't think that is acceptable. >=20 > I can imagine 3 types of devices: > 1) Devices that comply with phonebcp, recognise an emergency dial = string and convert to a service URN. > 2) Devices that comply with phonebcp but do not recognise certain = emergency dial strings. > 3) Devices that do not comply with phonebcp. >=20 > To support type 3 devices, there will have to be some form of = agreement between the device and the proxy as to how dial strings are = delivered to the proxy. This applies to any dial string, whether it is = for an emergency call or something else. This is common practice today, = and generally does not involve RFC 4967 Tel URIs. Many working = implementations pre-date RFC 4967. To support type 3 devices making = emergency calls, proxies will presumably need to recognise emergency = dial strings when delivered by whatever means dial strings are delivered = by those devices.=20 >=20 > So I don't see the sense of upgrading those proxies to also support = RFC 4967 dial stings from type 2 devices. It would be better for proxies = to treat type 2 and type 3 devices the same. >=20 > John >=20 >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net]=20 >> Sent: 08 April 2011 14:29 >> To: Elwell, John >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Comment on latest changes to phone bcp -=20 >> dial strings >>=20 >> The BCP can't cover devices that don't conform to it, so the=20 >> fact that some existing devices don't do what it says isn't=20 >> relevant. This doesn't update 3261. It says if you do=20 >> emergency calls, do it this way. The same applies to=20 >> downstream proxies. Standardizing behavior makes sure that=20 >> regardless of the device and the proxy, the call will be=20 >> recognize as an emergency call and the right processing done for it. >>=20 >> Emergency calls have some special processing. I'd love to=20 >> mandate that all devices conforming to it recognize dial=20 >> strings, and process them into the urn. There was objection=20 >> to going that far, and thus we have this alternate path. =20 >> Your text won't work as is: it would have to be followed by a=20 >> new requirement on proxies to recognize anything the device=20 >> could put out. >>=20 >> Brian >> On Apr 8, 2011, at 3:50 AM, Elwell, John wrote: >>=20 >>> In 9.2: >>> "ED-63 The initial SIP signaling method is an INVITE request: >>> 1. The Request URI SHOULD be the service URN in the=20 >> "sos" tree. If >>> the device does not interpret local dial strings,=20 >> the Request- >>> URI MUST be a dial string URI [RFC4967] with the=20 >> dialed digits." >>> I have a concern about the "MUST" in the last sentence=20 >> (previously it was SHOULD). If the device does not interpret=20 >> local dial strings, it will not recognise an emergency call,=20 >> and therefore cannot be expected to comply with the=20 >> requirements of this BCP. >>>=20 >>> I am not aware of any RFC that updates RFC 3261 to mandate=20 >> the use of RFC 4967 when sending a dial string, so therefore=20 >> this statement in phone BCP is effectively changing the=20 >> behaviour of RFC 3261 for all calls (not just emergency=20 >> calls), which I believe should be outside the scope of the BCP. >>>=20 >>> Different practices exist today for submitting dial=20 >> strings, and acceptable forms will depend on the local proxy.=20 >> For example, often a URI in the form "SIP:12345@example.com"=20 >> is used in practice, and therefore for an emergency call it=20 >> would be, for example, "SIP:112@example.com". >>>=20 >>> An example of acceptable text would be: >>> "If the device does not interpret local dial strings and=20 >> therefore is unable to recognise a request for an emergency=20 >> call, it will behave as for any other call request for which=20 >> the dial string cannot be interpreted. Normally this will=20 >> involve submitting the dial string in the INVITE request in a=20 >> form acceptable to the local proxy (e.g., in the form of a=20 >> dial string URI [RFC4967])." >>>=20 >>> John >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 From john.elwell@siemens-enterprise.com Fri Apr 8 07:48:51 2011 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 D42333A6835 for ; Fri, 8 Apr 2011 07:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.553 X-Spam-Level: X-Spam-Status: No, score=-104.553 tagged_above=-999 required=5 tests=[AWL=2.046, 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 p7nc-f9wIXW4 for ; Fri, 8 Apr 2011 07:48:50 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by core3.amsl.com (Postfix) with SMTP id A638E3A6999 for ; Fri, 8 Apr 2011 07:48:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1302274231!15060524!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 5275 invoked from network); 8 Apr 2011 14:50:31 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-5.tower-174.messagelabs.com with SMTP; 8 Apr 2011 14:50:31 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id AD21923F0316; Fri, 8 Apr 2011 16:50:31 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 8 Apr 2011 16:50:31 +0200 From: "Elwell, John" To: Brian Rosen Date: Fri, 8 Apr 2011 16:50:30 +0200 Thread-Topic: [Ecrit] Comment on latest changes to phone bcp - dial strings Thread-Index: Acv1+dJL/DRDLV4HTKyPHZ7KaZHcQAAAajqg Message-ID: References: <3F2BF77F-027C-404D-9150-65D0396862C3@brianrosen.net> <098DD62E-BB38-4C7C-88F1-5CFF512AB573@brianrosen.net> In-Reply-To: <098DD62E-BB38-4C7C-88F1-5CFF512AB573@brianrosen.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 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Comment on latest changes to phone bcp - dial strings X-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 Apr 2011 14:48:51 -0000 Brian, I am concerned about a device that works today by embedding a dial string i= n a SIP or TEL URI in some way, but not in accordance with RFC 4967. I woul= d wager that devices supporting RFC 4967 are in a minority. Many such devices work today with dial strings for non-emergency calls, and= in most cases for emergency calls too (not using NG911). So I could dial = 112 from many devices attached to networks in Europe and somehow an emergen= cy call would be made. If I upgrade one of those devices to start encoding = dial strings using RFC 4967, would they still work? Would they still be abl= e to make non-emergency calls? Would they still be able to make emergency c= alls? My concern is that by mandating this we would break what works today. John > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: 08 April 2011 15:32 > To: Elwell, John > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Comment on latest changes to phone bcp -=20 > dial strings >=20 > phonebcp can't really deal in any sensible way with type 3,=20 > because there isn't any way to write "do the right thing" in=20 > the text, and the range of what "the right thing" could be is large. >=20 > What it deals with is type 2 (and of course, type 1). >=20 > It says that devices don't have to handle dial string=20 > interpretation, but if they don't, they must code dial=20 > strings as 4967 says in order that all proxies can recognize=20 > emergency calls and do correct processing. =20 >=20 > If we don't mandate specific behavior for conforming devices,=20 > we condemn any device that doesn't do full emergency=20 > processing to be subject to "do the right thing" at the proxy. >=20 > We've tried to avoid saying things in the text that basically=20 > amounts to: proxies and their associated registrars must=20 > refuse service to devices that don't allow the proxy to meet=20 > it's obligations to do the right thing for emergency calls. =20 > Of course there is no way to write such requirements, and=20 > mostly, there is no way to even discover what the registrar=20 > would need to know to make a decision. >=20 > Brian >=20 > On Apr 8, 2011, at 10:04 AM, Elwell, John wrote: >=20 > > Brian, > >=20 > > The problem with the text in the draft at present is it=20 > modifies behaviour for non-emergency calls, and I don't think=20 > that is acceptable. > >=20 > > I can imagine 3 types of devices: > > 1) Devices that comply with phonebcp, recognise an=20 > emergency dial string and convert to a service URN. > > 2) Devices that comply with phonebcp but do not recognise=20 > certain emergency dial strings. > > 3) Devices that do not comply with phonebcp. > >=20 > > To support type 3 devices, there will have to be some form=20 > of agreement between the device and the proxy as to how dial=20 > strings are delivered to the proxy. This applies to any dial=20 > string, whether it is for an emergency call or something=20 > else. This is common practice today, and generally does not=20 > involve RFC 4967 Tel URIs. Many working implementations=20 > pre-date RFC 4967. To support type 3 devices making emergency=20 > calls, proxies will presumably need to recognise emergency=20 > dial strings when delivered by whatever means dial strings=20 > are delivered by those devices.=20 > >=20 > > So I don't see the sense of upgrading those proxies to also=20 > support RFC 4967 dial stings from type 2 devices. It would be=20 > better for proxies to treat type 2 and type 3 devices the same. > >=20 > > John > >=20 > >> -----Original Message----- > >> From: Brian Rosen [mailto:br@brianrosen.net]=20 > >> Sent: 08 April 2011 14:29 > >> To: Elwell, John > >> Cc: ecrit@ietf.org > >> Subject: Re: [Ecrit] Comment on latest changes to phone bcp -=20 > >> dial strings > >>=20 > >> The BCP can't cover devices that don't conform to it, so the=20 > >> fact that some existing devices don't do what it says isn't=20 > >> relevant. This doesn't update 3261. It says if you do=20 > >> emergency calls, do it this way. The same applies to=20 > >> downstream proxies. Standardizing behavior makes sure that=20 > >> regardless of the device and the proxy, the call will be=20 > >> recognize as an emergency call and the right processing=20 > done for it. > >>=20 > >> Emergency calls have some special processing. I'd love to=20 > >> mandate that all devices conforming to it recognize dial=20 > >> strings, and process them into the urn. There was objection=20 > >> to going that far, and thus we have this alternate path. =20 > >> Your text won't work as is: it would have to be followed by a=20 > >> new requirement on proxies to recognize anything the device=20 > >> could put out. > >>=20 > >> Brian > >> On Apr 8, 2011, at 3:50 AM, Elwell, John wrote: > >>=20 > >>> In 9.2: > >>> "ED-63 The initial SIP signaling method is an INVITE request: > >>> 1. The Request URI SHOULD be the service URN in the=20 > >> "sos" tree. If > >>> the device does not interpret local dial strings,=20 > >> the Request- > >>> URI MUST be a dial string URI [RFC4967] with the=20 > >> dialed digits." > >>> I have a concern about the "MUST" in the last sentence=20 > >> (previously it was SHOULD). If the device does not interpret=20 > >> local dial strings, it will not recognise an emergency call,=20 > >> and therefore cannot be expected to comply with the=20 > >> requirements of this BCP. > >>>=20 > >>> I am not aware of any RFC that updates RFC 3261 to mandate=20 > >> the use of RFC 4967 when sending a dial string, so therefore=20 > >> this statement in phone BCP is effectively changing the=20 > >> behaviour of RFC 3261 for all calls (not just emergency=20 > >> calls), which I believe should be outside the scope of the BCP. > >>>=20 > >>> Different practices exist today for submitting dial=20 > >> strings, and acceptable forms will depend on the local proxy.=20 > >> For example, often a URI in the form "SIP:12345@example.com"=20 > >> is used in practice, and therefore for an emergency call it=20 > >> would be, for example, "SIP:112@example.com". > >>>=20 > >>> An example of acceptable text would be: > >>> "If the device does not interpret local dial strings and=20 > >> therefore is unable to recognise a request for an emergency=20 > >> call, it will behave as for any other call request for which=20 > >> the dial string cannot be interpreted. Normally this will=20 > >> involve submitting the dial string in the INVITE request in a=20 > >> form acceptable to the local proxy (e.g., in the form of a=20 > >> dial string URI [RFC4967])." > >>>=20 > >>> John > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >>=20 > >>=20 >=20 > = From br@brianrosen.net Fri Apr 8 07:59:22 2011 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 651373A6876 for ; Fri, 8 Apr 2011 07:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 MSXHZYid+u14 for ; Fri, 8 Apr 2011 07:59:21 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by core3.amsl.com (Postfix) with ESMTP id 27F523A67CF for ; Fri, 8 Apr 2011 07:59:21 -0700 (PDT) X-ASG-Debug-ID: 1302274863-011a9f5812283f0001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id 2k7CgpkDAp5gAnk4; Fri, 08 Apr 2011 08:01:03 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=ctho-lt61.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q8DBA-0004VE-4h; Fri, 08 Apr 2011 08:01:03 -0700 Mime-Version: 1.0 (Apple Message framework v1084) X-ASG-Orig-Subj: Re: [Ecrit] Comment on latest changes to phone bcp - dial strings Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Fri, 8 Apr 2011 11:00:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <17CFBFC6-2A76-4194-8689-B3A6119E3BBF@brianrosen.net> References: <3F2BF77F-027C-404D-9150-65D0396862C3@brianrosen.net> <098DD62E-BB38-4C7C-88F1-5CFF512AB573@brianrosen.net> To: "Elwell, John" X-Mailer: Apple Mail (2.1084) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1302274863 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.60266 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Comment on latest changes to phone bcp - dial strings X-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 Apr 2011 14:59:22 -0000 How do you propose to fix the problem with not having a standardized = behavior for coding dial strings that is going to be interoperable? An existing proxy that doesn't handle 4967 wouldn't support phonebcp = today. If it was upgraded, it would be upgraded to support 4967. I'd = expect it would also handle other ways, for backwards compatibility if = nothing else. If the upgraded proxy can handle emergency calls from = existing devices, great, but I don't see how to mandate that. If the device was upgraded, it should support 4967. Brian On Apr 8, 2011, at 10:50 AM, Elwell, John wrote: > Brian, >=20 > I am concerned about a device that works today by embedding a dial = string in a SIP or TEL URI in some way, but not in accordance with RFC = 4967. I would wager that devices supporting RFC 4967 are in a minority. >=20 > Many such devices work today with dial strings for non-emergency = calls, and in most cases for emergency calls too (not using NG911). So = I could dial 112 from many devices attached to networks in Europe and = somehow an emergency call would be made. If I upgrade one of those = devices to start encoding dial strings using RFC 4967, would they still = work? Would they still be able to make non-emergency calls? Would they = still be able to make emergency calls? My concern is that by mandating = this we would break what works today. >=20 > John >=20 >=20 >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net]=20 >> Sent: 08 April 2011 15:32 >> To: Elwell, John >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Comment on latest changes to phone bcp -=20 >> dial strings >>=20 >> phonebcp can't really deal in any sensible way with type 3,=20 >> because there isn't any way to write "do the right thing" in=20 >> the text, and the range of what "the right thing" could be is large. >>=20 >> What it deals with is type 2 (and of course, type 1). >>=20 >> It says that devices don't have to handle dial string=20 >> interpretation, but if they don't, they must code dial=20 >> strings as 4967 says in order that all proxies can recognize=20 >> emergency calls and do correct processing. =20 >>=20 >> If we don't mandate specific behavior for conforming devices,=20 >> we condemn any device that doesn't do full emergency=20 >> processing to be subject to "do the right thing" at the proxy. >>=20 >> We've tried to avoid saying things in the text that basically=20 >> amounts to: proxies and their associated registrars must=20 >> refuse service to devices that don't allow the proxy to meet=20 >> it's obligations to do the right thing for emergency calls. =20 >> Of course there is no way to write such requirements, and=20 >> mostly, there is no way to even discover what the registrar=20 >> would need to know to make a decision. >>=20 >> Brian >>=20 >> On Apr 8, 2011, at 10:04 AM, Elwell, John wrote: >>=20 >>> Brian, >>>=20 >>> The problem with the text in the draft at present is it=20 >> modifies behaviour for non-emergency calls, and I don't think=20 >> that is acceptable. >>>=20 >>> I can imagine 3 types of devices: >>> 1) Devices that comply with phonebcp, recognise an=20 >> emergency dial string and convert to a service URN. >>> 2) Devices that comply with phonebcp but do not recognise=20 >> certain emergency dial strings. >>> 3) Devices that do not comply with phonebcp. >>>=20 >>> To support type 3 devices, there will have to be some form=20 >> of agreement between the device and the proxy as to how dial=20 >> strings are delivered to the proxy. This applies to any dial=20 >> string, whether it is for an emergency call or something=20 >> else. This is common practice today, and generally does not=20 >> involve RFC 4967 Tel URIs. Many working implementations=20 >> pre-date RFC 4967. To support type 3 devices making emergency=20 >> calls, proxies will presumably need to recognise emergency=20 >> dial strings when delivered by whatever means dial strings=20 >> are delivered by those devices.=20 >>>=20 >>> So I don't see the sense of upgrading those proxies to also=20 >> support RFC 4967 dial stings from type 2 devices. It would be=20 >> better for proxies to treat type 2 and type 3 devices the same. >>>=20 >>> John >>>=20 >>>> -----Original Message----- >>>> From: Brian Rosen [mailto:br@brianrosen.net]=20 >>>> Sent: 08 April 2011 14:29 >>>> To: Elwell, John >>>> Cc: ecrit@ietf.org >>>> Subject: Re: [Ecrit] Comment on latest changes to phone bcp -=20 >>>> dial strings >>>>=20 >>>> The BCP can't cover devices that don't conform to it, so the=20 >>>> fact that some existing devices don't do what it says isn't=20 >>>> relevant. This doesn't update 3261. It says if you do=20 >>>> emergency calls, do it this way. The same applies to=20 >>>> downstream proxies. Standardizing behavior makes sure that=20 >>>> regardless of the device and the proxy, the call will be=20 >>>> recognize as an emergency call and the right processing=20 >> done for it. >>>>=20 >>>> Emergency calls have some special processing. I'd love to=20 >>>> mandate that all devices conforming to it recognize dial=20 >>>> strings, and process them into the urn. There was objection=20 >>>> to going that far, and thus we have this alternate path. =20 >>>> Your text won't work as is: it would have to be followed by a=20 >>>> new requirement on proxies to recognize anything the device=20 >>>> could put out. >>>>=20 >>>> Brian >>>> On Apr 8, 2011, at 3:50 AM, Elwell, John wrote: >>>>=20 >>>>> In 9.2: >>>>> "ED-63 The initial SIP signaling method is an INVITE request: >>>>> 1. The Request URI SHOULD be the service URN in the=20 >>>> "sos" tree. If >>>>> the device does not interpret local dial strings,=20 >>>> the Request- >>>>> URI MUST be a dial string URI [RFC4967] with the=20 >>>> dialed digits." >>>>> I have a concern about the "MUST" in the last sentence=20 >>>> (previously it was SHOULD). If the device does not interpret=20 >>>> local dial strings, it will not recognise an emergency call,=20 >>>> and therefore cannot be expected to comply with the=20 >>>> requirements of this BCP. >>>>>=20 >>>>> I am not aware of any RFC that updates RFC 3261 to mandate=20 >>>> the use of RFC 4967 when sending a dial string, so therefore=20 >>>> this statement in phone BCP is effectively changing the=20 >>>> behaviour of RFC 3261 for all calls (not just emergency=20 >>>> calls), which I believe should be outside the scope of the BCP. >>>>>=20 >>>>> Different practices exist today for submitting dial=20 >>>> strings, and acceptable forms will depend on the local proxy.=20 >>>> For example, often a URI in the form "SIP:12345@example.com"=20 >>>> is used in practice, and therefore for an emergency call it=20 >>>> would be, for example, "SIP:112@example.com". >>>>>=20 >>>>> An example of acceptable text would be: >>>>> "If the device does not interpret local dial strings and=20 >>>> therefore is unable to recognise a request for an emergency=20 >>>> call, it will behave as for any other call request for which=20 >>>> the dial string cannot be interpreted. Normally this will=20 >>>> involve submitting the dial string in the INVITE request in a=20 >>>> form acceptable to the local proxy (e.g., in the form of a=20 >>>> dial string URI [RFC4967])." >>>>>=20 >>>>> John >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>>=20 >>=20 >>=20 From rbarnes@bbn.com Fri Apr 8 08:08:01 2011 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 099E23A6943 for ; Fri, 8 Apr 2011 08:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 wjKNCL3IThZM for ; Fri, 8 Apr 2011 08:07:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id A01A23A6819 for ; Fri, 8 Apr 2011 08:07:59 -0700 (PDT) Received: from [192.1.255.182] (port=61930 helo=col-dhcp-192-1-255-182.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q8DJe-000F7L-EQ; Fri, 08 Apr 2011 11:09:42 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <17CFBFC6-2A76-4194-8689-B3A6119E3BBF@brianrosen.net> Date: Fri, 8 Apr 2011 11:09:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0B800564-4009-49F9-97E9-A6B7829A6200@bbn.com> References: <3F2BF77F-027C-404D-9150-65D0396862C3@brianrosen.net> <098DD62E-BB38-4C7C-88F1-5CFF512AB573@brianrosen.net> <17CFBFC6-2A76-4194-8689-B3A6119E3BBF@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1082) Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Comment on latest changes to phone bcp - dial strings X-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 Apr 2011 15:08:01 -0000 I think the point is that since we're talking about the *difference* = between a normal phone and an ECRIT-enabled phone, we don't need to = solve the dial-string interop problem. If you assume the phone can already dial numbers, then the phone and the = proxy already have some convention that they've agreed upon for sending = dialed digits. Maybe its tel:12345, maybe it's 12345@example.com, maybe = it's 4967. If it's not upgraded to give some special treatment to = specific dial strings, A non-upgraded phone is going to send dialed = digits in whatever convention it's configured with, and it's the proxy's = job to do the recognition and routing. =20 So it seems like what the document should be saying is: -- If an endpoint supports emergency dialstring recognition, then it = MUST replace things with service URN as described in this document -- Otherwise, it sends the dialed digits like any other dialed digits. ... which I think is what John was suggesting. --Richard On Apr 8, 2011, at 11:00 AM, Brian Rosen wrote: > How do you propose to fix the problem with not having a standardized = behavior for coding dial strings that is going to be interoperable? >=20 > An existing proxy that doesn't handle 4967 wouldn't support phonebcp = today. If it was upgraded, it would be upgraded to support 4967. I'd = expect it would also handle other ways, for backwards compatibility if = nothing else. If the upgraded proxy can handle emergency calls from = existing devices, great, but I don't see how to mandate that. >=20 > If the device was upgraded, it should support 4967. >=20 > Brian >=20 > On Apr 8, 2011, at 10:50 AM, Elwell, John wrote: >=20 >> Brian, >>=20 >> I am concerned about a device that works today by embedding a dial = string in a SIP or TEL URI in some way, but not in accordance with RFC = 4967. I would wager that devices supporting RFC 4967 are in a minority. >>=20 >> Many such devices work today with dial strings for non-emergency = calls, and in most cases for emergency calls too (not using NG911). So = I could dial 112 from many devices attached to networks in Europe and = somehow an emergency call would be made. If I upgrade one of those = devices to start encoding dial strings using RFC 4967, would they still = work? Would they still be able to make non-emergency calls? Would they = still be able to make emergency calls? My concern is that by mandating = this we would break what works today. >>=20 >> John >>=20 >>=20 >>> -----Original Message----- >>> From: Brian Rosen [mailto:br@brianrosen.net]=20 >>> Sent: 08 April 2011 15:32 >>> To: Elwell, John >>> Cc: ecrit@ietf.org >>> Subject: Re: [Ecrit] Comment on latest changes to phone bcp -=20 >>> dial strings >>>=20 >>> phonebcp can't really deal in any sensible way with type 3,=20 >>> because there isn't any way to write "do the right thing" in=20 >>> the text, and the range of what "the right thing" could be is large. >>>=20 >>> What it deals with is type 2 (and of course, type 1). >>>=20 >>> It says that devices don't have to handle dial string=20 >>> interpretation, but if they don't, they must code dial=20 >>> strings as 4967 says in order that all proxies can recognize=20 >>> emergency calls and do correct processing. =20 >>>=20 >>> If we don't mandate specific behavior for conforming devices,=20 >>> we condemn any device that doesn't do full emergency=20 >>> processing to be subject to "do the right thing" at the proxy. >>>=20 >>> We've tried to avoid saying things in the text that basically=20 >>> amounts to: proxies and their associated registrars must=20 >>> refuse service to devices that don't allow the proxy to meet=20 >>> it's obligations to do the right thing for emergency calls. =20 >>> Of course there is no way to write such requirements, and=20 >>> mostly, there is no way to even discover what the registrar=20 >>> would need to know to make a decision. >>>=20 >>> Brian >>>=20 >>> On Apr 8, 2011, at 10:04 AM, Elwell, John wrote: >>>=20 >>>> Brian, >>>>=20 >>>> The problem with the text in the draft at present is it=20 >>> modifies behaviour for non-emergency calls, and I don't think=20 >>> that is acceptable. >>>>=20 >>>> I can imagine 3 types of devices: >>>> 1) Devices that comply with phonebcp, recognise an=20 >>> emergency dial string and convert to a service URN. >>>> 2) Devices that comply with phonebcp but do not recognise=20 >>> certain emergency dial strings. >>>> 3) Devices that do not comply with phonebcp. >>>>=20 >>>> To support type 3 devices, there will have to be some form=20 >>> of agreement between the device and the proxy as to how dial=20 >>> strings are delivered to the proxy. This applies to any dial=20 >>> string, whether it is for an emergency call or something=20 >>> else. This is common practice today, and generally does not=20 >>> involve RFC 4967 Tel URIs. Many working implementations=20 >>> pre-date RFC 4967. To support type 3 devices making emergency=20 >>> calls, proxies will presumably need to recognise emergency=20 >>> dial strings when delivered by whatever means dial strings=20 >>> are delivered by those devices.=20 >>>>=20 >>>> So I don't see the sense of upgrading those proxies to also=20 >>> support RFC 4967 dial stings from type 2 devices. It would be=20 >>> better for proxies to treat type 2 and type 3 devices the same. >>>>=20 >>>> John >>>>=20 >>>>> -----Original Message----- >>>>> From: Brian Rosen [mailto:br@brianrosen.net]=20 >>>>> Sent: 08 April 2011 14:29 >>>>> To: Elwell, John >>>>> Cc: ecrit@ietf.org >>>>> Subject: Re: [Ecrit] Comment on latest changes to phone bcp -=20 >>>>> dial strings >>>>>=20 >>>>> The BCP can't cover devices that don't conform to it, so the=20 >>>>> fact that some existing devices don't do what it says isn't=20 >>>>> relevant. This doesn't update 3261. It says if you do=20 >>>>> emergency calls, do it this way. The same applies to=20 >>>>> downstream proxies. Standardizing behavior makes sure that=20 >>>>> regardless of the device and the proxy, the call will be=20 >>>>> recognize as an emergency call and the right processing=20 >>> done for it. >>>>>=20 >>>>> Emergency calls have some special processing. I'd love to=20 >>>>> mandate that all devices conforming to it recognize dial=20 >>>>> strings, and process them into the urn. There was objection=20 >>>>> to going that far, and thus we have this alternate path. =20 >>>>> Your text won't work as is: it would have to be followed by a=20 >>>>> new requirement on proxies to recognize anything the device=20 >>>>> could put out. >>>>>=20 >>>>> Brian >>>>> On Apr 8, 2011, at 3:50 AM, Elwell, John wrote: >>>>>=20 >>>>>> In 9.2: >>>>>> "ED-63 The initial SIP signaling method is an INVITE request: >>>>>> 1. The Request URI SHOULD be the service URN in the=20 >>>>> "sos" tree. If >>>>>> the device does not interpret local dial strings,=20 >>>>> the Request- >>>>>> URI MUST be a dial string URI [RFC4967] with the=20 >>>>> dialed digits." >>>>>> I have a concern about the "MUST" in the last sentence=20 >>>>> (previously it was SHOULD). If the device does not interpret=20 >>>>> local dial strings, it will not recognise an emergency call,=20 >>>>> and therefore cannot be expected to comply with the=20 >>>>> requirements of this BCP. >>>>>>=20 >>>>>> I am not aware of any RFC that updates RFC 3261 to mandate=20 >>>>> the use of RFC 4967 when sending a dial string, so therefore=20 >>>>> this statement in phone BCP is effectively changing the=20 >>>>> behaviour of RFC 3261 for all calls (not just emergency=20 >>>>> calls), which I believe should be outside the scope of the BCP. >>>>>>=20 >>>>>> Different practices exist today for submitting dial=20 >>>>> strings, and acceptable forms will depend on the local proxy.=20 >>>>> For example, often a URI in the form "SIP:12345@example.com"=20 >>>>> is used in practice, and therefore for an emergency call it=20 >>>>> would be, for example, "SIP:112@example.com". >>>>>>=20 >>>>>> An example of acceptable text would be: >>>>>> "If the device does not interpret local dial strings and=20 >>>>> therefore is unable to recognise a request for an emergency=20 >>>>> call, it will behave as for any other call request for which=20 >>>>> the dial string cannot be interpreted. Normally this will=20 >>>>> involve submitting the dial string in the INVITE request in a=20 >>>>> form acceptable to the local proxy (e.g., in the form of a=20 >>>>> dial string URI [RFC4967])." >>>>>>=20 >>>>>> John >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>=20 >>>>>=20 >>>=20 >>>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From john.elwell@siemens-enterprise.com Fri Apr 8 08:15:14 2011 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 8C9DE3A696F for ; Fri, 8 Apr 2011 08:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.569 X-Spam-Level: X-Spam-Status: No, score=-104.569 tagged_above=-999 required=5 tests=[AWL=2.030, 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 jJ1frKYXhN6t for ; Fri, 8 Apr 2011 08:15:13 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by core3.amsl.com (Postfix) with SMTP id 88A9F3A681F for ; Fri, 8 Apr 2011 08:15:12 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1302275815!21824862!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 3784 invoked from network); 8 Apr 2011 15:16:55 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-13.tower-27.messagelabs.com with SMTP; 8 Apr 2011 15:16:55 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id CEAE61EB8327; Fri, 8 Apr 2011 17:16:56 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 8 Apr 2011 17:16:56 +0200 From: "Elwell, John" To: "Richard L. Barnes" , Brian Rosen Date: Fri, 8 Apr 2011 17:16:55 +0200 Thread-Topic: [Ecrit] Comment on latest changes to phone bcp - dial strings Thread-Index: Acv1/v6hGdGZ85PFS8iYnF0CaGDJ+wAAJ2pw Message-ID: References: <3F2BF77F-027C-404D-9150-65D0396862C3@brianrosen.net> <098DD62E-BB38-4C7C-88F1-5CFF512AB573@brianrosen.net> <17CFBFC6-2A76-4194-8689-B3A6119E3BBF@brianrosen.net> <0B800564-4009-49F9-97E9-A6B7829A6200@bbn.com> In-Reply-To: <0B800564-4009-49F9-97E9-A6B7829A6200@bbn.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 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Comment on latest changes to phone bcp - dial strings X-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 Apr 2011 15:15:14 -0000 =20 > -----Original Message----- > From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 > Sent: 08 April 2011 16:10 > To: Brian Rosen > Cc: Elwell, John; ecrit@ietf.org > Subject: Re: [Ecrit] Comment on latest changes to phone bcp -=20 > dial strings >=20 > I think the point is that since we're talking about the=20 > *difference* between a normal phone and an ECRIT-enabled=20 > phone, we don't need to solve the dial-string interop problem. >=20 > If you assume the phone can already dial numbers, then the=20 > phone and the proxy already have some convention that they've=20 > agreed upon for sending dialed digits. Maybe its tel:12345,=20 > maybe it's 12345@example.com, maybe it's 4967. If it's not=20 > upgraded to give some special treatment to specific dial=20 > strings, A non-upgraded phone is going to send dialed digits=20 > in whatever convention it's configured with, and it's the=20 > proxy's job to do the recognition and routing. =20 >=20 > So it seems like what the document should be saying is: > -- If an endpoint supports emergency dialstring recognition,=20 > then it MUST replace things with service URN as described in=20 > this document > -- Otherwise, it sends the dialed digits like any other dialed digits. > ... which I think is what John was suggesting. [JRE] Yes, that is basically what I was suggesting. So a phonebcp-compliant= device will normally send a URN and a non-compliant device will continue t= o work as at present. This just leaves the case where a phonebcp-compliant = device fails to recognise an emergency dial string, because it wasn't confi= gured and it wasn't obtained from LoST. In that case I think it makes sense= just to let it behave as a non-compliant device. John >=20 > --Richard >=20 >=20 > On Apr 8, 2011, at 11:00 AM, Brian Rosen wrote: >=20 > > How do you propose to fix the problem with not having a=20 > standardized behavior for coding dial strings that is going=20 > to be interoperable? > >=20 > > An existing proxy that doesn't handle 4967 wouldn't support=20 > phonebcp today. If it was upgraded, it would be upgraded to=20 > support 4967. I'd expect it would also handle other ways,=20 > for backwards compatibility if nothing else. If the upgraded=20 > proxy can handle emergency calls from existing devices,=20 > great, but I don't see how to mandate that. > >=20 > > If the device was upgraded, it should support 4967. > >=20 > > Brian > >=20 > > On Apr 8, 2011, at 10:50 AM, Elwell, John wrote: > >=20 > >> Brian, > >>=20 > >> I am concerned about a device that works today by=20 > embedding a dial string in a SIP or TEL URI in some way, but=20 > not in accordance with RFC 4967. I would wager that devices=20 > supporting RFC 4967 are in a minority. > >>=20 > >> Many such devices work today with dial strings for=20 > non-emergency calls, and in most cases for emergency calls=20 > too (not using NG911). So I could dial 112 from many devices=20 > attached to networks in Europe and somehow an emergency call=20 > would be made. If I upgrade one of those devices to start=20 > encoding dial strings using RFC 4967, would they still work?=20 > Would they still be able to make non-emergency calls? Would=20 > they still be able to make emergency calls? My concern is=20 > that by mandating this we would break what works today. > >>=20 > >> John > >>=20 > >>=20 > >>> -----Original Message----- > >>> From: Brian Rosen [mailto:br@brianrosen.net]=20 > >>> Sent: 08 April 2011 15:32 > >>> To: Elwell, John > >>> Cc: ecrit@ietf.org > >>> Subject: Re: [Ecrit] Comment on latest changes to phone bcp -=20 > >>> dial strings > >>>=20 > >>> phonebcp can't really deal in any sensible way with type 3,=20 > >>> because there isn't any way to write "do the right thing" in=20 > >>> the text, and the range of what "the right thing" could=20 > be is large. > >>>=20 > >>> What it deals with is type 2 (and of course, type 1). > >>>=20 > >>> It says that devices don't have to handle dial string=20 > >>> interpretation, but if they don't, they must code dial=20 > >>> strings as 4967 says in order that all proxies can recognize=20 > >>> emergency calls and do correct processing. =20 > >>>=20 > >>> If we don't mandate specific behavior for conforming devices,=20 > >>> we condemn any device that doesn't do full emergency=20 > >>> processing to be subject to "do the right thing" at the proxy. > >>>=20 > >>> We've tried to avoid saying things in the text that basically=20 > >>> amounts to: proxies and their associated registrars must=20 > >>> refuse service to devices that don't allow the proxy to meet=20 > >>> it's obligations to do the right thing for emergency calls. =20 > >>> Of course there is no way to write such requirements, and=20 > >>> mostly, there is no way to even discover what the registrar=20 > >>> would need to know to make a decision. > >>>=20 > >>> Brian > >>>=20 > >>> On Apr 8, 2011, at 10:04 AM, Elwell, John wrote: > >>>=20 > >>>> Brian, > >>>>=20 > >>>> The problem with the text in the draft at present is it=20 > >>> modifies behaviour for non-emergency calls, and I don't think=20 > >>> that is acceptable. > >>>>=20 > >>>> I can imagine 3 types of devices: > >>>> 1) Devices that comply with phonebcp, recognise an=20 > >>> emergency dial string and convert to a service URN. > >>>> 2) Devices that comply with phonebcp but do not recognise=20 > >>> certain emergency dial strings. > >>>> 3) Devices that do not comply with phonebcp. > >>>>=20 > >>>> To support type 3 devices, there will have to be some form=20 > >>> of agreement between the device and the proxy as to how dial=20 > >>> strings are delivered to the proxy. This applies to any dial=20 > >>> string, whether it is for an emergency call or something=20 > >>> else. This is common practice today, and generally does not=20 > >>> involve RFC 4967 Tel URIs. Many working implementations=20 > >>> pre-date RFC 4967. To support type 3 devices making emergency=20 > >>> calls, proxies will presumably need to recognise emergency=20 > >>> dial strings when delivered by whatever means dial strings=20 > >>> are delivered by those devices.=20 > >>>>=20 > >>>> So I don't see the sense of upgrading those proxies to also=20 > >>> support RFC 4967 dial stings from type 2 devices. It would be=20 > >>> better for proxies to treat type 2 and type 3 devices the same. > >>>>=20 > >>>> John > >>>>=20 > >>>>> -----Original Message----- > >>>>> From: Brian Rosen [mailto:br@brianrosen.net]=20 > >>>>> Sent: 08 April 2011 14:29 > >>>>> To: Elwell, John > >>>>> Cc: ecrit@ietf.org > >>>>> Subject: Re: [Ecrit] Comment on latest changes to phone bcp -=20 > >>>>> dial strings > >>>>>=20 > >>>>> The BCP can't cover devices that don't conform to it, so the=20 > >>>>> fact that some existing devices don't do what it says isn't=20 > >>>>> relevant. This doesn't update 3261. It says if you do=20 > >>>>> emergency calls, do it this way. The same applies to=20 > >>>>> downstream proxies. Standardizing behavior makes sure that=20 > >>>>> regardless of the device and the proxy, the call will be=20 > >>>>> recognize as an emergency call and the right processing=20 > >>> done for it. > >>>>>=20 > >>>>> Emergency calls have some special processing. I'd love to=20 > >>>>> mandate that all devices conforming to it recognize dial=20 > >>>>> strings, and process them into the urn. There was objection=20 > >>>>> to going that far, and thus we have this alternate path. =20 > >>>>> Your text won't work as is: it would have to be followed by a=20 > >>>>> new requirement on proxies to recognize anything the device=20 > >>>>> could put out. > >>>>>=20 > >>>>> Brian > >>>>> On Apr 8, 2011, at 3:50 AM, Elwell, John wrote: > >>>>>=20 > >>>>>> In 9.2: > >>>>>> "ED-63 The initial SIP signaling method is an INVITE request: > >>>>>> 1. The Request URI SHOULD be the service URN in the=20 > >>>>> "sos" tree. If > >>>>>> the device does not interpret local dial strings,=20 > >>>>> the Request- > >>>>>> URI MUST be a dial string URI [RFC4967] with the=20 > >>>>> dialed digits." > >>>>>> I have a concern about the "MUST" in the last sentence=20 > >>>>> (previously it was SHOULD). If the device does not interpret=20 > >>>>> local dial strings, it will not recognise an emergency call,=20 > >>>>> and therefore cannot be expected to comply with the=20 > >>>>> requirements of this BCP. > >>>>>>=20 > >>>>>> I am not aware of any RFC that updates RFC 3261 to mandate=20 > >>>>> the use of RFC 4967 when sending a dial string, so therefore=20 > >>>>> this statement in phone BCP is effectively changing the=20 > >>>>> behaviour of RFC 3261 for all calls (not just emergency=20 > >>>>> calls), which I believe should be outside the scope of the BCP. > >>>>>>=20 > >>>>>> Different practices exist today for submitting dial=20 > >>>>> strings, and acceptable forms will depend on the local proxy.=20 > >>>>> For example, often a URI in the form "SIP:12345@example.com"=20 > >>>>> is used in practice, and therefore for an emergency call it=20 > >>>>> would be, for example, "SIP:112@example.com". > >>>>>>=20 > >>>>>> An example of acceptable text would be: > >>>>>> "If the device does not interpret local dial strings and=20 > >>>>> therefore is unable to recognise a request for an emergency=20 > >>>>> call, it will behave as for any other call request for which=20 > >>>>> the dial string cannot be interpreted. Normally this will=20 > >>>>> involve submitting the dial string in the INVITE request in a=20 > >>>>> form acceptable to the local proxy (e.g., in the form of a=20 > >>>>> dial string URI [RFC4967])." > >>>>>>=20 > >>>>>> John > >>>>>> _______________________________________________ > >>>>>> Ecrit mailing list > >>>>>> Ecrit@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>>=20 > >>>>>=20 > >>>=20 > >>>=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > = From rbarnes@bbn.com Fri Apr 8 08:24:25 2011 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 791043A6934 for ; Fri, 8 Apr 2011 08:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 YE5IPv-BTo5g for ; Fri, 8 Apr 2011 08:24:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 540463A6819 for ; Fri, 8 Apr 2011 08:24:23 -0700 (PDT) Received: from [192.1.255.182] (port=61948 helo=col-dhcp-192-1-255-182.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q8DZW-000FOv-Mm; Fri, 08 Apr 2011 11:26:07 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Fri, 8 Apr 2011 11:26:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3F2BF77F-027C-404D-9150-65D0396862C3@brianrosen.net> <098DD62E-BB38-4C7C-88F1-5CFF512AB573@brianrosen.net> <17CFBFC6-2A76-4194-8689-B3A6119E3BBF@brianrosen.net> <0B800564-4009-49F9-97E9-A6B7829A6200@bbn.com> To: "Elwell, John" X-Mailer: Apple Mail (2.1082) Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Comment on latest changes to phone bcp - dial strings X-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 Apr 2011 15:24:25 -0000 >> So it seems like what the document should be saying is: >> -- If an endpoint supports emergency dialstring recognition,=20 >> then it MUST replace things with service URN as described in=20 >> this document >> -- Otherwise, it sends the dialed digits like any other dialed = digits. >> ... which I think is what John was suggesting. > [JRE] Yes, that is basically what I was suggesting. So a = phonebcp-compliant device will normally send a URN and a non-compliant = device will continue to work as at present. This just leaves the case = where a phonebcp-compliant device fails to recognise an emergency dial = string, because it wasn't configured and it wasn't obtained from LoST. = In that case I think it makes sense just to let it behave as a = non-compliant device. That sounds like a LoST provisioning failure to me, thus not a case that = needs to be addressed at all. --Richard > John >=20 >=20 >>=20 >> --Richard >>=20 >>=20 >> On Apr 8, 2011, at 11:00 AM, Brian Rosen wrote: >>=20 >>> How do you propose to fix the problem with not having a=20 >> standardized behavior for coding dial strings that is going=20 >> to be interoperable? >>>=20 >>> An existing proxy that doesn't handle 4967 wouldn't support=20 >> phonebcp today. If it was upgraded, it would be upgraded to=20 >> support 4967. I'd expect it would also handle other ways,=20 >> for backwards compatibility if nothing else. If the upgraded=20 >> proxy can handle emergency calls from existing devices,=20 >> great, but I don't see how to mandate that. >>>=20 >>> If the device was upgraded, it should support 4967. >>>=20 >>> Brian >>>=20 >>> On Apr 8, 2011, at 10:50 AM, Elwell, John wrote: >>>=20 >>>> Brian, >>>>=20 >>>> I am concerned about a device that works today by=20 >> embedding a dial string in a SIP or TEL URI in some way, but=20 >> not in accordance with RFC 4967. I would wager that devices=20 >> supporting RFC 4967 are in a minority. >>>>=20 >>>> Many such devices work today with dial strings for=20 >> non-emergency calls, and in most cases for emergency calls=20 >> too (not using NG911). So I could dial 112 from many devices=20 >> attached to networks in Europe and somehow an emergency call=20 >> would be made. If I upgrade one of those devices to start=20 >> encoding dial strings using RFC 4967, would they still work?=20 >> Would they still be able to make non-emergency calls? Would=20 >> they still be able to make emergency calls? My concern is=20 >> that by mandating this we would break what works today. >>>>=20 >>>> John >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Brian Rosen [mailto:br@brianrosen.net]=20 >>>>> Sent: 08 April 2011 15:32 >>>>> To: Elwell, John >>>>> Cc: ecrit@ietf.org >>>>> Subject: Re: [Ecrit] Comment on latest changes to phone bcp -=20 >>>>> dial strings >>>>>=20 >>>>> phonebcp can't really deal in any sensible way with type 3,=20 >>>>> because there isn't any way to write "do the right thing" in=20 >>>>> the text, and the range of what "the right thing" could=20 >> be is large. >>>>>=20 >>>>> What it deals with is type 2 (and of course, type 1). >>>>>=20 >>>>> It says that devices don't have to handle dial string=20 >>>>> interpretation, but if they don't, they must code dial=20 >>>>> strings as 4967 says in order that all proxies can recognize=20 >>>>> emergency calls and do correct processing. =20 >>>>>=20 >>>>> If we don't mandate specific behavior for conforming devices,=20 >>>>> we condemn any device that doesn't do full emergency=20 >>>>> processing to be subject to "do the right thing" at the proxy. >>>>>=20 >>>>> We've tried to avoid saying things in the text that basically=20 >>>>> amounts to: proxies and their associated registrars must=20 >>>>> refuse service to devices that don't allow the proxy to meet=20 >>>>> it's obligations to do the right thing for emergency calls. =20 >>>>> Of course there is no way to write such requirements, and=20 >>>>> mostly, there is no way to even discover what the registrar=20 >>>>> would need to know to make a decision. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Apr 8, 2011, at 10:04 AM, Elwell, John wrote: >>>>>=20 >>>>>> Brian, >>>>>>=20 >>>>>> The problem with the text in the draft at present is it=20 >>>>> modifies behaviour for non-emergency calls, and I don't think=20 >>>>> that is acceptable. >>>>>>=20 >>>>>> I can imagine 3 types of devices: >>>>>> 1) Devices that comply with phonebcp, recognise an=20 >>>>> emergency dial string and convert to a service URN. >>>>>> 2) Devices that comply with phonebcp but do not recognise=20 >>>>> certain emergency dial strings. >>>>>> 3) Devices that do not comply with phonebcp. >>>>>>=20 >>>>>> To support type 3 devices, there will have to be some form=20 >>>>> of agreement between the device and the proxy as to how dial=20 >>>>> strings are delivered to the proxy. This applies to any dial=20 >>>>> string, whether it is for an emergency call or something=20 >>>>> else. This is common practice today, and generally does not=20 >>>>> involve RFC 4967 Tel URIs. Many working implementations=20 >>>>> pre-date RFC 4967. To support type 3 devices making emergency=20 >>>>> calls, proxies will presumably need to recognise emergency=20 >>>>> dial strings when delivered by whatever means dial strings=20 >>>>> are delivered by those devices.=20 >>>>>>=20 >>>>>> So I don't see the sense of upgrading those proxies to also=20 >>>>> support RFC 4967 dial stings from type 2 devices. It would be=20 >>>>> better for proxies to treat type 2 and type 3 devices the same. >>>>>>=20 >>>>>> John >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Brian Rosen [mailto:br@brianrosen.net]=20 >>>>>>> Sent: 08 April 2011 14:29 >>>>>>> To: Elwell, John >>>>>>> Cc: ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] Comment on latest changes to phone bcp -=20 >>>>>>> dial strings >>>>>>>=20 >>>>>>> The BCP can't cover devices that don't conform to it, so the=20 >>>>>>> fact that some existing devices don't do what it says isn't=20 >>>>>>> relevant. This doesn't update 3261. It says if you do=20 >>>>>>> emergency calls, do it this way. The same applies to=20 >>>>>>> downstream proxies. Standardizing behavior makes sure that=20 >>>>>>> regardless of the device and the proxy, the call will be=20 >>>>>>> recognize as an emergency call and the right processing=20 >>>>> done for it. >>>>>>>=20 >>>>>>> Emergency calls have some special processing. I'd love to=20 >>>>>>> mandate that all devices conforming to it recognize dial=20 >>>>>>> strings, and process them into the urn. There was objection=20 >>>>>>> to going that far, and thus we have this alternate path. =20 >>>>>>> Your text won't work as is: it would have to be followed by a=20 >>>>>>> new requirement on proxies to recognize anything the device=20 >>>>>>> could put out. >>>>>>>=20 >>>>>>> Brian >>>>>>> On Apr 8, 2011, at 3:50 AM, Elwell, John wrote: >>>>>>>=20 >>>>>>>> In 9.2: >>>>>>>> "ED-63 The initial SIP signaling method is an INVITE request: >>>>>>>> 1. The Request URI SHOULD be the service URN in the=20 >>>>>>> "sos" tree. If >>>>>>>> the device does not interpret local dial strings,=20 >>>>>>> the Request- >>>>>>>> URI MUST be a dial string URI [RFC4967] with the=20 >>>>>>> dialed digits." >>>>>>>> I have a concern about the "MUST" in the last sentence=20 >>>>>>> (previously it was SHOULD). If the device does not interpret=20 >>>>>>> local dial strings, it will not recognise an emergency call,=20 >>>>>>> and therefore cannot be expected to comply with the=20 >>>>>>> requirements of this BCP. >>>>>>>>=20 >>>>>>>> I am not aware of any RFC that updates RFC 3261 to mandate=20 >>>>>>> the use of RFC 4967 when sending a dial string, so therefore=20 >>>>>>> this statement in phone BCP is effectively changing the=20 >>>>>>> behaviour of RFC 3261 for all calls (not just emergency=20 >>>>>>> calls), which I believe should be outside the scope of the BCP. >>>>>>>>=20 >>>>>>>> Different practices exist today for submitting dial=20 >>>>>>> strings, and acceptable forms will depend on the local proxy.=20 >>>>>>> For example, often a URI in the form "SIP:12345@example.com"=20 >>>>>>> is used in practice, and therefore for an emergency call it=20 >>>>>>> would be, for example, "SIP:112@example.com". >>>>>>>>=20 >>>>>>>> An example of acceptable text would be: >>>>>>>> "If the device does not interpret local dial strings and=20 >>>>>>> therefore is unable to recognise a request for an emergency=20 >>>>>>> call, it will behave as for any other call request for which=20 >>>>>>> the dial string cannot be interpreted. Normally this will=20 >>>>>>> involve submitting the dial string in the INVITE request in a=20 >>>>>>> form acceptable to the local proxy (e.g., in the form of a=20 >>>>>>> dial string URI [RFC4967])." >>>>>>>>=20 >>>>>>>> John >>>>>>>> _______________________________________________ >>>>>>>> Ecrit mailing list >>>>>>>> Ecrit@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 From john.elwell@siemens-enterprise.com Fri Apr 8 08:28:24 2011 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 9707F3A6819 for ; Fri, 8 Apr 2011 08:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 PbJvGd0K+-KA for ; Fri, 8 Apr 2011 08:28:22 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by core3.amsl.com (Postfix) with SMTP id 180423A6974 for ; Fri, 8 Apr 2011 08:28:20 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1302276604!1745665!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 5442 invoked from network); 8 Apr 2011 15:30:04 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-3.tower-216.messagelabs.com with SMTP; 8 Apr 2011 15:30:04 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id C410F23F0330; Fri, 8 Apr 2011 17:30:04 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 8 Apr 2011 17:30:04 +0200 From: "Elwell, John" To: Brian Rosen Date: Fri, 8 Apr 2011 17:30:02 +0200 Thread-Topic: [Ecrit] Comment on latest changes to phone bcp - dial strings Thread-Index: Acv1/crtGjocO89XRP+Yd5f2LPYibwAA94oQ Message-ID: References: <3F2BF77F-027C-404D-9150-65D0396862C3@brianrosen.net> <098DD62E-BB38-4C7C-88F1-5CFF512AB573@brianrosen.net> <17CFBFC6-2A76-4194-8689-B3A6119E3BBF@brianrosen.net> In-Reply-To: <17CFBFC6-2A76-4194-8689-B3A6119E3BBF@brianrosen.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 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Comment on latest changes to phone bcp - dial strings X-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 Apr 2011 15:28:24 -0000 Referring to what Richard says and my response to that, I think the case yo= u are concerned about is a corner case that we don't need to deal with. John=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: 08 April 2011 16:01 > To: Elwell, John > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Comment on latest changes to phone bcp -=20 > dial strings >=20 > How do you propose to fix the problem with not having a=20 > standardized behavior for coding dial strings that is going=20 > to be interoperable? >=20 > An existing proxy that doesn't handle 4967 wouldn't support=20 > phonebcp today. If it was upgraded, it would be upgraded to=20 > support 4967. I'd expect it would also handle other ways,=20 > for backwards compatibility if nothing else. If the upgraded=20 > proxy can handle emergency calls from existing devices,=20 > great, but I don't see how to mandate that. >=20 > If the device was upgraded, it should support 4967. >=20 > Brian >=20 > On Apr 8, 2011, at 10:50 AM, Elwell, John wrote: >=20 > > Brian, > >=20 > > I am concerned about a device that works today by embedding=20 > a dial string in a SIP or TEL URI in some way, but not in=20 > accordance with RFC 4967. I would wager that devices=20 > supporting RFC 4967 are in a minority. > >=20 > > Many such devices work today with dial strings for=20 > non-emergency calls, and in most cases for emergency calls=20 > too (not using NG911). So I could dial 112 from many devices=20 > attached to networks in Europe and somehow an emergency call=20 > would be made. If I upgrade one of those devices to start=20 > encoding dial strings using RFC 4967, would they still work?=20 > Would they still be able to make non-emergency calls? Would=20 > they still be able to make emergency calls? My concern is=20 > that by mandating this we would break what works today. > >=20 > > John > >=20 > >=20 > >> -----Original Message----- > >> From: Brian Rosen [mailto:br@brianrosen.net]=20 > >> Sent: 08 April 2011 15:32 > >> To: Elwell, John > >> Cc: ecrit@ietf.org > >> Subject: Re: [Ecrit] Comment on latest changes to phone bcp -=20 > >> dial strings > >>=20 > >> phonebcp can't really deal in any sensible way with type 3,=20 > >> because there isn't any way to write "do the right thing" in=20 > >> the text, and the range of what "the right thing" could be=20 > is large. > >>=20 > >> What it deals with is type 2 (and of course, type 1). > >>=20 > >> It says that devices don't have to handle dial string=20 > >> interpretation, but if they don't, they must code dial=20 > >> strings as 4967 says in order that all proxies can recognize=20 > >> emergency calls and do correct processing. =20 > >>=20 > >> If we don't mandate specific behavior for conforming devices,=20 > >> we condemn any device that doesn't do full emergency=20 > >> processing to be subject to "do the right thing" at the proxy. > >>=20 > >> We've tried to avoid saying things in the text that basically=20 > >> amounts to: proxies and their associated registrars must=20 > >> refuse service to devices that don't allow the proxy to meet=20 > >> it's obligations to do the right thing for emergency calls. =20 > >> Of course there is no way to write such requirements, and=20 > >> mostly, there is no way to even discover what the registrar=20 > >> would need to know to make a decision. > >>=20 > >> Brian > >>=20 > >> On Apr 8, 2011, at 10:04 AM, Elwell, John wrote: > >>=20 > >>> Brian, > >>>=20 > >>> The problem with the text in the draft at present is it=20 > >> modifies behaviour for non-emergency calls, and I don't think=20 > >> that is acceptable. > >>>=20 > >>> I can imagine 3 types of devices: > >>> 1) Devices that comply with phonebcp, recognise an=20 > >> emergency dial string and convert to a service URN. > >>> 2) Devices that comply with phonebcp but do not recognise=20 > >> certain emergency dial strings. > >>> 3) Devices that do not comply with phonebcp. > >>>=20 > >>> To support type 3 devices, there will have to be some form=20 > >> of agreement between the device and the proxy as to how dial=20 > >> strings are delivered to the proxy. This applies to any dial=20 > >> string, whether it is for an emergency call or something=20 > >> else. This is common practice today, and generally does not=20 > >> involve RFC 4967 Tel URIs. Many working implementations=20 > >> pre-date RFC 4967. To support type 3 devices making emergency=20 > >> calls, proxies will presumably need to recognise emergency=20 > >> dial strings when delivered by whatever means dial strings=20 > >> are delivered by those devices.=20 > >>>=20 > >>> So I don't see the sense of upgrading those proxies to also=20 > >> support RFC 4967 dial stings from type 2 devices. It would be=20 > >> better for proxies to treat type 2 and type 3 devices the same. > >>>=20 > >>> John > >>>=20 > >>>> -----Original Message----- > >>>> From: Brian Rosen [mailto:br@brianrosen.net]=20 > >>>> Sent: 08 April 2011 14:29 > >>>> To: Elwell, John > >>>> Cc: ecrit@ietf.org > >>>> Subject: Re: [Ecrit] Comment on latest changes to phone bcp -=20 > >>>> dial strings > >>>>=20 > >>>> The BCP can't cover devices that don't conform to it, so the=20 > >>>> fact that some existing devices don't do what it says isn't=20 > >>>> relevant. This doesn't update 3261. It says if you do=20 > >>>> emergency calls, do it this way. The same applies to=20 > >>>> downstream proxies. Standardizing behavior makes sure that=20 > >>>> regardless of the device and the proxy, the call will be=20 > >>>> recognize as an emergency call and the right processing=20 > >> done for it. > >>>>=20 > >>>> Emergency calls have some special processing. I'd love to=20 > >>>> mandate that all devices conforming to it recognize dial=20 > >>>> strings, and process them into the urn. There was objection=20 > >>>> to going that far, and thus we have this alternate path. =20 > >>>> Your text won't work as is: it would have to be followed by a=20 > >>>> new requirement on proxies to recognize anything the device=20 > >>>> could put out. > >>>>=20 > >>>> Brian > >>>> On Apr 8, 2011, at 3:50 AM, Elwell, John wrote: > >>>>=20 > >>>>> In 9.2: > >>>>> "ED-63 The initial SIP signaling method is an INVITE request: > >>>>> 1. The Request URI SHOULD be the service URN in the=20 > >>>> "sos" tree. If > >>>>> the device does not interpret local dial strings,=20 > >>>> the Request- > >>>>> URI MUST be a dial string URI [RFC4967] with the=20 > >>>> dialed digits." > >>>>> I have a concern about the "MUST" in the last sentence=20 > >>>> (previously it was SHOULD). If the device does not interpret=20 > >>>> local dial strings, it will not recognise an emergency call,=20 > >>>> and therefore cannot be expected to comply with the=20 > >>>> requirements of this BCP. > >>>>>=20 > >>>>> I am not aware of any RFC that updates RFC 3261 to mandate=20 > >>>> the use of RFC 4967 when sending a dial string, so therefore=20 > >>>> this statement in phone BCP is effectively changing the=20 > >>>> behaviour of RFC 3261 for all calls (not just emergency=20 > >>>> calls), which I believe should be outside the scope of the BCP. > >>>>>=20 > >>>>> Different practices exist today for submitting dial=20 > >>>> strings, and acceptable forms will depend on the local proxy.=20 > >>>> For example, often a URI in the form "SIP:12345@example.com"=20 > >>>> is used in practice, and therefore for an emergency call it=20 > >>>> would be, for example, "SIP:112@example.com". > >>>>>=20 > >>>>> An example of acceptable text would be: > >>>>> "If the device does not interpret local dial strings and=20 > >>>> therefore is unable to recognise a request for an emergency=20 > >>>> call, it will behave as for any other call request for which=20 > >>>> the dial string cannot be interpreted. Normally this will=20 > >>>> involve submitting the dial string in the INVITE request in a=20 > >>>> form acceptable to the local proxy (e.g., in the form of a=20 > >>>> dial string URI [RFC4967])." > >>>>>=20 > >>>>> John > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>=20 > >>>>=20 > >>=20 > >>=20 >=20 > = From mlinsner@cisco.com Mon Apr 11 09:43:20 2011 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 5DE8C28C12F for ; Mon, 11 Apr 2011 09:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.289 X-Spam-Level: X-Spam-Status: No, score=-9.289 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5QVC-8btVIc for ; Mon, 11 Apr 2011 09:43:19 -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 4DDAD3A68DC for ; Mon, 11 Apr 2011 09:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=1201; q=dns/txt; s=iport; t=1302540200; x=1303749800; h=date:subject:from:to:message-id:mime-version; bh=zQ8mIUwjPEyGgGTS6KuhvtawWFp/ozrvQl+YH0L3Yq0=; b=NL96niknw8D533i8D5M8rQeOtNyRDm9ssrJgOWHvm1Nj0WpZwIN1dUvp myoBIqDrq85+aYio6Iow6Oauc3OV1d9XtsgDIU2htGEY6huY1XChxX9lE M9m4uktaoDrFaLA1FQi9ypIdUomV2EBiy2UnN/IYHKlPwEItV1WHq93/l w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcIALouo02rRDoH/2dsb2JhbACCYJxJhgRvd6c/nBaFbgSNWINq X-IronPort-AV: E=Sophos;i="4.63,339,1299456000"; d="scan'208,217";a="679093004" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 11 Apr 2011 16:43:19 +0000 Received: from [10.116.195.117] (rtp-mlinsner-8714.cisco.com [10.116.195.117]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3BGhGOH013410 for ; Mon, 11 Apr 2011 16:43:17 GMT User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Mon, 11 Apr 2011 12:43:14 -0400 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: Reminder - 2 wglc on-going - due this week Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3385370599_1055801" Subject: [Ecrit] Reminder - 2 wglc on-going - due this week X-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 Apr 2011 16:43:20 -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_3385370599_1055801 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Data Only http://www.ietf.org/mail-archive/web/ecrit/current/msg07532.html Rough Location http://www.ietf.org/mail-archive/web/ecrit/current/msg07529.html --B_3385370599_1055801 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Data Only

Rough Location


--B_3385370599_1055801-- From Martin.Thomson@commscope.com Mon Apr 11 16:15:27 2011 Return-Path: X-Original-To: ecrit@ietfc.amsl.com Delivered-To: ecrit@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8ED0CE0683 for ; Mon, 11 Apr 2011 16:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqxsS3CPquul for ; Mon, 11 Apr 2011 16:15:24 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfc.amsl.com (Postfix) with ESMTP id 38022E0680 for ; Mon, 11 Apr 2011 16:15:24 -0700 (PDT) X-AuditID: 0a0404e8-b7bd2ae0000014c1-fc-4da38b8bd736 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 28.84.05313.B8B83AD4; Mon, 11 Apr 2011 18:15:23 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 11 Apr 2011 18:15:23 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 12 Apr 2011 07:15:18 +0800 From: "Thomson, Martin" To: Marc Linsner , "ecrit@ietf.org" Date: Tue, 12 Apr 2011 07:15:17 +0800 Thread-Topic: WGLC - draft-ietf-ecrit-rough-loc-04 Thread-Index: AcvutABRubNk+Qf6QqWof3TCLivs2AJ6aaAw Message-ID: <8B0A9FCBB9832F43971E38010638454F0402958E6B@SISPE7MB1.commscope.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-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-rough-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 23:15:27 -0000 This document is ready to go. The draft currently states that it's standards track, though - as noted bel= ow - Informational is more appropriate. Nits: >From a readability perspective, the introduction to Section 4 is a little a= brupt. Introducing the concept of filtering might help. Several paragraphs are missing terminating periods. Page 4, first. Sectio= n 2, last. --Martin On 2011-03-30 at 19:24:10, Marc Linsner wrote: > This message starts the Working Group Last Call for draft "Using=20 > Imprecise Location for Emergency Call Routing" > (http://tools.ietf.org/html/draft-ietf-ecrit-rough-loc-04). >=20 > This draft fulfills the WG milestone: > Nov 2010 Submit 'Using Imprecise Location for Emergency Call > Routing' to the IESG for consideration as an Informational RFC >=20 > Please submit comments to the list by COB on Friday April 15, 2011. >=20 >=20 > Thanks, >=20 >=20 > -Marc Linsner- From Martin.Thomson@commscope.com Tue Apr 12 19:21:00 2011 Return-Path: X-Original-To: ecrit@ietfc.amsl.com Delivered-To: ecrit@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E90A4E07DB for ; Tue, 12 Apr 2011 19:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vP15RkyG4ufh for ; Tue, 12 Apr 2011 19:21:00 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfc.amsl.com (Postfix) with ESMTP id 29BD2E071F for ; Tue, 12 Apr 2011 19:21:00 -0700 (PDT) X-AuditID: 0a0404e8-b7bd2ae0000014c1-fc-4da5088bd567 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 9C.53.05313.B8805AD4; Tue, 12 Apr 2011 21:20:59 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Tue, 12 Apr 2011 21:20:59 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 13 Apr 2011 10:20:56 +0800 From: "Thomson, Martin" To: Marc Linsner , "ecrit@ietf.org" Date: Wed, 13 Apr 2011 10:20:54 +0800 Thread-Topic: WGLC - draft-ietf-ecrit-data-only-ea-01 Thread-Index: Acvu6bzPwKjLdwIiQfyWAisuweS3KAKlu5WQ Message-ID: <8B0A9FCBB9832F43971E38010638454F04029590A6@SISPE7MB1.commscope.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-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 02:21:01 -0000 The document is OK, modulo a few comments and nits: Comments: Section 3, Figure 2: Why does the sensor not perform the route selection it= self? If it doesn't, then this is little different to the first scenario, = where proxy =3D=3D aggregator. This text is strange: [...] In case the LoST resolution is done at an emergency services routing proxy rather than at the entity issuing the alert since it may not know the address of the receiver. =20 The reason given doesn't make any sense to me. A proxy might perform routi= ng because the sensor has limited capabilities, but that smells more like t= he scenario in Figure 1 instead. Suggest reworking this example to either = provide better justification, or to have the sensor do the LoST lookup. Section 4.2: It's unclear what interoperability gain is achieved by constra= ining the CAP contents in this manner. In particular, the scope seems like= a strange constraint. =20 Section 6.1: This seems to advocate the use of XML digital signatures. Tha= t would be a bad idea. Even CMS is better. JOES would be better still. Was "application/cap+xml" already taken? Nits: The example has a few errors: - It needs to be updated for the latest sipcore-location-conveyance version - The namespace prefix for the usage rules in the PIDF-LO are incorrect - The use of a mac: URI for identifying the device requires the definition = of the mac: URI scheme. What is the right case for scope? I didn't check what the right answer is,= but the example and the MUST use different case - one of them is probably = wrong. Who is "phrank"? [citation required] Section 6.3: hanging sentence in the threat description: "In scenario [...]= " --Martin On 2011-03-31 at 01:49:46, Marc Linsner wrote: > This message starts the Working Group Last Call for draft "Common=20 > Alerting Protocol (CAP) based Data-Only Emergency Alerts using >=20 > the Session Initiation Protocol (SIP) >=20 > " (http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01). >=20 > This draft fulfills the WG milestone: >=20 > Apr 2011 Submit 'Common Alerting Protocol (CAP) based Data-Only=20 > Emergency Alerts using the Session Initiation Protocol (SIP)' >=20 > Please submit comments to the list by COB on Friday April 15, 2011. >=20 >=20 > Thanks, >=20 >=20 > -Marc Linsner- From James.Winterbottom@commscope.com Tue Apr 12 20:48:44 2011 Return-Path: X-Original-To: ecrit@ietfc.amsl.com Delivered-To: ecrit@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6A5A5E0687 for ; Tue, 12 Apr 2011 20:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnKga6ylSq+1 for ; Tue, 12 Apr 2011 20:48:43 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfc.amsl.com (Postfix) with ESMTP id 98DFDE066A for ; Tue, 12 Apr 2011 20:48:43 -0700 (PDT) X-AuditID: 0a0404e8-b7bd2ae0000014c1-a1-4da51d1b5c63 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 6A.F4.05313.B1D15AD4; Tue, 12 Apr 2011 22:48:43 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Tue, 12 Apr 2011 22:48:42 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 13 Apr 2011 11:48:40 +0800 From: "Winterbottom, James" To: "Thomson, Martin" , Marc Linsner , "ecrit@ietf.org" Date: Wed, 13 Apr 2011 11:48:38 +0800 Thread-Topic: WGLC - draft-ietf-ecrit-data-only-ea-01 Thread-Index: Acvu6bzPwKjLdwIiQfyWAisuweS3KAKlu5WQAAIefDA= Message-ID: <5A55A45AE77F5941B18E5457ECAC818801210235F1BA@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F04029590A6@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F04029590A6@SISPE7MB1.commscope.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-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 03:48:44 -0000 On the mac URI scheme, we originally had this in the HELD identity extensio= ns but it was suggested in no uncertain terms that this had buckley's chanc= e of getting through. This led us to use an explicit XML entity, though I s= eem to recall somebody suggesting that we may have been able to do somethin= g with UUIDs. Cheers James=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Thomson, Martin > Sent: Wednesday, 13 April 2011 12:21 PM > To: Marc Linsner; ecrit@ietf.org > Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 >=20 > The document is OK, modulo a few comments and nits: >=20 > Comments: >=20 > Section 3, Figure 2: Why does the sensor not perform the route selection > itself? If it doesn't, then this is little different to the first > scenario, where proxy =3D=3D aggregator. This text is strange: >=20 > [...] In case the LoST > resolution is done at an emergency services routing proxy rather than > at the entity issuing the alert since it may not know the address of > the receiver. >=20 > The reason given doesn't make any sense to me. A proxy might perform > routing because the sensor has limited capabilities, but that smells more > like the scenario in Figure 1 instead. Suggest reworking this example to > either provide better justification, or to have the sensor do the LoST > lookup. >=20 > Section 4.2: It's unclear what interoperability gain is achieved by > constraining the CAP contents in this manner. In particular, the scope > seems like a strange constraint. >=20 > Section 6.1: This seems to advocate the use of XML digital signatures. > That would be a bad idea. Even CMS is better. JOES would be better > still. >=20 > Was "application/cap+xml" already taken? >=20 > Nits: >=20 > The example has a few errors: > - It needs to be updated for the latest sipcore-location-conveyance > version > - The namespace prefix for the usage rules in the PIDF-LO are > incorrect > - The use of a mac: URI for identifying the device requires the > definition of the mac: URI scheme. >=20 > What is the right case for scope? I didn't check what the right answer > is, but the example and the MUST use different case - one of them is > probably wrong. >=20 > Who is "phrank"? [citation required] >=20 > Section 6.3: hanging sentence in the threat description: "In scenario > [...]" >=20 > --Martin >=20 > On 2011-03-31 at 01:49:46, Marc Linsner wrote: > > This message starts the Working Group Last Call for draft "Common > > Alerting Protocol (CAP) based Data-Only Emergency Alerts using > > > > the Session Initiation Protocol (SIP) > > > > " (http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01). > > > > This draft fulfills the WG milestone: > > > > Apr 2011 Submit 'Common Alerting Protocol (CAP) based Data-Only > > Emergency Alerts using the Session Initiation Protocol (SIP)' > > > > Please submit comments to the list by COB on Friday April 15, 2011. > > > > > > Thanks, > > > > > > -Marc Linsner- >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From forte@att.com Fri Apr 15 12:00:27 2011 Return-Path: X-Original-To: ecrit@ietfc.amsl.com Delivered-To: ecrit@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5E95EE092F for ; Fri, 15 Apr 2011 12:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHqaGEEYVUkE for ; Fri, 15 Apr 2011 12:00:24 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfc.amsl.com (Postfix) with ESMTP id 3F0FCE09A8 for ; Fri, 15 Apr 2011 12:00:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: forte@att.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1302894013!14567080!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 4457 invoked from network); 15 Apr 2011 19:00:13 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-5.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Apr 2011 19:00:13 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p3FJ0bUa024096 for ; Fri, 15 Apr 2011 15:00:37 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p3FJ0XTZ023991 for ; Fri, 15 Apr 2011 15:00:33 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p3FJ09fD000433 for ; Fri, 15 Apr 2011 15:00:09 -0400 Received: from [151.109.8.240] (ds151-109-8-240.dhcps.ugn.att.com [151.109.8.240]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p3FIxtuF032089 for ; Fri, 15 Apr 2011 15:00:04 -0400 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Fri, 15 Apr 2011 14:59:53 -0400 From: "Andrea G. Forte" To: "ecrit@ietf.org" Message-ID: Thread-Topic: New Version Notification for draft-forte-lost-extensions-03 In-Reply-To: <20110415185558.CC032E06C6@ietfc.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [Ecrit] FW: New Version Notification for draft-forte-lost-extensions-03 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 19:00:27 -0000 FYI. I think I have addressed most of the concerns. Please, let me know if you have further comments. http://www.ietf.org/id/draft-forte-lost-extensions-03.txt Regards, -Andrea On 4/15/11 2:55 PM, "IETF I-D Submission Tool" wrote: > >A new version of I-D, draft-forte-lost-extensions-03.txt has been >successfully submitted by Andrea Forte and posted to the IETF repository. > >Filename: draft-forte-lost-extensions >Revision: 03 >Title: Location-to-Service Translation Protocol (LoST) Extensions >Creation_date: 2011-04-15 >WG ID: Independent Submission >Number_of_pages: 23 > >Abstract: >An important class of location-based services answer the question >"What instances of this service are closest to me?" Examples include >finding restaurants, gas stations, stores, automated teller machines, >wireless access points (hot spots) or parking spaces. Currently, the >Location-to-Service Translation (LoST) protocol only supports mapping >locations to a single service based on service regions. This >document describes an extension that allows queries of the type "N >nearest", "within distance X" and "served by". > > > > >The IETF Secretariat. > > From jgunn6@csc.com Mon Apr 18 12:22:28 2011 Return-Path: X-Original-To: ecrit@ietfc.amsl.com Delivered-To: ecrit@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 60611E0714 for ; Mon, 18 Apr 2011 12:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2wknSKWLwLh for ; Mon, 18 Apr 2011 12:22:25 -0700 (PDT) Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by ietfc.amsl.com (Postfix) with ESMTP id 55D74E0694 for ; Mon, 18 Apr 2011 12:22:23 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-4.tower-164.messagelabs.com!1303154541!42851692!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 1082 invoked from network); 18 Apr 2011 19:22:22 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-4.tower-164.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Apr 2011 19:22:22 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id p3IJMJss019801 for ; Mon, 18 Apr 2011 15:22:21 -0400 In-Reply-To: References: To: Robert Sparks , ecrit@ietf.org MIME-Version: 1.0 X-KeepSent: 968BAE2F:50D07487-85257876:0069D185; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Mon, 18 Apr 2011 15:20:32 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP1 HF29|January 09, 2011) at 04/18/2011 03:21:12 PM, Serialize complete at 04/18/2011 03:21:12 PM Content-Type: multipart/alternative; boundary="=_alternative 006A303A85257876_=" Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 19:22:28 -0000 This is a multipart message in MIME format. --=_alternative 006A303A85257876_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGVyZSBhcmUgbXkgY29tbWVudHMgb24gLWxvY2FsLWVtZXJnZW5jeS1ycGgtbmFtZXNwYWNlIChm cm9tIGxhc3QgQXVndXN0KSwgDQogd2hpY2ggYXBwYXJlbnRseSBkaWQgbm90IGdldCBpbmNvcnBv cmF0ZWQuDQoNCk1vc3RseSBuaXRzLCBidXQgYSBjb3VwbGUgb2YgIGNvbW1lbnRzIG9uIGNvbnRl bnQuDQotLQ0KRmlyc3QgY29tbWVudCBvbiBjb250ZW50DQoNCkF0IHRoZSBlbmQgb2Ygc2VjdGlv biAyIGl0IHNheXMNCuKAnCAgIFRvIGJlIGNsZWFyLCBzcGVjaWZpY2FsbHkgZm9yIHRoZSB1c2Ug b2YgYW4gZWRnZSBwcm94eSBpbiBhbnkgDQogICBuZXR3b3JrLCBiZWNhdXNlIHRoZSAiZXNuZXQi IG5hbWVzcGFjZSBpcyBhbGxvd2VkIHRvIGJlIG1vZGlmaWVkIG9yIA0KICAgZGVsZXRlZCBhdCB0 aGUgZWRnZSBwcm94eSBvZiB0aGUgRVNJbmV0IGRvZXMgbm90IGFsbG93IGFueSBlZGdlIA0KICAg cHJveHkgdG8gbW9kaWZ5IG9yIGRlbGV0ZSBhbnkgb3RoZXIgUmVzb3VyY2UtUHJpb3JpdHkgbmFt ZXNwYWNlLuKAnQ0KDQpGaXJzdCBvZiBhbGwsIHRoaXMgaXMgYSBsb25nIGFuZCBhd2t3YXJkIHNl bnRlbmNlLCBhbmQgYSBsaXR0bGUgYml0IA0KYXdrd2FyZCB0byB1bmRlcnN0YW5kLiAgQnV0IHlv dSBTRUVNIHRvIGJlIHNheWluZyB0aGF0IGFuIOKAnGVkZ2UgcHJveHkgb24gDQphbnkgbmV0d29y a+KAnSBpcyBub3QgYWxsb3dlZCB0byAgbW9kaWZ5IG9yIGRlbGV0ZSBhbnkgT1RIRVIgUi1QIG5h bWVzcGFjZS4NCg0KSWYgdGhhdCBpcyBOT1Qgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBzYXksIHRo ZW4geW91IG5lZWQgdG8gcmV3b3JkIGl0IHRvIA0KbWFrZSBpdCBjbGVhciB0aGF0IHlvdSBhcmUg b25seSByZWZlcnJpbmcgdG8gbW9kaWZ5aW5nIG9yIGRlbGV0aW5nIHRoZSANCmVzaW5ldCBoZWFk ZXIuDQoNCklmIHRoYXQgSVMgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBzYXksIHRoZW4gSSB0YWtl IHN0cm9uZyBvYmplY3Rpb24gdG8gdGhlIA0KRVNJTkVUIE5hbWVzcGFjZSBJRCAoYW5kIGxhdGVy IFJGQykgcHJvc2NyaWJpbmcgd2hhdCBvdGhlciBuZXR3b3Jr4oCZcyBlZGdlIA0KcHJveGllcyBj YW4gZG8gd2l0aC90byBvdGhlciBuYW1lc3BhY2UgaGVhZGVycywgYW5kIGV2ZW4gd2hhdCB0aGUg RVNJbmV0IA0KcHJveGllcyBjYW4gZG8gd2l0aC90byBvdGhlciBuYW1lc3BhY2UgaGVhZGVycy4N Cg0KUGVyaGFwcyB3aGF0IHlvdSBtZWFuIGlzIA0K4oCcICAgVG8gYmUgY2xlYXIsIGV2ZW4gdGhv dWdoIGFuIGVkZ2UgcHJveHkgIG9mIHRoZSBFU0luZXQgbWF5IG1vZGlmeSBvciANCmRlbGV0ZSBh biBSLVAgSGVhZGVyIHdpdGggdGhlICBFU0lORVQgbmFtZXNwYWNlLCB0aGlzIGhhcyBubyBiZWFy aW5nIG9uIA0Kd2hldGhlciBvciBub3QgYSBnaXZlbiBwcm94eSAob24gRVNJbmV0IG9yIGVsc2V3 aGVyZSkgaXMgYWxsb3dlZCB0byBtb2RpZnkgDQphbiBSLVAgSGVhZGVyIHdpdGggYSBkaWZmZXJl bnQgbmFtZXNwYWNlLuKAnQ0KDQpSZW1lbWJlciB0aGF0IDQ0MTIgc2F5cyB0aGF0IEFOWSBwcm94 eSBjYW4gcmVtb3ZlIG9yIG1vZGlmeSBBTlkgUi1QIEhlYWRlciANCihhbWRyIGluIHRhYmxlIDIp DQotLQ0KDQpUaGUgc2Vjb25kIGNvbW1lbnQgb24gY29udGVudCBpcyBhYm91dCB0aGUg4oCcaW50 ZW5kZWQgYWxnb3JpdGht4oCdLg0KDQpSRkM0NDEyICBzYXlzIHRoYXQg4oCcQm90aCBhbGdvcml0 aG1zIGNhbiBzb21ldGltZXMgYmUgY29tYmluZWQgaW4NCiAgIHRoZSBzYW1lIGVsZW1lbnQsIGFs dGhvdWdoIG5vbmUgb2YgdGhlIG5hbWVzcGFjZXMgZGVzY3JpYmVkIGluIHRoaXMNCiAgIGRvY3Vt ZW50IGRvIHRoaXMu4oCdIChlLmcuLCBib3RoIOKAnHByZWVtcHRpb27igJ0gYW5kIOKAnHF1ZXVl 4oCdKS7igJ0NCiAgQnV0IHRoZSBJQU5BIHJlZ2lzdHJhdGlvbiByZXF1aXJlcyB5b3UgdG8gY2hv c2Ugb25lIG9yIHRoZSBvdGhlciDigJMgeW91IA0KY2hvc2Ug4oCccXVldWXigJ0uDQoNCkl0IHNl ZW1zIHRoYXQgeW91IHdhbnQgdG8gcGVybWl0IOKAnGJvdGggYWxnb3JpdGhtcyBjb21iaW5lZCBp biB0aGUgc2FtZSANCmVsZW1lbnTigJ0sIGJ1dCB0aGUgYWN0dWFsIHRleHQgc3dpdGNoZXMgYmFj ayBhbmQgZm9ydGggaW4gYSB2ZXJ5IGNvbmZ1c2luZyANCndheS4NCg0KRmlyc3QgeW91IHNheQ0K 4oCcVGhlcmUgaXMgdGhlIHBvc3NpYmlsaXR5IHRoYXQgd2l0aGluIGVtZXJnZW5jeSBzZXJ2aWNl cyBuZXR3b3JrcyAtIA0KICAgcHJvdmlkZWQgbG9jYWwgcG9saWN5IHN1cHBvcnRzIGVuYWJsaW5n IHRoaXMgZnVuY3Rpb24gLSBhIE11bHRpbGV2ZWwNCiAgIFByZWNlZGVuY2UgYW5kIFByZWVtcHRp b24gKE1MUFApLWxpa2UgYmVoYXZpb3IgY2FuIGJlIGFjaGlldmVkIA0KICAgKGxpa2VseSB3aXRo b3V0IHRoZSAncHJlZW1wdGlvbicgcGFydCwgd2hpY2ggd2lsbCBhbHdheXMgYmUgYSBtYXR0ZXIN CiAgIG9mIGxvY2FsIHBvbGljeSwgYW5kIGRlZmluZWQgaGVyZSkg4oCcDQoNCi1NZW50aW9uaW5n IE1MUFAvUHJlZW1wdGlvbiBiZWZvcmUgbWVudGlvbmluZyBRdWV1aW5nIGltcGxpZXMgdGhhdCBN TFBQIGlzIA0KdGhlIGRvbWluYW50IGFsZ29yaXRobQ0KDQot4oCcTUxQUC1saWtlIGJlaGF2aW9y IHdpdGhvdXQgdGhlIHByZWVtcHRpb24gcGFydOKAnSAgaXMgcHJldHR5IGluZWZmZWN0aXZlIA0K Zm9yIGFueXRoaW5nLiAgQnV0IGEgY29tYmluYXRpb24gb2YgTUxQUCBhbmQgcXVldWluZyAoYXMg aW4gM0dQUCBlTUxQUCkgDQpjYW4gYmUgZWZmZWN0aXZlLg0KDQotV2hhdCBkb2VzIOKAnGFuZCBk ZWZpbmVkIGhlcmXigJ0gcmVmZXIgdG8/IE1MUFAgd2l0aG91dCBwcmVlbXB0aW9uPyDigJxsb2Nh bCANCnBvbGljeeKAnT8gSW4gZWl0aGVyIGNhc2UgSSBkb27igJl0IGZpbmQgaXQg4oCcZGVmaW5l ZCBoZXJl4oCdLiANCg0KVGhlbiBvbiB0aGUgbmV4dCBwYWdlIHlvdSBzYXkNCuKAnFRoZSAiZXNu ZXQiIG5hbWVzcGFjZSBoYXMgNSBwcmlvcml0eS12YWx1ZXMsIGluIGEgc3BlY2lmaWVkIHJlbGF0 aXZlIA0KICAgcHJpb3JpdHkgb3JkZXIsIGFuZCBpcyBhIHF1ZXVlLWJhc2VkIHRyZWF0bWVudCBu YW1lc3BhY2UgW1JGQzQ0MTJdLiANCiAgIEluZGl2aWR1YWwganVyaXNkaWN0aW9ucyBNQVkgY29u ZmlndXJlIHRoZWlyIFNJUCBlbnRpdGllcyBmb3IgDQogICBwcmVlbXB0aW9uIHRyZWF0bWVudC4g VGhpcyBpcyBPUFRJT05BTCwgc3ViamVjdCB0byBsb2NhbCBwb2xpY3kgDQogICBkZWNpc2lvbnMu 4oCdDQoNCi1pdCB3b3VsZCBiZSBhIGxvdCBjbGVhcmVyICBpZiB5b3UgcmVwbGFjZWQgdGhlIGVh cmxpZXIgcmVmZXJlbmNlIHRvIA0KTUxQUCB3aXRob3V0IHByZWVtcHRpb24gd2l0aCBzb21ldGhp bmcgbGlrZS0NCuKAnFdpdGhpbiBhbiBFbWVyZ2VuY3kgU2VydmljZXMgTmV0d29yaywgaXQgaXMg cG9zc2libGUgdGhhdCBsb2NhbCBwb2xpY3kgDQp3aWxsIGludm9sdmUgYSBjb21iaW5hdGlvbiBv ZiDigJxwcmVlbXB0aW9u4oCdIGFuZCDigJxxdWV1aW5n4oCdIGFsZ29yaXRobXMsIGFzIA0KcGVy bWl0dGVkIGJ5IFJGQzQ0MTIsIHRob3VnaCBxdWV1aW5nIGlzIGV4cGVjdGVkIHRvIGJlIHRoZSBk b21pbmFudCANCmFsZ29yaXRobSwgYW5kIGlzIHNlbGVjdGVkIGluIHRoZSBJQU5BIHJlZ2lzdHJh dGlvbi4gIFRoaXMgY29tYmluYXRpb24gY2FuIA0KZW5zdXJlIHRoYXQgbW9yZSBpbXBvcnRhbnQg Y2FsbHMgYXJlIGVzdGFibGlzaGVkIG9yIHJldGFpbmVkLiBUaGUgImVzbmV0IiANCm5hbWVzcGFj ZSBpcyBnaXZlbiA1IHByaW9yaXR5LWxldmVscywgYW5hbG9nb3VzIHRvIG90aGVyIFByZW1lbXB0 aW9uIGJhc2VkIA0KYW5kIFF1ZXVlIGJhc2VkIG5hbWVzcGFjZXMuICBUaGUgTUxQUC1saWtlIFNJ UCBzaWduYWxpbmcgbmVlZGVkIGZvciB0aGUgDQpwcmVlbXB0aW9uIHNpZGUgb2YgYSBjb21iaW5l ZCBhbGdvcml0aG0gaXMgbm90IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCANCmZvciA5MTEvMTEy Lzk5OSBzdHlsZSBlbWVyZ2VuY3kgY2FsbGluZywgYnV0IGl0IGlzIG5vdCBwcmV2ZW50ZWQgZWl0 aGVyLuKAnQ0KDQpBbmQgdGhlbiB0aGUgc2Vjb25kIGJlY29tZXMtDQrigJxUaGUgImVzbmV0IiBu YW1lc3BhY2UgaGFzIDUgcHJpb3JpdHktdmFsdWVzLCBpbiBhIHNwZWNpZmllZCByZWxhdGl2ZSAN CiAgIHByaW9yaXR5IG9yZGVyLCBhbmQgaXMgYSByZWdpc3RlcmVkIGFzIGEgcXVldWUtYmFzZWQg dHJlYXRtZW50IA0KbmFtZXNwYWNlIFtSRkM0NDEyXS4gDQogIEhvd2V2ZXIsIGFzIHBlcm1pdHRl ZCBpbiBSRkM0NDEyLCBpbmRpdmlkdWFsIGp1cmlzZGljdGlvbnMgTUFZIGNvbmZpZ3VyZSANCnRo ZWlyIFNJUCBlbnRpdGllcyBmb3IgYSBjb21iaW5hdGlvbiBvZiBxdWV1aW5nIGFuZCBwcmVlbXB0 aW9uIHRyZWF0bWVudCwgDQpvciBldmVuIGEgcHJlZW1wdGlvbiBvbmx5IHRyZWF0bWVudC4gVGhp cyBzZWxlY3Rpb24gb2YgdGhlIHRyZWF0bWVudCANCmFsZ29yaXRobSBpcyBPUFRJT05BTCwgc3Vi amVjdCB0byBsb2NhbCBwb2xpY3kgZGVjaXNpb25zLuKAnQ0KDQoNCk5vdyB0byB0aGUgbml0cy4N Cg0KSW4gdGhlIGludHJvZHVjdGlvbiwgeW91IHNheSA6DQrigJxUaGlzIG5ldyBuYW1lc3BhY2Ug aXMgdG8gYmUgdXNlZCB3aXRoaW4gcHVibGljIHNhZmV0eSBhbnN3ZXJpbmcgDQogICBwb2ludCAg KFBTQVApIG5ldHdvcmtzLuKAnQ0KDQpCdXQgdGhpcyBhcHBlYXJzIHRvIGJlIGFuIG92ZXItc2lt cGxpZmljYXRpb24sIGFzIGVsc2V3aGVyZSB5b3Ugc2F5IHRoYXQgDQooZGVwZW5kYW50LCBvZiBj b3Vyc2UsIG9uIHRoZSBwcm9wZXIgYnVzaW5lc3MgYW5kIHBvbGljeSBhZ3JlZW1lbnRzKToNCuKA nEFkamFjZW50IEFTUHMgdG8gdGhlIEVTSW5ldCBNQVkgaGF2ZSBhIA0KICAgdHJ1c3QgcmVsYXRp b25zaGlwIHRoYXQgaW5jbHVkZXMgYWxsb3dpbmcgdGhpcy90aGVzZSBuZWlnaGJvcmluZyANCiAg IEFTUChzKSB0byB1c2UgdGhlICJlc25ldCIgbmFtZXNwYWNlIHRvIGRpZmZlcmVudGlhdGUgU0lQ IHJlcXVlc3RzIA0KICAgYW5kIGRpYWxvZ3Mgd2l0aGluIHRoZSBBU1AncyBuZXR3b3JrLuKAnSAo bW9yZSBvbiBvdGhlciBjb25jZXJucyB3aXRoIA0KdGhpcyBzZW50ZW5jZSBsYXRlcikuDQpQZXJo YXBzIHJld29yZCB0aGUgc2VudGVuY2UgaW4gdGhlIEludHJvIHRvIHNheSA6DQrigJxUaGlzIG5l dyBuYW1lc3BhY2UgaXMgdG8gYmUgdXNlZCB3aXRoaW4sIG9yIGluIGNvbmp1bmN0aW9uIHdpdGgs IHB1YmxpYyANCnNhZmV0eSBhbnN3ZXJpbmcgDQogICBwb2ludCAgKFBTQVApIG5ldHdvcmtzLuKA nQ0KDQoNCkxhdGVyIG9uIGluIHRoZSBJbnRybywgeW91IHNheToNCuKAnFRoaXMgaW5kaWNhdGlv biBpcyANCiAgIHVzZWQgc29sZWx5IHRvIGRpZmZlcmVudGlhdGUgU0lQIHJlcXVlc3RzLCB0cmFu c2FjdGlvbnMgb3IgZGlhbG9ncywgDQogICBmcm9tIG90aGVyIHJlcXVlc3RzLCB0cmFuc2FjdGlv bnMgb3IgZGlhbG9ncyB0aGF0IGRvIG5vdCBoYXZlIHRoZSANCiAgIG5lZWQgZm9yIHByaW9yaXR5 IHRyZWF0bWVudC7igJ0NCg0KVGhlIHdheSBpdCBpcyB3b3JkZWQgc291bmRzIGFzIGlmIHlvdSBh cmUgZGlzdGluZ3Vpc2hpbmcg4oCcU0lQIHJlcXVlc3Rz4oCdLCANCmZyb20g4oCcbm9uLVNJUCBy ZXF1ZXN0c+KAnSwgYnV0IEkgZG8gbm90IHRoaW5rIHRoYXQgaXMgd2hhdCB5b3UgbWVhbi4gIEkg DQp0aGluayB5b3UgbWVhbjoNCuKAnFRoaXMgaW5kaWNhdGlvbiBpcyANCiAgIHVzZWQgc29sZWx5 IHRvIGRpZmZlcmVudGlhdGUgUFNBUC1yZWxhdGVkIFNJUCByZXF1ZXN0cywgdHJhbnNhY3Rpb25z IG9yIA0KZGlhbG9ncywgDQogICBmcm9tIG90aGVyLCBub24gUFNBUC1yZWxhdGVkLCBTSVAgIHJl cXVlc3RzLCB0cmFuc2FjdGlvbnMgb3IgZGlhbG9ncywgDQp0aGF0IGRvIG5vdCBoYXZlIHRoZSAN CiAgIG5lZWQgZm9yIHByaW9yaXR5IHRyZWF0bWVudC7igJ0NCg0KTmV4dCBzZW50ZW5jZSBzYXlz Og0K4oCcSWYgdGhlcmUgYXJlIGRpZmZlcmluZywgeWV0IHN0aWxsIA0KICAgdmFsaWQgUmVzb3Vy Y2UtUHJpb3JpdHkgaGVhZGVyIHZhbHVlcyBiZXR3ZWVuIFNJUCByZXF1ZXN0cyBpbiBhIA0KICAg bmV0d29yaywgdGhlbiB0aGlzIGluZGljYXRpb24gY2FuIGJlIHVzZWQgYnkgbG9jYWwgcG9saWN5 IHRvIA0KICAgZGV0ZXJtaW5lIHdoaWNoIFNJUCByZXF1ZXN0LCB0cmFuc2FjdGlvbiBvciBkaWFs b2cgcmVjZWl2ZXMgd2hpY2ggDQogICB0cmVhdG1lbnQgKGxpa2VseSBiZXR0ZXIgb3Igd29yc2Ug dGhhbiBhbm90aGVyKS7igJ0NCg0KR29pbmcgYmFjayB0byB0aGUgd29yZGluZyBvZiA0NDEyLCB0 aGUgcG9pbnQgaXMgd2hldGhlciBvciBub3QgdGhlIA0KbmFtZXNwYWNlcyBhcmUg4oCcdW5kZXJz dG9vZOKAnSwgbm90IGp1c3Qgd2hldGhlciB0aGUgdmFsdWVzIGFyZSB2YWxpZC4NCg0KQnV0IEkg ZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSB5b3Ugc2F5IOKAnGJldHdlZW7igJ0gaW4gdGhpcyBjb250 ZXh0Lg0KDQpTdWdnZXN0Og0K4oCcQXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gOCBvZiBSRkM0NDEy LCBvdGhlciBuYW1lc3BhY2VzLCBub3QgdW5kZXJzdG9vZCBieSANCnRoZSBTSVAgYWN0b3IgYXJl IGlnbm9yZWQuICBJZiBtdWx0aXBsZSBSUEggbmFtZXNwYWNlcyBhcmUgdW5kZXJzdG9vZCBieSAN CnRoZSBTSVAgYWN0b3IsIGl0IG11c3QgY3JlYXRlIGEgbG9jYWwgdG90YWwgb3JkZXJpbmcgYWNy b3NzIGFsbCByZXNvdXJjZSANCnZhbHVlcyBmcm9tIHRoZSBuYW1lc3BhY2VzIGl0IHVuZGVyc3Rh bmRzLiBUaGlzIHdpbGwgZGV0ZXJtaW5lIHRoZSANCnJlbGF0aXZlIHByaW9yaXR5IHdpdGggd2hp Y2ggZWFjaCBtZXNzYWdlLCByZXF1ZXN0LCB0cmFuc2FjdGlvbiBvciBkaWFsb2cgDQppcyB0cmVh dGVkLuKAnQ0KDQpJbiBzZWN0aW9uIDIsIHlvdSBzYXk6DQrigJxFdmVyeSB1c2Ugb2YgdGhpcyBu YW1lc3BhY2Ugd2lsbCBiZSBpbiB0aW1lcyBvZiBhbiBlbWVyZ2VuY3ksIHdoZXJlIA0KICAgYXQg bGVhc3Qgb25lIGVuZCBvZiB0aGUgc2lnbmFsaW5nIGlzIHdpdGhpbiBhIGxvY2FsIGVtZXJnZW5j eSANCm9yZ2FuaXphdGlvbi7igJ0NCg0KVGhpcywgb2YgY291cnNlLCBiZWdzIHRoZSBxdWVzdGlv biAtd2hhdCBpcyB0aGUgZGVmaW5pdGlvbiBvZiBhIOKAnHRpbWUgb2YgDQplbWVyZ2VuY3nigJ0/ ICBEb2VzIHNvbWUgYXV0aG9yaXR5IGhhdmUgdG8gZm9ybWFsbHkgZGVjbGFyZSBhIOKAnHRpbWUg b2YgDQplbWVyZ2VuY3nigJ0/ICBJdCB3b3VsZCBzZWVtIHRoYXQsIGJ5IGRlZmluaXRpb24sIGV2 ZXJ5IDkxMS8xMTIvOTk5IGNhbGwgDQpyZXByZXNlbnRzIGEg4oCcdGltZSBvZiBlbWVyZ2VuY3ni gJ0sIGF0IGxlYXN0IGZvciB0aGUgY2FsbGVyLg0KDQpBbmQgd2hhdCBkbyB5b3UgbWVhbiBieSDi gJxvbmUgZW5kIG9mIHNpZ25hbGluZz8gSXMgYSBCMkJVQSBhbiDigJxlbmTigJ0/DQoNCldoYXQg aXMgdGhlIGRlZmluaXRpb24gb2Yg4oCcYSBsb2NhbCBlbWVyZ2VuY3kgb3JnYW5pemF0aW9u4oCd Pw0KDQpJZiBhIFBTQVAgaXMgZGlyZWN0bHkgY29ubmVjdGVkIHRvIHRoZSAocHVibGljKSBTZXJ2 aWNlIFByb3ZpZGVyIG5ldHdvcmssIA0Kd2l0aG91dCBhIHNlcGFyYXRlIOKAnEVTSSBuZXR3b3Jr 4oCdLCBpcyBpdCBhbGxvd2VkIHRvIHVzZSB0aGlzIG5hbWVzcGFjZT8NCg0KSSBhbSBjb25mdXNl ZCBieSB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIHRlcm1pbm9sb2d5IGluIEZpZ3VyZSAx IGFuZCANCnRoZSB0ZXJtaW5vbG9neSBpbiB0aGUgdGV4dC4NCg0KVGhlIHRleHQgcmVmZXJzIHRv IOKAnEFwcGxpY2F0aW9uIFNlcnZpY2UgUHJvdmlkZXJzIChBU1ApIGRpcmVjdGx5IGF0dGFjaGVk IA0KdG8gYW4gRVNJbmV04oCdICh3aGljaCBtYXkgaGF2ZSBhIHRydXN0IHJlbGF0aW9uc2hpcCB3 aXRoIHRoZSBFU0luZXQsIGFuZCANCnRodXMgbWF5IHVzZSB0aGUgZXNpbmV0IG5hbWVzcGFjZSku ICBCdXQgdGhlIGZpZ3VyZSBkb2VzIG5vdCBzaG93IGFuIEFTUCwgDQppdCBzaG93cyBzb21ldGhp bmcgY2FsbGVkIGEg4oCcU2VydmljZSBOZXR3b3Jr4oCdLiAgSXMgdGhlIOKAnFNlcnZpY2UgTmV0 d29ya+KAnSANCnN1cHBvc2VkIHRvIGJlIHRoZSDigJxBU1DigJ0/DQoNClRoaXMgc2VudGVuY2Ug aW4gc2VjIDMuMiBpcyByYXRoZXIgYXdrd2FyZDoNCuKAnFRoZSBydWxlcyBvcmlnaW5hdGVkIGlu IFJGQyA0NDEyIHJlbWFpbiB3aXRoIHJlZ2FyZCB0byBhbiBSUCBhY3RvciwgDQogICB3aG8gdW5k ZXJzdGFuZHMgbW9yZSB0aGFuIG9uZSBuYW1lc3BhY2UsIE1VU1QgbWFpbnRhaW4gaXRzIGxvY2Fs bHkgDQogICBzaWduaWZpY2FudCByZWxhdGl2ZSBwcmlvcml0eSBvcmRlci7igJ0NCg0KUGVyaGFw cyANCiDigJxUaGUgcnVsZXMgb3JpZ2luYXRlZCBpbiBSRkMgNDQxMiAsIHRoYXQgYW4gUlAgYWN0 b3IsIA0KICAgd2hvIHVuZGVyc3RhbmRzIG1vcmUgdGhhbiBvbmUgbmFtZXNwYWNlLCBNVVNUIG1h aW50YWluIGl0cyBsb2NhbGx5IA0KICAgc2lnbmlmaWNhbnQgcmVsYXRpdmUgcHJpb3JpdHkgb3Jk ZXIsIHJlbWFpbiBpbiBlZmZlY3Qu4oCdDQoNCkluIHNlY3Rpb24gNiwgdGhpcyBzZW50ZW5jZSBp cyBhbWJpZ3VvdXM6DQrigJwgICBUaGUgaW1wbGljYXRpb25zIG9mIHVzaW5nIHRoaXMgbmFtZXNw YWNlIHdpdGhpbiB0aGUgDQogICBSZXNvdXJjZS1Qcmlvcml0eSBoZWFkZXIgZmllbGQgaW5jb3Jy ZWN0bHkgY2FuIGNhdXNlIGEgbGFyZ2UgaW1wYWN0IA0KICAgb24gYSBuZXR3b3JrIC0gZ2l2ZW4g dGhhdCB0aGlzIGluZGljYXRpb24gaXMgdG8gZ2l2ZSBwcmVmZXJlbnRpYWwgDQogICB0cmVhdG1l bnQgb2YgbWFya2VkIHRyYWZmaWMgZ3JlYXQgcHJlZmVyZW5jZSB3aXRoaW4gdGhlIG5ldHdvcmsg dGhhbg0KICAgb3RoZXIgdHJhZmZpYy7igJ0NCg0KRmlyc3QsIOKAnG1hcmtlZOKAnSBjb3VsZCBt ZWFuIG1hbnkgZGlmZmVyZW50IHRoaW5ncy4gIFNlY29uZCwgZ2l2ZW4gdGhhdCB5b3UgDQpoYXZl IDUgZGlmZmVyZW50IHByaW9yaXR5IGxldmVscywgaXQgaXMgdW5saWtlbHkgdGhhdCB0aGV5IEFM TCDigJxnaXZlIA0KcHJlZmVyZW50aWFsICAgIHRyZWF0bWVudCBvZiBtYXJrZWQgdHJhZmZpYyBn cmVhdCBwcmVmZXJlbmNl4oCdICh3aGljaCBpcyANCmFsc28gcmVkdW5kYW50KS4NCg0KU3VnZ2Vz dDoNCuKAnEluY29ycmVjdGx5IHVzaW5nIHRoaXMgbmFtZXNwYWNlIHdpdGhpbiB0aGUgDQogICBS ZXNvdXJjZS1Qcmlvcml0eSBoZWFkZXIgZmllbGQgY2FuIGNhdXNlIGEgbGFyZ2UgaW1wYWN0IA0K ICAgb24gYSBuZXR3b3JrLiAgRm9yIHNvbWUgcHJpb3JpdHkgdmFsdWVzLCAgdGhpcyBuYW1lc3Bh Y2UgY2FuIGdpdmUgZ3JlYXQgDQpwcmVmZXJlbmNlIHdpdGhpbiB0aGUgbmV0d29yaw0KICAgdG8g bWFya2VkIHRyYWZmaWMgb3ZlciBvdGhlciB0cmFmZmljLuKAnQ0KDQpUaGFua3MNCg0KSmFuZXQN Cg0KVGhpcyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIA0KZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2luZGx5IGFk dmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4gDQpkZWxpdmVyeS4gDQpOT1RFOiBS ZWdhcmRsZXNzIG9mIGNvbnRlbnQsIHRoaXMgZS1tYWlsIHNoYWxsIG5vdCBvcGVyYXRlIHRvIGJp bmQgQ1NDIHRvIA0KYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0 byBleHBsaWNpdCB3cml0dGVuIGFncmVlbWVudCANCm9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBl eHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNlIG9mIGUtbWFpbCBmb3Igc3VjaCANCnB1cnBvc2Uu DQoNCg0KDQpGcm9tOg0KUm9iZXJ0IFNwYXJrcyA8cmpzcGFya3NAbm9zdHJ1bS5jb20+DQpUbzoN CkphbmV0IFAgR3Vubi9VU0EvQ1NDQENTQw0KRGF0ZToNCjA0LzA3LzIwMTEgMDE6NDIgUE0NClN1 YmplY3Q6DQpSZTogW0Vjcml0XSBkcmFmdC1pZXRmLWVjcml0LWxvY2FsLWVtZXJnZW5jeS1ycGgt bmFtZXNwYWNlDQoNCg0KDQpIaSBKYW5ldCAtDQoNCkknbSBwaWNraW5nIHRoaXMgYmFjayB1cCAo aXQgZmVsbCBiZXR3ZWVuIHNvbWUgY3JhY2tzKS4gRGlkIHlvdSBnZXQgYSANCmNoYW5jZSB0byBy ZXZpZXcgaXQgbGFzdCB5ZWFyPw0KDQpSalMNCg0KT24gQXVnIDUsIDIwMTAsIGF0IDY6MTcgQU0s IEphbmV0IFAgR3VubiB3cm90ZToNCg0KDQpJIHBsYW4gdG8gcmV2aWV3IGl0LCBidXQgbm90IHVu dGlsIHRoZSBzZWNvbmQgaGFsZiBvZiBBdWd1c3QuIA0KDQpKYW5ldA0KDQpUaGlzIGlzIGEgUFJJ VkFURSBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2UgDQpkZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5IGUtbWFp bCBvZiB0aGUgbWlzdGFrZSBpbiANCmRlbGl2ZXJ5LiANCk5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29u dGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gYmluZCBDU0MgdG8gDQphbnkg b3JkZXIgb3Igb3RoZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1YW50IHRvIGV4cGxpY2l0IHdyaXR0 ZW4gYWdyZWVtZW50IA0Kb3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0 aW5nIHRoZSB1c2Ugb2YgZS1tYWlsIGZvciBzdWNoIA0KcHVycG9zZS4gDQoNCg0KRnJvbTogDQpN YXJjIExpbnNuZXIgPG1saW5zbmVyQGNpc2NvLmNvbT4gDQpUbzogDQoiJ2Vjcml0JyIgPGVjcml0 QGlldGYub3JnPiANCkRhdGU6IA0KMDgvMDMvMjAxMCAwMzowNCBQTSANClN1YmplY3Q6IA0KW0Vj cml0XSBkcmFmdC1pZXRmLWVjcml0LWxvY2FsLWVtZXJnZW5jeS1ycGgtbmFtZXNwYWNlDQoNCg0K DQoNCkFsbCwNCg0KQXMgeW91IGFsbCBrbm93LCBSUEggbmFtZXNwYWNlIGlzIGFuIEVDUklUIGRy YWZ0IHdpdGhvdXQgYSBtaWxlc3RvbmUuICBBdA0KdGhlIG1lZXRpbmcgbGFzdCB3ZWVrIFJvYmVy dCBTcGFya3MgYW5ub3VuY2VkIGhlIGlzIHdpbGxpbmcgdG8gQUQgc3BvbnNvcg0KdGhpcyBkcmFm dC4NCg0KUm9iZXJ0IGFza3MgZXZlcnlvbmUgdG8gcmVhZCB0aGUgZHJhZnQgYW5kIGNvbW1lbnQg b24gaXQgdG8gdGhpcyBsaXN0Lg0KDQpUaGFua3MsDQoNCi1NYXJjLQ0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QN CkVjcml0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vj cml0DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkVjcml0IG1haWxpbmcgbGlzdA0KRWNyaXRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KDQoNCg== --=_alternative 006A303A85257876_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlcmUgYXJlIG15IGNvbW1lbnRz IG9uIC1sb2NhbC1lbWVyZ2VuY3ktcnBoLW5hbWVzcGFjZQ0KKGZyb20gbGFzdCBBdWd1c3QpLCAm bmJzcDt3aGljaCBhcHBhcmVudGx5IGRpZCBub3QgZ2V0IGluY29ycG9yYXRlZC48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPk1vc3RseSBuaXRzLCBidXQgYSBj b3VwbGUgb2YgJm5ic3A7Y29tbWVudHMNCm9uIGNvbnRlbnQuPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDYWxpYnJpIj4tLTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2Fs aWJyaSI+Rmlyc3QgY29tbWVudCBvbiBjb250ZW50PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDYWxpYnJpIj5BdCB0aGUgZW5kIG9mIHNlY3Rpb24gMiBpdCBzYXlzPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj7igJwgJm5ic3A7IFRvIGJlIGNsZWFy LCBzcGVjaWZpY2FsbHkgZm9yDQp0aGUgdXNlIG9mIGFuIGVkZ2UgcHJveHkgaW4gYW55IDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO25ldHdvcmss IGJlY2F1c2UgdGhlICZxdW90O2VzbmV0JnF1b3Q7DQpuYW1lc3BhY2UgaXMgYWxsb3dlZCB0byBi ZSBtb2RpZmllZCBvciA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZu YnNwOyAmbmJzcDtkZWxldGVkIGF0IHRoZSBlZGdlIHByb3h5DQpvZiB0aGUgRVNJbmV0IGRvZXMg bm90IGFsbG93IGFueSBlZGdlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+Jm5ic3A7ICZuYnNwO3Byb3h5IHRvIG1vZGlmeSBvciBkZWxldGUNCmFueSBvdGhlciBSZXNv dXJjZS1Qcmlvcml0eSBuYW1lc3BhY2Uu4oCdPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj5GaXJzdCBvZiBhbGwsIHRoaXMgaXMgYSBsb25nIGFuZCBhd2t3YXJk DQpzZW50ZW5jZSwgYW5kIGEgbGl0dGxlIGJpdCBhd2t3YXJkIHRvIHVuZGVyc3RhbmQuICZuYnNw O0J1dCB5b3UgU0VFTSB0bw0KYmUgc2F5aW5nIHRoYXQgYW4g4oCcZWRnZSBwcm94eSBvbiBhbnkg bmV0d29ya+KAnSBpcyBub3QgYWxsb3dlZCB0byAmbmJzcDttb2RpZnkNCm9yIGRlbGV0ZSBhbnkg T1RIRVIgUi1QIG5hbWVzcGFjZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNhbGlicmkiPklmIHRoYXQgaXMgTk9UIHdoYXQgeW91IGFyZSB0cnlpbmcgdG8gc2F5LA0KdGhl biB5b3UgbmVlZCB0byByZXdvcmQgaXQgdG8gbWFrZSBpdCBjbGVhciB0aGF0IHlvdSBhcmUgb25s eSByZWZlcnJpbmcNCnRvIG1vZGlmeWluZyBvciBkZWxldGluZyB0aGUgZXNpbmV0IGhlYWRlci48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPklmIHRoYXQgSVMg d2hhdCB5b3UgYXJlIHRyeWluZyB0byBzYXksDQp0aGVuIEkgdGFrZSBzdHJvbmcgb2JqZWN0aW9u IHRvIHRoZSBFU0lORVQgTmFtZXNwYWNlIElEIChhbmQgbGF0ZXIgUkZDKQ0KcHJvc2NyaWJpbmcg d2hhdCBvdGhlciBuZXR3b3Jr4oCZcyBlZGdlIHByb3hpZXMgY2FuIGRvIHdpdGgvdG8gb3RoZXIg bmFtZXNwYWNlDQpoZWFkZXJzLCBhbmQgZXZlbiB3aGF0IHRoZSBFU0luZXQgcHJveGllcyBjYW4g ZG8gd2l0aC90byBvdGhlciBuYW1lc3BhY2UNCmhlYWRlcnMuPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5QZXJoYXBzIHdoYXQgeW91IG1lYW4gaXMgPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj7igJwgJm5ic3A7IFRvIGJlIGNsZWFy LCBldmVuIHRob3VnaCBhbiBlZGdlDQpwcm94eSAmbmJzcDtvZiB0aGUgRVNJbmV0IG1heSBtb2Rp Znkgb3IgZGVsZXRlIGFuIFItUCBIZWFkZXIgd2l0aCB0aGUgJm5ic3A7RVNJTkVUDQpuYW1lc3Bh Y2UsIHRoaXMgaGFzIG5vIGJlYXJpbmcgb24gd2hldGhlciBvciBub3QgYSBnaXZlbiBwcm94eSAo b24gRVNJbmV0DQpvciBlbHNld2hlcmUpIGlzIGFsbG93ZWQgdG8gbW9kaWZ5IGFuIFItUCBIZWFk ZXIgd2l0aCBhIGRpZmZlcmVudCBuYW1lc3BhY2Uu4oCdPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5SZW1lbWJlciB0aGF0IDQ0MTIgc2F5cyB0aGF0IEFOWSBw cm94eQ0KY2FuIHJlbW92ZSBvciBtb2RpZnkgQU5ZIFItUCBIZWFkZXIgKGFtZHIgaW4gdGFibGUg Mik8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPi0tPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5UaGUgc2Vjb25kIGNvbW1lbnQgb24g Y29udGVudCBpcyBhYm91dA0KdGhlIOKAnGludGVuZGVkIGFsZ29yaXRobeKAnS48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlJGQzQ0MTIgJm5ic3A7c2F5cyB0 aGF0IOKAnEJvdGggYWxnb3JpdGhtcw0KY2FuIHNvbWV0aW1lcyBiZSBjb21iaW5lZCBpbjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO3RoZSBzYW1l IGVsZW1lbnQsIGFsdGhvdWdoDQpub25lIG9mIHRoZSBuYW1lc3BhY2VzIGRlc2NyaWJlZCBpbiB0 aGlzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7 ZG9jdW1lbnQgZG8gdGhpcy7igJ0gKGUuZy4sDQpib3RoIOKAnHByZWVtcHRpb27igJ0gYW5kIOKA nHF1ZXVl4oCdKS7igJ08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZu YnNwOyBCdXQgdGhlIElBTkEgcmVnaXN0cmF0aW9uIHJlcXVpcmVzDQp5b3UgdG8gY2hvc2Ugb25l IG9yIHRoZSBvdGhlciDigJMgeW91IGNob3NlIOKAnHF1ZXVl4oCdLjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+SXQgc2VlbXMgdGhhdCB5b3Ugd2FudCB0byBw ZXJtaXQg4oCcYm90aA0KYWxnb3JpdGhtcyBjb21iaW5lZCBpbiB0aGUgc2FtZSBlbGVtZW504oCd LCBidXQgdGhlIGFjdHVhbCB0ZXh0IHN3aXRjaGVzDQpiYWNrIGFuZCBmb3J0aCBpbiBhIHZlcnkg Y29uZnVzaW5nIHdheS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGli cmkiPkZpcnN0IHlvdSBzYXk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki PuKAnFRoZXJlIGlzIHRoZSBwb3NzaWJpbGl0eSB0aGF0IHdpdGhpbg0KZW1lcmdlbmN5IHNlcnZp Y2VzIG5ldHdvcmtzIC0gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4m bmJzcDsgJm5ic3A7cHJvdmlkZWQgbG9jYWwgcG9saWN5IHN1cHBvcnRzDQplbmFibGluZyB0aGlz IGZ1bmN0aW9uIC0gYSBNdWx0aWxldmVsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj4mbmJzcDsgJm5ic3A7UHJlY2VkZW5jZSBhbmQgUHJlZW1wdGlvbg0KKE1MUFApLWxp a2UgYmVoYXZpb3IgY2FuIGJlIGFjaGlldmVkIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwOyhsaWtlbHkgd2l0aG91dCB0aGUgJ3ByZWVtcHRpb24n DQpwYXJ0LCB3aGljaCB3aWxsIGFsd2F5cyBiZSBhIG1hdHRlcjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO29mIGxvY2FsIHBvbGljeSwgYW5kIGRl ZmluZWQNCmhlcmUpIOKAnDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2Fs aWJyaSI+LU1lbnRpb25pbmcgTUxQUC9QcmVlbXB0aW9uIGJlZm9yZSBtZW50aW9uaW5nDQpRdWV1 aW5nIGltcGxpZXMgdGhhdCBNTFBQIGlzIHRoZSBkb21pbmFudCBhbGdvcml0aG08L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPi3igJxNTFBQLWxpa2UgYmVoYXZp b3Igd2l0aG91dCB0aGUgcHJlZW1wdGlvbg0KcGFydOKAnSAmbmJzcDtpcyBwcmV0dHkgaW5lZmZl Y3RpdmUgZm9yIGFueXRoaW5nLiAmbmJzcDtCdXQgYSBjb21iaW5hdGlvbg0Kb2YgTUxQUCBhbmQg cXVldWluZyAoYXMgaW4gM0dQUCBlTUxQUCkgY2FuIGJlIGVmZmVjdGl2ZS48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPi1XaGF0IGRvZXMg4oCcYW5kIGRlZmlu ZWQgaGVyZeKAnSByZWZlciB0bz8NCk1MUFAgd2l0aG91dCBwcmVlbXB0aW9uPyDigJxsb2NhbCBw b2xpY3nigJ0/IEluIGVpdGhlciBjYXNlIEkgZG9u4oCZdCBmaW5kDQppdCDigJxkZWZpbmVkIGhl cmXigJ0uIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhl biBvbiB0aGUgbmV4dCBwYWdlIHlvdSBzYXk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNhbGlicmkiPuKAnFRoZSAmcXVvdDtlc25ldCZxdW90OyBuYW1lc3BhY2UgaGFzIDUNCnByaW9y aXR5LXZhbHVlcywgaW4gYSBzcGVjaWZpZWQgcmVsYXRpdmUgPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7cHJpb3JpdHkgb3JkZXIsIGFuZCBpcyBh IHF1ZXVlLWJhc2VkDQp0cmVhdG1lbnQgbmFtZXNwYWNlIFtSRkM0NDEyXS4gPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7SW5kaXZpZHVhbCBqdXJp c2RpY3Rpb25zIE1BWQ0KY29uZmlndXJlIHRoZWlyIFNJUCBlbnRpdGllcyBmb3IgPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7cHJlZW1wdGlvbiB0 cmVhdG1lbnQuIFRoaXMNCmlzIE9QVElPTkFMLCBzdWJqZWN0IHRvIGxvY2FsIHBvbGljeSA8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDtkZWNpc2lv bnMu4oCdPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4taXQg d291bGQgYmUgYSBsb3QgY2xlYXJlciAmbmJzcDtpZiB5b3UNCnJlcGxhY2VkIHRoZSBlYXJsaWVy IHJlZmVyZW5jZSB0byAmbmJzcDs8YnI+DQpNTFBQIHdpdGhvdXQgcHJlZW1wdGlvbiB3aXRoIHNv bWV0aGluZyBsaWtlLTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+4oCc V2l0aGluIGFuIEVtZXJnZW5jeSBTZXJ2aWNlcyBOZXR3b3JrLA0KaXQgaXMgcG9zc2libGUgdGhh dCBsb2NhbCBwb2xpY3kgd2lsbCBpbnZvbHZlIGEgY29tYmluYXRpb24gb2Yg4oCccHJlZW1wdGlv buKAnQ0KYW5kIOKAnHF1ZXVpbmfigJ0gYWxnb3JpdGhtcywgYXMgcGVybWl0dGVkIGJ5IFJGQzQ0 MTIsIHRob3VnaCBxdWV1aW5nIGlzDQpleHBlY3RlZCB0byBiZSB0aGUgZG9taW5hbnQgYWxnb3Jp dGhtLCBhbmQgaXMgc2VsZWN0ZWQgaW4gdGhlIElBTkEgcmVnaXN0cmF0aW9uLg0KJm5ic3A7VGhp cyBjb21iaW5hdGlvbiBjYW4gZW5zdXJlIHRoYXQgbW9yZSBpbXBvcnRhbnQgY2FsbHMgYXJlIGVz dGFibGlzaGVkDQpvciByZXRhaW5lZC4gVGhlICZxdW90O2VzbmV0JnF1b3Q7IG5hbWVzcGFjZSBp cyBnaXZlbiA1IHByaW9yaXR5LWxldmVscywNCmFuYWxvZ291cyB0byBvdGhlciBQcmVtZW1wdGlv biBiYXNlZCBhbmQgUXVldWUgYmFzZWQgbmFtZXNwYWNlcy4gJm5ic3A7VGhlDQpNTFBQLWxpa2Ug U0lQIHNpZ25hbGluZyBuZWVkZWQgZm9yIHRoZSBwcmVlbXB0aW9uIHNpZGUgb2YgYSBjb21iaW5l ZCBhbGdvcml0aG0NCmlzIG5vdCBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgZm9yIDkxMS8xMTIv OTk5IHN0eWxlIGVtZXJnZW5jeSBjYWxsaW5nLA0KYnV0IGl0IGlzIG5vdCBwcmV2ZW50ZWQgZWl0 aGVyLuKAnTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+QW5k IHRoZW4gdGhlIHNlY29uZCBiZWNvbWVzLTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+4oCcVGhlICZxdW90O2VzbmV0JnF1b3Q7IG5hbWVzcGFjZSBoYXMgNQ0KcHJpb3Jp dHktdmFsdWVzLCBpbiBhIHNwZWNpZmllZCByZWxhdGl2ZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDtwcmlvcml0eSBvcmRlciwgYW5kIGlzIGEg cmVnaXN0ZXJlZA0KYXMgYSBxdWV1ZS1iYXNlZCB0cmVhdG1lbnQgbmFtZXNwYWNlIFtSRkM0NDEy XS4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgSG93ZXZl ciwgYXMgcGVybWl0dGVkIGluIFJGQzQ0MTIsDQppbmRpdmlkdWFsIGp1cmlzZGljdGlvbnMgTUFZ IGNvbmZpZ3VyZSB0aGVpciBTSVAgZW50aXRpZXMgZm9yIGEgY29tYmluYXRpb24NCm9mIHF1ZXVp bmcgYW5kIHByZWVtcHRpb24gdHJlYXRtZW50LCBvciBldmVuIGEgcHJlZW1wdGlvbiBvbmx5IHRy ZWF0bWVudC4NClRoaXMgc2VsZWN0aW9uIG9mIHRoZSB0cmVhdG1lbnQgYWxnb3JpdGhtIGlzIE9Q VElPTkFMLCBzdWJqZWN0IHRvIGxvY2FsDQpwb2xpY3kgZGVjaXNpb25zLuKAnTwvZm9udD4NCjxi cj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Tm93IHRvIHRoZSBuaXRz LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+SW4gdGhlIGlu dHJvZHVjdGlvbiwgeW91IHNheSA6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxp YnJpIj7igJxUaGlzIG5ldyBuYW1lc3BhY2UgaXMgdG8gYmUgdXNlZCB3aXRoaW4NCnB1YmxpYyBz YWZldHkgYW5zd2VyaW5nIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ Jm5ic3A7ICZuYnNwO3BvaW50ICZuYnNwOyhQU0FQKSBuZXR3b3Jrcy7igJ08L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkJ1dCB0aGlzIGFwcGVhcnMgdG8gYmUg YW4gb3Zlci1zaW1wbGlmaWNhdGlvbiwNCmFzIGVsc2V3aGVyZSB5b3Ugc2F5IHRoYXQgKGRlcGVu ZGFudCwgb2YgY291cnNlLCBvbiB0aGUgcHJvcGVyIGJ1c2luZXNzDQphbmQgcG9saWN5IGFncmVl bWVudHMpOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+4oCcQWRqYWNl bnQgQVNQcyB0byB0aGUgRVNJbmV0IE1BWSBoYXZlDQphIDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO3RydXN0IHJlbGF0aW9uc2hpcCB0aGF0IGlu Y2x1ZGVzDQphbGxvd2luZyB0aGlzL3RoZXNlIG5laWdoYm9yaW5nIDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO0FTUChzKSB0byB1c2UgdGhlICZx dW90O2VzbmV0JnF1b3Q7DQpuYW1lc3BhY2UgdG8gZGlmZmVyZW50aWF0ZSBTSVAgcmVxdWVzdHMg PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7YW5k IGRpYWxvZ3Mgd2l0aGluIHRoZSBBU1Ancw0KbmV0d29yay7igJ0gKG1vcmUgb24gb3RoZXIgY29u Y2VybnMgd2l0aCB0aGlzIHNlbnRlbmNlIGxhdGVyKS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNhbGlicmkiPlBlcmhhcHMgcmV3b3JkIHRoZSBzZW50ZW5jZSBpbiB0aGUgSW50cm8N CnRvIHNheSA6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj7igJxUaGlz IG5ldyBuYW1lc3BhY2UgaXMgdG8gYmUgdXNlZCB3aXRoaW4sDQpvciBpbiBjb25qdW5jdGlvbiB3 aXRoLCBwdWJsaWMgc2FmZXR5IGFuc3dlcmluZyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDtwb2ludCAmbmJzcDsoUFNBUCkgbmV0d29ya3Mu4oCd PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5MYXRl ciBvbiBpbiB0aGUgSW50cm8sIHlvdSBzYXk6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDYWxpYnJpIj7igJxUaGlzIGluZGljYXRpb24gaXMgPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7dXNlZCBzb2xlbHkgdG8gZGlmZmVyZW50aWF0 ZQ0KU0lQIHJlcXVlc3RzLCB0cmFuc2FjdGlvbnMgb3IgZGlhbG9ncywgPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7ZnJvbSBvdGhlciByZXF1ZXN0 cywgdHJhbnNhY3Rpb25zDQpvciBkaWFsb2dzIHRoYXQgZG8gbm90IGhhdmUgdGhlIDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO25lZWQgZm9yIHBy aW9yaXR5IHRyZWF0bWVudC7igJ08L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNhbGlicmkiPlRoZSB3YXkgaXQgaXMgd29yZGVkIHNvdW5kcyBhcyBpZiB5b3UgYXJlDQpkaXN0 aW5ndWlzaGluZyDigJxTSVAgcmVxdWVzdHPigJ0sIGZyb20g4oCcbm9uLVNJUCByZXF1ZXN0c+KA nSwgYnV0IEkgZG8gbm90DQp0aGluayB0aGF0IGlzIHdoYXQgeW91IG1lYW4uICZuYnNwO0kgdGhp bmsgeW91IG1lYW46PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj7igJxU aGlzIGluZGljYXRpb24gaXMgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJp Ij4mbmJzcDsgJm5ic3A7dXNlZCBzb2xlbHkgdG8gZGlmZmVyZW50aWF0ZQ0KUFNBUC1yZWxhdGVk IFNJUCByZXF1ZXN0cywgdHJhbnNhY3Rpb25zIG9yIGRpYWxvZ3MsIDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO2Zyb20gb3RoZXIsIG5vbiBQU0FQ LXJlbGF0ZWQsDQpTSVAgJm5ic3A7cmVxdWVzdHMsIHRyYW5zYWN0aW9ucyBvciBkaWFsb2dzLCB0 aGF0IGRvIG5vdCBoYXZlIHRoZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGli cmkiPiZuYnNwOyAmbmJzcDtuZWVkIGZvciBwcmlvcml0eSB0cmVhdG1lbnQu4oCdPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5OZXh0IHNlbnRlbmNlIHNheXM6 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj7igJxJZiB0aGVyZSBhcmUg ZGlmZmVyaW5nLCB5ZXQgc3RpbGwgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxp YnJpIj4mbmJzcDsgJm5ic3A7dmFsaWQgUmVzb3VyY2UtUHJpb3JpdHkgaGVhZGVyDQp2YWx1ZXMg YmV0d2VlbiBTSVAgcmVxdWVzdHMgaW4gYSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNhbGlicmkiPiZuYnNwOyAmbmJzcDtuZXR3b3JrLCB0aGVuIHRoaXMgaW5kaWNhdGlvbg0KY2Fu IGJlIHVzZWQgYnkgbG9jYWwgcG9saWN5IHRvIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO2RldGVybWluZSB3aGljaCBTSVAgcmVxdWVzdCwNCnRy YW5zYWN0aW9uIG9yIGRpYWxvZyByZWNlaXZlcyB3aGljaCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDt0cmVhdG1lbnQgKGxpa2VseSBiZXR0ZXIg b3INCndvcnNlIHRoYW4gYW5vdGhlciku4oCdPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj5Hb2luZyBiYWNrIHRvIHRoZSB3b3JkaW5nIG9mIDQ0MTIsIHRoZQ0K cG9pbnQgaXMgd2hldGhlciBvciBub3QgdGhlIG5hbWVzcGFjZXMgYXJlIOKAnHVuZGVyc3Rvb2Ti gJ0sIG5vdCBqdXN0IHdoZXRoZXINCnRoZSB2YWx1ZXMgYXJlIHZhbGlkLjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+QnV0IEkgZG9u4oCZdCB1bmRlcnN0YW5k IHdoeSB5b3Ugc2F5IOKAnGJldHdlZW7igJ0NCmluIHRoaXMgY29udGV4dC48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlN1Z2dlc3Q6PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj7igJxBcyBkZXNjcmliZWQgaW4gc2VjdGlvbiA4IG9m IFJGQzQ0MTIsDQpvdGhlciBuYW1lc3BhY2VzLCBub3QgdW5kZXJzdG9vZCBieSB0aGUgU0lQIGFj dG9yIGFyZSBpZ25vcmVkLiAmbmJzcDtJZg0KbXVsdGlwbGUgUlBIIG5hbWVzcGFjZXMgYXJlIHVu ZGVyc3Rvb2QgYnkgdGhlIFNJUCBhY3RvciwgaXQgbXVzdCBjcmVhdGUNCmEgbG9jYWwgdG90YWwg b3JkZXJpbmcgYWNyb3NzIGFsbCByZXNvdXJjZSB2YWx1ZXMgZnJvbSB0aGUgbmFtZXNwYWNlcyBp dA0KdW5kZXJzdGFuZHMuIFRoaXMgd2lsbCBkZXRlcm1pbmUgdGhlIHJlbGF0aXZlIHByaW9yaXR5 IHdpdGggd2hpY2ggZWFjaA0KbWVzc2FnZSwgcmVxdWVzdCwgdHJhbnNhY3Rpb24gb3IgZGlhbG9n IGlzIHRyZWF0ZWQu4oCdPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxp YnJpIj5JbiBzZWN0aW9uIDIsIHlvdSBzYXk6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDYWxpYnJpIj7igJxFdmVyeSB1c2Ugb2YgdGhpcyBuYW1lc3BhY2Ugd2lsbCBiZSBpbg0KdGlt ZXMgb2YgYW4gZW1lcmdlbmN5LCB3aGVyZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNhbGlicmkiPiZuYnNwOyAmbmJzcDthdCBsZWFzdCBvbmUgZW5kIG9mIHRoZSBzaWduYWxpbmcN CmlzIHdpdGhpbiBhIGxvY2FsIGVtZXJnZW5jeSAmbmJzcDtvcmdhbml6YXRpb24u4oCdPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5UaGlzLCBvZiBjb3Vyc2Us IGJlZ3MgdGhlIHF1ZXN0aW9uIC13aGF0DQppcyB0aGUgZGVmaW5pdGlvbiBvZiBhIOKAnHRpbWUg b2YgZW1lcmdlbmN54oCdPyAmbmJzcDtEb2VzIHNvbWUgYXV0aG9yaXR5DQpoYXZlIHRvIGZvcm1h bGx5IGRlY2xhcmUgYSDigJx0aW1lIG9mIGVtZXJnZW5jeeKAnT8gJm5ic3A7SXQgd291bGQgc2Vl bSB0aGF0LA0KYnkgZGVmaW5pdGlvbiwgZXZlcnkgOTExLzExMi85OTkgY2FsbCByZXByZXNlbnRz IGEg4oCcdGltZSBvZiBlbWVyZ2VuY3nigJ0sDQphdCBsZWFzdCBmb3IgdGhlIGNhbGxlci48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkFuZCB3aGF0IGRvIHlv dSBtZWFuIGJ5IOKAnG9uZSBlbmQgb2Ygc2lnbmFsaW5nPw0KSXMgYSBCMkJVQSBhbiDigJxlbmTi gJ0/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5XaGF0IGlz IHRoZSBkZWZpbml0aW9uIG9mIOKAnGEgbG9jYWwgZW1lcmdlbmN5DQpvcmdhbml6YXRpb27igJ0/ PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5JZiBhIFBTQVAg aXMgZGlyZWN0bHkgY29ubmVjdGVkIHRvIHRoZQ0KKHB1YmxpYykgU2VydmljZSBQcm92aWRlciBu ZXR3b3JrLCB3aXRob3V0IGEgc2VwYXJhdGUg4oCcRVNJIG5ldHdvcmvigJ0sDQppcyBpdCBhbGxv d2VkIHRvIHVzZSB0aGlzIG5hbWVzcGFjZT88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNhbGlicmkiPkkgYW0gY29uZnVzZWQgYnkgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVu DQp0aGUgdGVybWlub2xvZ3kgaW4gRmlndXJlIDEgYW5kIHRoZSB0ZXJtaW5vbG9neSBpbiB0aGUg dGV4dC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlRoZSB0 ZXh0IHJlZmVycyB0byDigJxBcHBsaWNhdGlvbiBTZXJ2aWNlDQpQcm92aWRlcnMgKEFTUCkgZGly ZWN0bHkgYXR0YWNoZWQgdG8gYW4gRVNJbmV04oCdICh3aGljaCBtYXkgaGF2ZSBhIHRydXN0DQpy ZWxhdGlvbnNoaXAgd2l0aCB0aGUgRVNJbmV0LCBhbmQgdGh1cyBtYXkgdXNlIHRoZSBlc2luZXQg bmFtZXNwYWNlKS4gJm5ic3A7QnV0DQp0aGUgZmlndXJlIGRvZXMgbm90IHNob3cgYW4gQVNQLCBp dCBzaG93cyBzb21ldGhpbmcgY2FsbGVkIGEg4oCcU2VydmljZQ0KTmV0d29ya+KAnS4gJm5ic3A7 SXMgdGhlIOKAnFNlcnZpY2UgTmV0d29ya+KAnSBzdXBwb3NlZCB0byBiZSB0aGUg4oCcQVNQ4oCd PzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhpcyBzZW50 ZW5jZSBpbiBzZWMgMy4yIGlzIHJhdGhlciBhd2t3YXJkOjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQ2FsaWJyaSI+4oCcVGhlIHJ1bGVzIG9yaWdpbmF0ZWQgaW4gUkZDIDQ0MTIgcmVt YWluDQp3aXRoIHJlZ2FyZCB0byBhbiBSUCBhY3RvciwgPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7d2hvIHVuZGVyc3RhbmRzIG1vcmUgdGhhbg0K b25lIG5hbWVzcGFjZSwgTVVTVCBtYWludGFpbiBpdHMgbG9jYWxseSA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDtzaWduaWZpY2FudCByZWxhdGl2 ZSBwcmlvcml0eQ0Kb3JkZXIu4oCdPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDYWxpYnJpIj5QZXJoYXBzIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+Jm5ic3A74oCcVGhlIHJ1bGVzIG9yaWdpbmF0ZWQgaW4gUkZDIDQ0MTINCiwgdGhhdCBhbiBS UCBhY3RvciwgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsg Jm5ic3A7d2hvIHVuZGVyc3RhbmRzIG1vcmUgdGhhbg0Kb25lIG5hbWVzcGFjZSwgTVVTVCBtYWlu dGFpbiBpdHMgbG9jYWxseSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki PiZuYnNwOyAmbmJzcDtzaWduaWZpY2FudCByZWxhdGl2ZSBwcmlvcml0eQ0Kb3JkZXIsIHJlbWFp biBpbiBlZmZlY3Qu4oCdPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxp YnJpIj5JbiBzZWN0aW9uIDYsIHRoaXMgc2VudGVuY2UgaXMgYW1iaWd1b3VzOjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+4oCcICZuYnNwOyBUaGUgaW1wbGljYXRpb25z IG9mIHVzaW5nIHRoaXMNCm5hbWVzcGFjZSB3aXRoaW4gdGhlIDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO1Jlc291cmNlLVByaW9yaXR5IGhlYWRl ciBmaWVsZA0KaW5jb3JyZWN0bHkgY2FuIGNhdXNlIGEgbGFyZ2UgaW1wYWN0IDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO29uIGEgbmV0d29yayAt IGdpdmVuIHRoYXQNCnRoaXMgaW5kaWNhdGlvbiBpcyB0byBnaXZlIHByZWZlcmVudGlhbCA8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDt0cmVhdG1l bnQgb2YgbWFya2VkIHRyYWZmaWMNCmdyZWF0IHByZWZlcmVuY2Ugd2l0aGluIHRoZSBuZXR3b3Jr IHRoYW48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJz cDtvdGhlciB0cmFmZmljLuKAnTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+Rmlyc3QsIOKAnG1hcmtlZOKAnSBjb3VsZCBtZWFuIG1hbnkgZGlmZmVyZW50DQp0 aGluZ3MuICZuYnNwO1NlY29uZCwgZ2l2ZW4gdGhhdCB5b3UgaGF2ZSA1IGRpZmZlcmVudCBwcmlv cml0eSBsZXZlbHMsDQppdCBpcyB1bmxpa2VseSB0aGF0IHRoZXkgQUxMIOKAnGdpdmUgcHJlZmVy ZW50aWFsICZuYnNwOyAmbmJzcDt0cmVhdG1lbnQNCm9mIG1hcmtlZCB0cmFmZmljIGdyZWF0IHBy ZWZlcmVuY2XigJ0gKHdoaWNoIGlzIGFsc28gcmVkdW5kYW50KS48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlN1Z2dlc3Q6PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDYWxpYnJpIj7igJxJbmNvcnJlY3RseSB1c2luZyB0aGlzIG5hbWVzcGFjZSB3 aXRoaW4NCnRoZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNw OyAmbmJzcDtSZXNvdXJjZS1Qcmlvcml0eSBoZWFkZXIgZmllbGQNCmNhbiBjYXVzZSBhIGxhcmdl IGltcGFjdCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAm bmJzcDtvbiBhIG5ldHdvcmsuICZuYnNwO0ZvciBzb21lDQpwcmlvcml0eSB2YWx1ZXMsICZuYnNw O3RoaXMgbmFtZXNwYWNlIGNhbiBnaXZlIGdyZWF0IHByZWZlcmVuY2Ugd2l0aGluDQp0aGUgbmV0 d29yazwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNw O3RvIG1hcmtlZCB0cmFmZmljIG92ZXIgb3RoZXINCnRyYWZmaWMu4oCdPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3M8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkphbmV0PGJyPg0KPGJyPg0KVGhpcyBp cyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlDQpkZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5 IGUtbWFpbCBvZiB0aGUgbWlzdGFrZSBpbg0KZGVsaXZlcnkuIDxicj4NCk5PVEU6IFJlZ2FyZGxl c3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gYmluZCBDU0MN CnRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGlj aXQgd3JpdHRlbiBhZ3JlZW1lbnQNCm9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkg cGVybWl0dGluZyB0aGUgdXNlIG9mIGUtbWFpbCBmb3Igc3VjaA0KcHVycG9zZS48L2ZvbnQ+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkZyb206PC9mb250 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5Sb2JlcnQgU3BhcmtzICZsdDty anNwYXJrc0Bub3N0cnVtLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD48Zm9u dCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5Ubzo8L2ZvbnQ+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkphbmV0IFAgR3Vubi9VU0EvQ1NDQENTQzwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZh Y2U9InNhbnMtc2VyaWYiPkRhdGU6PC9mb250Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4wNC8wNy8yMDExIDAxOjQyIFBNPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+U3ViamVjdDo8L2Zv bnQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbRWNyaXRdIGRyYWZ0 LWlldGYtZWNyaXQtbG9jYWwtZW1lcmdlbmN5LXJwaC1uYW1lc3BhY2U8L2ZvbnQ+PC90YWJsZT4N Cjxicj4NCjxociBub3NoYWRlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5IaSBKYW5l dCAtPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5JJ20gcGlja2luZyB0aGlzIGJhY2sg dXAgKGl0IGZlbGwgYmV0d2VlbiBzb21lIGNyYWNrcykuDQpEaWQgeW91IGdldCBhIGNoYW5jZSB0 byByZXZpZXcgaXQgbGFzdCB5ZWFyPzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+UmpT PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5PbiBBdWcgNSwgMjAxMCwgYXQgNjoxNyBB TSwgSmFuZXQgUCBHdW5uIHdyb3RlOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KSSBwbGFuIHRvIHJldmlldyBpdCwgYnV0IG5vdCB1bnRpbCB0 aGUgc2Vjb25kIGhhbGYgb2YgQXVndXN0LjwvZm9udD48Zm9udCBzaXplPTM+DQo8YnI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkphbmV0PGJyPg0KPGJyPg0K VGhpcyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlDQpkZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBraW5kbHkgYWR2aXNl IHVzIGJ5IGUtbWFpbCBvZiB0aGUgbWlzdGFrZSBpbg0KZGVsaXZlcnkuIDxicj4NCk5PVEU6IFJl Z2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gYmlu ZCBDU0MNCnRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8g ZXhwbGljaXQgd3JpdHRlbiBhZ3JlZW1lbnQNCm9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHBy ZXNzbHkgcGVybWl0dGluZyB0aGUgdXNlIG9mIGUtbWFpbCBmb3Igc3VjaA0KcHVycG9zZS48L2Zv bnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTE1JT48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1 ZiBmYWNlPSJzYW5zLXNlcmlmIj5Gcm9tOjwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+DQo8 dGQgd2lkdGg9ODQlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5NYXJjIExpbnNuZXIg Jmx0OzwvZm9udD48YSBocmVmPW1haWx0bzptbGluc25lckBjaXNjby5jb20+PGZvbnQgc2l6ZT0x IGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+bWxpbnNuZXJAY2lzY28uY29tPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZndDs8L2ZvbnQ+PGZvbnQg c2l6ZT0zPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+PGZvbnQgc2l6ZT0xIGNvbG9y PSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+VG86PC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9u dD4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7J2Vjcml0JyZxdW90 OyAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOmVjcml0QGlldGYub3JnPjxmb250IHNpemU9MSBj b2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PmVjcml0QGlldGYub3JnPC91PjwvZm9udD48 L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0z Pg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVm NWYgZmFjZT0ic2Fucy1zZXJpZiI+RGF0ZTo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4wOC8wMy8yMDEwIDAzOjA0IFBNPC9m b250Pjxmb250IHNpemU9Mz4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPjxmb250IHNp emU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPlN1YmplY3Q6PC9mb250Pjxmb250 IHNpemU9Mz4NCjwvZm9udD4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W0Vj cml0XSBkcmFmdC1pZXRmLWVjcml0LWxvY2FsLWVtZXJnZW5jeS1ycGgtbmFtZXNwYWNlPC9mb250 PjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD4NCjxociBub3NoYWRlPjxm b250IHNpemU9Mz48YnI+DQo8YnI+DQo8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj48YnI+DQpBbGws PGJyPg0KPGJyPg0KQXMgeW91IGFsbCBrbm93LCBSUEggbmFtZXNwYWNlIGlzIGFuIEVDUklUIGRy YWZ0IHdpdGhvdXQgYSBtaWxlc3RvbmUuICZuYnNwO0F0PGJyPg0KdGhlIG1lZXRpbmcgbGFzdCB3 ZWVrIFJvYmVydCBTcGFya3MgYW5ub3VuY2VkIGhlIGlzIHdpbGxpbmcgdG8gQUQgc3BvbnNvcjxi cj4NCnRoaXMgZHJhZnQuPGJyPg0KPGJyPg0KUm9iZXJ0IGFza3MgZXZlcnlvbmUgdG8gcmVhZCB0 aGUgZHJhZnQgYW5kIGNvbW1lbnQgb24gaXQgdG8gdGhpcyBsaXN0Ljxicj4NCjxicj4NClRoYW5r cyw8YnI+DQo8YnI+DQotTWFyYy08YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkVjcml0IG1haWxpbmcgbGlzdDwvZm9u dD48L3R0Pjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dT48YnI+DQo8L3U+PC9mb250Pjwv dHQ+PGEgaHJlZj1tYWlsdG86RWNyaXRAaWV0Zi5vcmc+PHR0Pjxmb250IHNpemU9MiBjb2xvcj1i bHVlPjx1PkVjcml0QGlldGYub3JnPC91PjwvZm9udD48L3R0PjwvYT48Zm9udCBzaXplPTMgY29s b3I9Ymx1ZT48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9lY3JpdD48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHU+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwvdT48L2ZvbnQ+PC90dD48 L2E+PGZvbnQgc2l6ZT0zPjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRWNyaXQgbWFpbGluZyBsaXN0PC9mb250Pjxm b250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86 RWNyaXRAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+RWNyaXRAaWV0Zi5vcmc8 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250PjxhIGhyZWY9aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdD48Zm9udCBzaXplPTM+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwvZm9udD48L2E+DQo8YnI+DQo8YnI+ DQo8YnI+DQo= --=_alternative 006A303A85257876_=-- From shida@ntt-at.com Tue Apr 19 19:27:38 2011 Return-Path: X-Original-To: ecrit@ietfc.amsl.com Delivered-To: ecrit@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 531E7E07D9 for ; Tue, 19 Apr 2011 19:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.232 X-Spam-Level: X-Spam-Status: No, score=-102.232 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUXpif2XOxva for ; Tue, 19 Apr 2011 19:27:37 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfc.amsl.com (Postfix) with ESMTP id 39501E0670 for ; Tue, 19 Apr 2011 19:27:37 -0700 (PDT) Received: from [221.170.62.9] (port=60629 helo=[192.168.11.11]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QCN8h-0004OK-8j for ecrit@ietf.org; Tue, 19 Apr 2011 21:27:36 -0500 From: Shida Schubert Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-18-689222653 Date: Wed, 20 Apr 2011 11:27:33 +0900 In-Reply-To: To: ecrit@ietf.org References: Message-Id: X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: flh1ack009.tky.mesh.ad.jp ([192.168.11.11]) [221.170.62.9]:60629 X-Source-Cap: moc.adanga@adihs Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 02:27:38 -0000 --Apple-Mail-18-689222653 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I reviewed the document and followings are some comments/questions.=20 In general, I am having a hard time understanding the intent of the=20 draft. Is it defining a CAP document composition rule (4.2) for = delivering=20 the CAP message from citizen to authority only? OR is it defining a SIP=20= usage to transport CAP message as well? If it's latter I think more = should=20 be said about how SIP entities should behave. I understand it is an=20 experimental document but I think we need to clarify the scope of the=20 document somewhat.=20 1. For scenario 1, I really don't think in reality a sensor will be=20 implementing a SIP stack simply to support the transport of=20 CAP message, it just seems like an overkill. I understand how=20 aggregator to PSAP should be SIP to re-use what is defined=20 in Phone-BCP and pre-exising infrastructure. May be text can=20 be added that some other means may be used to deliver a CAP=20 message from CAP to aggregator. =20 2. I am assuming that any SIP device can use MESSAGE to=20 send CAP to PSAP. If so, some device will be able to handle=20 call-back and some won't. Do we need to distinguish devices=20 that will be issuing the MESSAGE to see whether call-back=20 can be established etc? (I guess PSAP can look at allow header=20 to see if the device can accept INVITE etc.) =20 3. For both cases, should there be any recommendation on how=20 sensor should behave in case 200 OK is not received or error=20 is received from downstream? Again related to the scoping of=20 the document, this may not be necessary if the main intent is=20 to recommend CAP document composition rule.=20 4. If non SIP device is used what should be set in "sender" of CAP?=20 What if the CAP message is sent by a sensor which doesn't support=20= SIP and it is the aggregator that acts as the SIP intermediary and=20= SIP endpoint? 5. Use of P-Asserted-Identity doesn't provide any integrity so I would=20= take it out of section 6.3. 6. Why is RFC3265/RFC3903 a normative reference? I think they=20 should be in an informative reference as there is no normative text=20= surrounding their uses.=20 7. Shouldn't RFC3261(SIP)/RFC3428(MESSAGE)/location-conveyance/ RFC4119(PIDF-LO) be in a normative reference? **Some nits** Section 6:=20 OLD ".. this document and the discussion in.." =20 NEW ".. this document and are discussed in.." Section 6.2 OLD "..alerts and reply them at a later time.." NEW "..alerts and replay them at a later time.." Regards Shida On Mar 30, 2011, at 11:49 PM, Marc Linsner wrote: > This message starts the Working Group Last Call for draft "Common = Alerting Protocol (CAP) based Data-Only Emergency Alerts using the = Session Initiation Protocol (SIP)" = (http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01). >=20 > This draft fulfills the WG milestone: >=20 > Apr 2011 Submit 'Common Alerting Protocol (CAP) based Data-Only = Emergency Alerts using the Session Initiation Protocol (SIP)' >=20 > Please submit comments to the list by COB on Friday April 15, 2011. >=20 > Thanks, >=20 > -Marc Linsner- > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail-18-689222653 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
     What if the CAP message is sent = by a sensor which doesn't support 
     = SIP and it is the aggregator that acts as the SIP intermediary = and 
     SIP = endpoint?

 5. Use of P-Asserted-Identity = doesn't provide any integrity so I would 
   =   take it out of section 6.3.

 6. Why = is RFC3265/RFC3903 a normative reference? I think = they 
     should be in an informative = reference as there is no normative text 
   =   surrounding their uses. 

 7. = Shouldn't = RFC3261(SIP)/RFC3428(MESSAGE)/location-conveyance/
   =   RFC4119(PIDF-LO) be in a = normative reference?


**Some = nits**

  Section = 6: 

  OLD ".. this document and = the discussion in.."
  
  NEW = ".. this document and are discussed = in.."

  Section = 6.2

  OLD "..alerts and reply them at = a later time.."

  NEW "..alerts and = replay them at a later = time.."


Regards
 &n= bsp;Shida

On Mar 30, 2011, at 11:49 PM, = Marc Linsner wrote:

This message = starts the Working Group Last Call for draft "Common Alerting Protocol (CAP) based Data-Only = Emergency Alerts using

the Session = Initiation Protocol (SIP)

" =  (http:= //tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01).
This draft fulfills the WG = milestone:

Apr 2011 Submit 'Common Alerting = Protocol (CAP) based Data-Only Emergency Alerts using the Session = Initiation Protocol (SIP)'

Please submit = comments to the list by COB on Friday April 15, = 2011.
-Marc = Linsner-
_______________________________________________
Ecrit mailing = list
Ecrit@ietf.org
https://www.ietf.org/= mailman/listinfo/ecrit

= --Apple-Mail-18-689222653-- From bernard_aboba@hotmail.com Wed Apr 20 14:55:22 2011 Return-Path: X-Original-To: ecrit@ietfc.amsl.com Delivered-To: ecrit@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9ED24E0738 for ; Wed, 20 Apr 2011 14:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMjkxxMlCKjr for ; Wed, 20 Apr 2011 14:55:20 -0700 (PDT) Received: from blu0-omc3-s11.blu0.hotmail.com (blu0-omc3-s11.blu0.hotmail.com [65.55.116.86]) by ietfc.amsl.com (Postfix) with ESMTP id 1945AE0773 for ; Wed, 20 Apr 2011 14:55:20 -0700 (PDT) Received: from BLU152-W64 ([65.55.116.72]) by blu0-omc3-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Apr 2011 14:55:19 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_1903be30-2a0e-4900-87a6-ab3e344de943_" X-Originating-IP: [72.11.66.126] From: Bernard Aboba To: , Date: Wed, 20 Apr 2011 14:55:19 -0700 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 20 Apr 2011 21:55:19.0628 (UTC) FILETIME=[A3FF10C0:01CBFFA5] Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 21:55:22 -0000 --_1903be30-2a0e-4900-87a6-ab3e344de943_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BA] Overall=2C I echo Shida's comments about potential additional usage scenarios and have a few additional comments about the Security Considerations section.=20 Specific comments below: Abstract The Common Alerting Protocol (CAP) is a document format for exchanging emergency alerts and public warnings. CAP is mainly used for conveying alerts and warnings between authorities and from authorities to citizen/individuals. This document describes how data-only emergency alerts allow devices to issue alerts using the CAP document format. [BA] It seems to me that the use of the term "Data-Only" may not be appropriate to describe all the potential usage scenarios. For example=2C might it also not be possible to include CAP within an INVITE? Suggestion is that the draft be renamed "CAP Emergency Alerts Using SIP"=2C and that the Abstract be changed as follows: The Common Alerting Protocol (CAP) is a document format for exchanging emergency alerts and public warnings. CAP is mainly used for conveying alerts and warnings between authorities and from authorities to citizen/individuals. This document describes how the CAP document format can be used to allow devices to issue emergency alerts. ---------------------------- Data-only emergency alerts are similar to regular emergency calls in the sense that they require emergency call routing functionality and may even have the same location requirements. On the other hand=2C the initial communication interaction will not lead to the establishment of a voice or video channel. [BA] There are a number of potential uses for CAP=2C some of which could no= t be characterized as "Data-only". For example=2C CAP could be included in a= n INVITE which also included an SDP offer. Also an INVITE might be sent without CAP and then when a response was received indicating that MESSAGE was allowed then a CAP alert could subsequently be sent. So I wouldn't necessarily emphasize the "Data-only" aspect. Suggested change: Eergency alerts containing data are similar to regular emergency calls i= n the sense that they require emergency call routing functionality and may even have the same location requirements. On the other hand=2C the communication interaction may occur without establishment of a voice or video channel.=20 ---------------------------- Based on the deployment experience with non-IP based systems we distinguish between two types of environments=2C namely (1) data-only emergency alerts that are targeted directly to a recipient responsible for evaluating the alerts and for taking the necessary steps=2C including triggering an emergency call towards a Public Safety Answering Point (PSAP) and (2) alerts that are targeted to a Service URN as used for regular IP-based emergency calls where the recipient is not known to the originator. We describe these two cases in more detail in Section 3. [BA] The term "emergency call" as opposed to "emergency alert" suggests=20 that the aggregator could potentially convey the CAP message along with=20 establishing non-data channels. My suggestion is to rewrite as follows: Based on the deployment experience with non-IP based systems=2C two major deployment scenarios are envisaged: 1) Emergency alerts containing only data are targeted to a=20 recipient responsible for evaluating the next steps=2C which could include: a. Sending an alert containing only data toward a Public Safety Answering Point (PSAP)=3B b. Establishing an emergency call with a PSAP that could include audio/video as well as data 2) Emergency alerts targeted to a Service URN used for IP-based=20 emergency calls where the recipient is not known to=20 the originator. In this scenario=2C the alert may contain only data (e.g. MESSAGE) or could be included along with establishment of an audio/video channel (e.g. INVITE) We describe these two cases in more detail in Section 3. ---------------------------- Section 3 There is a basic issue in scenario described in Figure 2=2C which is handling of failure conditions. If we assume that the PSAPs do not deploy new capabilities uniformly=2C then the sender may not know beforehand what capabilities the PSAP=20 can support. For example=2C a given PSAP may or may not support MESSAGE= =2C may or may not support CAP or PIDF-LO=2C etc.=20 If at all possible=2C you want to avoid multiple error-terminated conversat= ions between the sender and receiver=2C consuming precious time during an emerge= ncy.=20 This is one argument for "silent call" approaches which utilize a "known good" mechanism for initiating an emergency call (e.g. an INVITE)=2C then follow up with additional messages once the capabilities of the responder are known (e.g. from an Allow: header).=20 ---------------------------- Section 4.1 Alternatively=2C the SIP PUBLISH mechanism or other SIP messages could be used. However=2C the usage of SIP MESSAGE is a simple enough approach from an implementation point of view. [BA] I'm not thrilled with using PUBLISH=2C so I'd remove that but it does occur to me that INVITE would make sense.=20 ---------------------------- Section 5 Via: SIP/2.0/TCP sensor1.domain.com=3Bbranch=3Dz9hG4bK776sgdkse [BA] Use of TCP transport makes sense=2C particularly in scenarios where bo= th CAP and a PIDF-LO might be included. You might consider saying something about= this since TCP transport for MESSAGE is not that common today.=20 ---------------------------- Section 6.1 Does it really make sense to sign the CAP alert when the sender might be a = sensor that may not even by IP-connected=2C and the signer might be an aggregator = with a different identity from the or the identity in the From: field of = the SIP message? If you are going to recommend that=2C you really need to desc= ribe what if anything the receiver can do to validate the signature.=20 ---------------------------- Section 6.2 Additionally=2C it is RECOMMENDED to make use of SIP security mechanisms=2C such as SIP Identity [RFC4474]=2C to tie the CAP messag= e to the SIP message. [BA] Since the sender of the CAP message and the SIP message can be different=2C RFC 4474 only can guarantee that the message isn't modified=3B it doesn't really "tie them together". For example=2C an attacker could snoop on a signed CAP message=2C insert it in a SIP MESSAGE and then use RFC 4474=2C and the sender wouldn't be able to verify that they are unrelated though the sender would be accountable for the mis-behavior.=20 ---------------------------- Section 6.3 For some types of data-only emergency calls author/originator and the receiver/recipient have a relationship with each other and hence it is possible (using cryptographic techniques) to verify whether a message was indeed issued by an authorized entity. Figure 1 is such an environment. Standard SIP security mechanisms can be re-used for this purpose. For example=2C identity based access control is a viable approach utilizing the asserted identity of the alert originator using P-Asserted-Identity [RFC3325] or SIP Identity [RFC4474]. [BA] What is the distinction between "forgery" and "Injecting false alerts"= ?=20 Verifying the identity of the sender of the SIP message may tell you who is accountable for sending the emergency alert=2C but that isn't the same as verifying the authenticity of the alert itself. =20 I might suggest that the threat model focus on the following instead: 1. Prevention of modification of data in transit (e.g. sending MESSAGE over= TLS) 2. Verification of the sender identity (Section 6.3) 3. Signing of alerts (Section 6.1) From: shida@ntt-at.com Date: Wed=2C 20 Apr 2011 11:27:33 +0900 To: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 I reviewed the document and followings are some comments/questions.=20 In general=2C I am having a hard time understanding the intent of the draf= t. Is it defining a CAP document composition rule (4.2) for delivering the = CAP message from citizen to authority only? OR is it defining a SIP usage t= o transport CAP message as well? If it's latter I think more should be said= about how SIP entities should behave. I understand it is an experimental d= ocument but I think we need to clarify the scope of the document somewhat.= =20 1. For scenario 1=2C I really don't think in reality a sensor will be = implementing a SIP stack simply to support the transport of CAP messa= ge=2C it just seems like an overkill. I understand how aggregator to P= SAP should be SIP to re-use what is defined in Phone-BCP and pre-exisi= ng infrastructure. May be text can be added that some other means may = be used to deliver a CAP message from CAP to aggregator. =20 2. I am assuming that any SIP device can use MESSAGE to send CAP to P= SAP. If so=2C some device will be able to handle call-back and some wo= n't. Do we need to distinguish devices that will be issuing the MESSAG= E to see whether call-back can be established etc? (I guess PSAP can = look at allow header to see if the device can accept INVITE etc.) = 3. For both cases=2C should there be any recommendation on how sensor= should behave in case 200 OK is not received or error is received fro= m downstream? Again related to the scoping of the document=2C this may= not be necessary if the main intent is to recommend CAP document comp= osition rule.=20 4. If non SIP device is used what should be set in "sender" of CAP? W= hat if the CAP message is sent by a sensor which doesn't support SIP a= nd it is the aggregator that acts as the SIP intermediary and SIP endp= oint? 5. Use of P-Asserted-Identity doesn't provide any integrity so I would = take it out of section 6.3. 6. Why is RFC3265/RFC3903 a normative reference? I think they should = be in an informative reference as there is no normative text surroundi= ng their uses.=20 7. Shouldn't RFC3261(SIP)/RFC3428(MESSAGE)/location-conveyance/ RFC411= 9(PIDF-LO) be in a normative reference? **Some nits** Section 6:=20 OLD ".. this document and the discussion in.." NEW ".. this document a= nd are discussed in.." Section 6.2 OLD "..alerts and reply them at a later time.." NEW "..alerts and replay them at a later time.." Regards Shida On Mar 30=2C 2011=2C at 11:49 PM=2C Marc Linsner wrote:This message starts = the Working Group Last Call for draft "Common Alerting Protocol (CAP) based= Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)" (= http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01). This draft fulfills the WG milestone: Apr 2011 Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency A= lerts using the Session Initiation Protocol (SIP)' Please submit comments to the list by COB on Friday April 15=2C 2011. Thanks=2C -Marc Linsner- _______________________________________________ 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 = --_1903be30-2a0e-4900-87a6-ab3e344de943_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BA] Overall=2C I echo Shida's comments about potential additional
usage= scenarios and have a few additional comments about the
Security Conside= rations section.

Specific comments below:

Abstract

&n= bsp=3B =3B The Common Alerting Protocol (CAP) is a document format for<= br> =3B =3B exchanging emergency alerts and public warnings. = =3B CAP is mainly used
 =3B =3B for conveying alerts and warning= s between authorities and from
 =3B =3B authorities to citizen/i= ndividuals. =3B This document describes how
 =3B =3B data-on= ly emergency alerts allow devices to issue alerts using the
 =3B&nbs= p=3B CAP document format.

[BA] It seems to me that the use of the te= rm "Data-Only" may not be
appropriate to describe all the potential usag= e scenarios. =3B =3B For
example=2C might it also not be possibl= e to include CAP within an INVITE?
Suggestion is that the draft be renam= ed "CAP Emergency Alerts Using SIP"=2C
and that the Abstract be changed = as follows:

 =3B =3B The Common Alerting Protocol (CAP) is a= document format for
 =3B =3B exchanging emergency alerts and pu= blic warnings. =3B CAP is mainly used
 =3B =3B for conveying= alerts and warnings between authorities and from
 =3B =3B autho= rities to citizen/individuals. =3B This document describes how
 = =3B =3B the CAP document format can be used to allow devices to issue =3B =3B emergency alerts.

----------------------------
 =3B =3B Data-only emergency alerts are similar to regular eme= rgency calls in
 =3B =3B the sense that they require emergency c= all routing functionality and
 =3B =3B may even have the same lo= cation requirements. =3B On the other hand=2C the
 =3B =3B i= nitial communication interaction will not lead to the establishment
&nbs= p=3B =3B of a voice or video channel.

[BA] There are a number of= potential uses for CAP=2C some of which could not
be characterized as "= Data-only". =3B For example=2C CAP could be included in an
INVITE wh= ich also included an SDP offer. =3B Also an INVITE might be sent
wit= hout CAP and then when a response was received indicating that MESSAGE
w= as allowed then a CAP alert could subsequently be sent. =3B So I wouldn= 't
necessarily emphasize the "Data-only" aspect. =3B Suggested chang= e:

 =3B =3B Eergency alerts containing data are similar to r= egular emergency calls in
 =3B =3B the sense that they require e= mergency call routing functionality and
 =3B =3B may even have t= he same location requirements. =3B On the other hand=2C the
 =3B=  =3B communication interaction may occur without establishment
 = =3B =3B of a voice or video channel.

--------------------------= --

 =3B =3B Based on the deployment experience with non-IP b= ased systems we
 =3B =3B distinguish between two types of enviro= nments=2C namely (1) data-only
 =3B =3B emergency alerts that ar= e targeted directly to a recipient
 =3B =3B responsible for eval= uating the alerts and for taking the necessary
 =3B =3B steps=2C= including triggering an emergency call towards a Public Safety
 =3B=  =3B Answering Point (PSAP) and (2) alerts that are targeted to a Servi= ce
 =3B =3B URN as used for regular IP-based emergency calls whe= re the recipient
 =3B =3B is not known to the originator. = =3B We describe these two cases in more
 =3B =3B detail in Secti= on 3.


[BA] The term "emergency call" as opposed to "emergency al= ert" suggests
that the aggregator could potentially convey the CAP mess= age along with
establishing non-data channels. =3B My suggestion is= to rewrite as follows:

 =3B =3B Based on the deployment exp= erience with non-IP based systems=2C two
 =3B =3B major deployme= nt scenarios are envisaged:

 =3B =3B 1) Emergency alerts con= taining only data are targeted to a
 =3B =3B =3B =3B&nb= sp=3B recipient responsible for evaluating the next steps=2C which
 = =3B =3B =3B =3B =3B could include:

 =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B a. Sending an alert contain= ing only data toward a Public
 =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B Safety Answering Point (PSAP= )=3B
 =3B =3B =3B =3B =3B =3B =3B =3B b.= Establishing an emergency call with a PSAP that could
 =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B inc= lude audio/video as well as data

 =3B =3B 2) =3B Emergen= cy alerts targeted to a Service URN used for IP-based
 =3B =3B&= nbsp=3B =3B =3B =3B emergency calls where the recipient is not = known to
 =3B =3B =3B =3B =3B =3B the originato= r. =3B In this scenario=2C the alert may contain
 =3B =3B&nb= sp=3B =3B =3B =3B only data (e.g. MESSAGE) or could be included= along with
 =3B =3B =3B =3B =3B =3B establishme= nt of an audio/video channel (e.g. INVITE)

We describe these two cas= es in more detail in Section 3.

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

= Section 3

There is a basic issue in scenario described in Figure 2= =2C which
is handling of failure conditions.

If we assume that th= e PSAPs do not deploy new capabilities uniformly=2C
then the sender may = not know beforehand what capabilities the PSAP
can support. =3B&nbs= p=3B For example=2C =3B a given PSAP may or may not support MESSAGE=2C<= br>may or may not support CAP or PIDF-LO=2C etc.

If at all possible= =2C you want to avoid multiple error-terminated conversations
between th= e sender and receiver=2C consuming precious time during an emergency.
<= br>This is one argument for "silent call" approaches which utilize a
"kn= own good" mechanism for initiating an emergency call (e.g. an INVITE)=2Cthen follow up with additional messages once the capabilities of
the re= sponder are known (e.g. from an Allow: header).

-------------------= ---------

Section 4.1

 =3B =3B =3B =3B = =3B Alternatively=2C the SIP PUBLISH mechanism or other SIP messages
&nb= sp=3B =3B =3B =3B =3B could be used. =3B However=2C the= usage of SIP MESSAGE is a simple
 =3B =3B =3B =3B = =3B enough approach from an implementation point of view.

[BA] I'm n= ot thrilled with using PUBLISH=2C so I'd remove that but it
does occur t= o me that INVITE would make sense.

----------------------------
=
Section 5

 =3B =3B Via: SIP/2.0/TCP sensor1.domain.com= =3Bbranch=3Dz9hG4bK776sgdkse

[BA] Use of TCP transport makes sense= =2C particularly in scenarios where both CAP
and a PIDF-LO might be incl= uded. =3B You might consider saying something about this
since TCP t= ransport for MESSAGE is not that common today.

--------------------= --------

Section 6.1

Does it really make sense to sign the CA= P alert when the sender might be a sensor
that may not even by IP-connec= ted=2C and the signer might be an aggregator with a
different identity f= rom the <=3Bsender>=3B or the identity in the From: field of the
SIP= message? =3B If you are going to recommend that=2C you really need to = describe
what if anything the receiver can do to validate the signature.=

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

Section 6.2

 =3B&nb= sp=3B =3B =3B =3B Additionally=2C it is RECOMMENDED to make use= of SIP security
 =3B =3B =3B =3B =3B mechanisms=2C = such as SIP Identity [RFC4474]=2C to tie the CAP message
 =3B = =3B =3B =3B =3B to the SIP message.

[BA] Since the sende= r of the CAP message and the SIP message can be
different=2C RFC 4474 on= ly can guarantee that the message isn't modified=3B
it doesn't really "t= ie them together". =3B For example=2C an attacker could
snoop on a s= igned CAP message=2C insert it in a SIP MESSAGE and then
use RFC 4474=2C= and the sender wouldn't be able to verify that they are
unrelated thoug= h the sender would be accountable for the mis-behavior.

-----------= -----------------

Section 6.3

 =3B =3B =3B = =3B =3B For some types of data-only emergency calls author/originator a= nd
 =3B =3B =3B =3B =3B the receiver/recipient have = a relationship with each other and
 =3B =3B =3B =3B = =3B hence it is possible (using cryptographic techniques) to verify
&nbs= p=3B =3B =3B =3B =3B whether a message was indeed issued by= an authorized entity.
 =3B =3B =3B =3B =3B Figure 1= is such an environment. =3B Standard SIP security mechanisms
 = =3B =3B =3B =3B =3B can be re-used for this purpose. = =3B For example=2C identity based
 =3B =3B =3B =3B = =3B access control is a viable approach utilizing the asserted
 =3B&= nbsp=3B =3B =3B =3B identity of the alert originator using P-As= serted-Identity
 =3B =3B =3B =3B =3B [RFC3325] or SI= P Identity [RFC4474].

[BA] What is the distinction between "forgery"= and "Injecting false alerts"?
Verifying the identity of the sender of = the SIP message may tell you who
is accountable for sending the emergenc= y alert=2C but that isn't the same
as verifying the authenticity of the = alert itself. =3B

I might suggest that the threat model focus o= n the following instead:

1. Prevention of modification of data in tr= ansit (e.g. sending MESSAGE over TLS)
2. Verification of the sender iden= tity (Section 6.3)
3. Signing of alerts (Section 6.1)

From: shida@ntt-at.com
Date: Wed=2C 20 Apr 2011 11:27:33 +0= 900
To: ecrit@ietf.org
Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-d= ata-only-ea-01


I reviewed the document and followings are some comments/questions. = =3B

 =3BIn general=2C I am having a hard time = understanding the intent of the =3B
draft. Is it defining a C= AP document composition rule (4.2) for delivering =3B
the&nbs= p=3BCAP message from citizen to authority only? OR is it defining a SIP&nbs= p=3B
usage =3Bto transport CAP message as well? If it's latte= r I think more should =3B
be said about how SIP entities shou= ld behave. I understand it is an =3B
experimental document bu= t I think we need to clarify the scope of the =3B
document so= mewhat. =3B

 =3B1. For scenario 1=2C I rea= lly don't think in reality a sensor will be =3B
 =3B = =3B  =3B implementing a SIP stack simply to support the transport of&nb= sp=3B
 =3B =3B  =3B CAP message=2C it just seems like= an overkill. I understand how =3B
 =3B =3B  =3B = aggregator to PSAP should be SIP to re-use what is defined =3B
 =3B =3B  =3B in Phone-BCP and pre-exising infrastructure. Ma= y be text can =3B
 =3B =3B  =3B be added that som= e other means may be used to deliver a CAP =3B
 =3B = =3B  =3B message from CAP to aggregator.  =3B =3B
 =3B2. I am assuming that any SIP device can use MESSAGE to=  =3B
 =3B =3B  =3B send CAP to PSAP. If so=2C som= e device will be able to handle =3B
 =3B =3B  =3B= call-back and some won't. Do we need to distinguish devices =3B
<= div> =3B =3B  =3B that will be issuing the MESSAGE to see wheth= er call-back =3B
 =3B =3B  =3B can be established= etc?  =3B(I guess PSAP can look at allow header =3B
&nbs= p=3B =3B  =3B to see if the device can accept INVITE etc.)
 =3B =3B  =3B =3B
 =3B3. For both cases=2C = should there be any recommendation on how =3B
 =3B = =3B  =3B sensor should behave in case 200 OK is not received or error&n= bsp=3B
 =3B =3B  =3B is received from downstream? Aga= in related to the scoping of =3B
 =3B =3B  =3B th= e document=2C this may not be necessary if the main intent is =3B
=
 =3B =3B  =3B to recommend CAP document composition rule.&= nbsp=3B

 =3B4. If non SIP device is used what = should be set in "sender" of CAP? =3B
 =3B =3B  = =3B What if the CAP message is sent by a sensor which doesn't support = =3B
 =3B =3B  =3B SIP and it is the aggregator that a= cts as the SIP intermediary and =3B
 =3B =3B  =3B= SIP endpoint?

 =3B5. Use of P-Asserted-Identi= ty doesn't provide any integrity so I would =3B
 =3B = =3B  =3B take it out of section 6.3.

 =3B6= . Why is RFC3265/RFC3903 a normative reference? I think they =3B
<= div> =3B =3B  =3B should be in an informative reference as ther= e is no normative text =3B
 =3B =3B  =3B surround= ing their uses. =3B

 =3B7. Shouldn't RFC32= 61(SIP)/RFC3428(MESSAGE)/location-conveyance/
 =3B =3B &n= bsp=3B RFC4119(PIDF-LO) be in a normative =3Breference?

<= /div>

**Some nits**

 =3B&nb= sp=3BSection 6: =3B

 =3B =3BOLD ".. th= is document and the discussion in.."
 =3B =3B
&= nbsp=3B =3BNEW ".. this document and are discussed in.."

=
 =3B =3BSection 6.2

 =3B&nb= sp=3BOLD "..alerts and reply them at a later time.."

 =3B =3BNEW "..alerts and replay them at a later time.."


Regards
 =3B =3BShida

On Mar 30=2C 2011=2C at 11:49 PM=2C Marc Linsne= r wrote:

This message starts the Working Group Last Call for dra= ft "Common Alerting Protocol (CAP)= based Data-Only Emergency Alerts using

the Session Initiation Protoc= ol (SIP)

"  =3B(http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01).

This draft fulfills the WG milestone:

Apr 2011 Submit 'Common Alerting Protocol (CAP) based Data= -Only Emergency Alerts using the Session Initiation Protocol (SIP)'

Please submit comments to the list by COB on Friday April 15=2C 2011.
Thanks=2C

-Marc Linsner-
_______________________________________________
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 = --_1903be30-2a0e-4900-87a6-ab3e344de943_-- From wwwrun@rfc-editor.org Wed Apr 20 22:14:50 2011 Return-Path: X-Original-To: ecrit@ietfc.amsl.com Delivered-To: ecrit@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E506CE0791; Wed, 20 Apr 2011 22:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-GEoPwM1xeM; Wed, 20 Apr 2011 22:14:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfc.amsl.com (Postfix) with ESMTP id 3E9C4E07D1; Wed, 20 Apr 2011 22:14:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 66ED4E077E; Wed, 20 Apr 2011 22:14:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110421051449.66ED4E077E@rfc-editor.org> Date: Wed, 20 Apr 2011 22:14:49 -0700 (PDT) Cc: ecrit@ietf.org, rfc-editor@rfc-editor.org Subject: [Ecrit] RFC 6197 on Location-to-Service Translation (LoST) Service List Boundary Extension X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 05:14:51 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6197 Title: Location-to-Service Translation (LoST) Service List Boundary Extension Author: K. Wolf Status: Experimental Stream: IETF Date: April 2011 Mailbox: karlheinz.wolf@nic.at Pages: 15 Characters: 27562 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ecrit-lost-servicelistboundary-05.txt URL: http://www.rfc-editor.org/rfc/rfc6197.txt Location-to-Service Translation (LoST) maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a query to the LoST server. However, the LoST server, in its response, does not provide context information; that is, it does not provide any additional information about the geographical region within which the returned list of services is considered valid. Therefore, this document defines a Service List Boundary that returns a local context along with the list of services returned, in order to assist the client in not missing a change in available services when moving. This document defines an Experimental Protocol for the Internet community. This document is a product of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From trac+ecrit@trac.tools.ietf.org Thu Apr 21 15:57:59 2011 Return-Path: X-Original-To: ecrit@ietfc.amsl.com Delivered-To: ecrit@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9DC2EE06E6 for ; Thu, 21 Apr 2011 15:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgOF61Mw0oFb for ; Thu, 21 Apr 2011 15:57:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 48C35E0695 for ; Thu, 21 Apr 2011 15:57:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QD2ov-0007bp-Bf; Thu, 21 Apr 2011 15:57:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ecrit issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 21 Apr 2011 22:57:57 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/ecrit/trac/ticket/5 Message-ID: <065.174dd4cfe726ec1c2fd905c874335760@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Fri, 22 Apr 2011 11:52:45 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] [ecrit] #5: Review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 22:57:59 -0000 #5: Review [BA] Overall, I echo Shida's comments about potential additional usage scenarios and have a few additional comments about the Security Considerations section. Specific comments below: Abstract The Common Alerting Protocol (CAP) is a document format for exchanging emergency alerts and public warnings. CAP is mainly used for conveying alerts and warnings between authorities and from authorities to citizen/individuals. This document describes how data-only emergency alerts allow devices to issue alerts using the CAP document format. [BA] It seems to me that the use of the term "Data-Only" may not be appropriate to describe all the potential usage scenarios. For example, might it also not be possible to include CAP within an INVITE? Suggestion is that the draft be renamed "CAP Emergency Alerts Using SIP", and that the Abstract be changed as follows: The Common Alerting Protocol (CAP) is a document format for exchanging emergency alerts and public warnings. CAP is mainly used for conveying alerts and warnings between authorities and from authorities to citizen/individuals. This document describes how the CAP document format can be used to allow devices to issue emergency alerts. ---------------------------- Data-only emergency alerts are similar to regular emergency calls in the sense that they require emergency call routing functionality and may even have the same location requirements. On the other hand, the initial communication interaction will not lead to the establishment of a voice or video channel. [BA] There are a number of potential uses for CAP, some of which could not be characterized as "Data-only". For example, CAP could be included in an INVITE which also included an SDP offer. Also an INVITE might be sent without CAP and then when a response was received indicating that MESSAGE was allowed then a CAP alert could subsequently be sent. So I wouldn't necessarily emphasize the "Data-only" aspect. Suggested change: Eergency alerts containing data are similar to regular emergency calls in the sense that they require emergency call routing functionality and may even have the same location requirements. On the other hand, the communication interaction may occur without establishment of a voice or video channel. ---------------------------- Based on the deployment experience with non-IP based systems we distinguish between two types of environments, namely (1) data-only emergency alerts that are targeted directly to a recipient responsible for evaluating the alerts and for taking the necessary steps, including triggering an emergency call towards a Public Safety Answering Point (PSAP) and (2) alerts that are targeted to a Service URN as used for regular IP-based emergency calls where the recipient is not known to the originator. We describe these two cases in more detail in Section 3. [BA] The term "emergency call" as opposed to "emergency alert" suggests that the aggregator could potentially convey the CAP message along with establishing non-data channels. My suggestion is to rewrite as follows: Based on the deployment experience with non-IP based systems, two major deployment scenarios are envisaged: 1) Emergency alerts containing only data are targeted to a recipient responsible for evaluating the next steps, which could include: a. Sending an alert containing only data toward a Public Safety Answering Point (PSAP); b. Establishing an emergency call with a PSAP that could include audio/video as well as data 2) Emergency alerts targeted to a Service URN used for IP-based emergency calls where the recipient is not known to the originator. In this scenario, the alert may contain only data (e.g. MESSAGE) or could be included along with establishment of an audio/video channel (e.g. INVITE) We describe these two cases in more detail in Section 3. ---------------------------- Section 3 There is a basic issue in scenario described in Figure 2, which is handling of failure conditions. If we assume that the PSAPs do not deploy new capabilities uniformly, then the sender may not know beforehand what capabilities the PSAP can support. For example, a given PSAP may or may not support MESSAGE, may or may not support CAP or PIDF-LO, etc. If at all possible, you want to avoid multiple error-terminated conversations between the sender and receiver, consuming precious time during an emergency. This is one argument for "silent call" approaches which utilize a "known good" mechanism for initiating an emergency call (e.g. an INVITE), then follow up with additional messages once the capabilities of the responder are known (e.g. from an Allow: header). ---------------------------- Section 4.1 Alternatively, the SIP PUBLISH mechanism or other SIP messages could be used. However, the usage of SIP MESSAGE is a simple enough approach from an implementation point of view. [BA] I'm not thrilled with using PUBLISH, so I'd remove that but it does occur to me that INVITE would make sense. ---------------------------- Section 5 Via: SIP/2.0/TCP sensor1.domain.com;branch=z9hG4bK776sgdkse [BA] Use of TCP transport makes sense, particularly in scenarios where both CAP and a PIDF-LO might be included. You might consider saying something about this since TCP transport for MESSAGE is not that common today. ---------------------------- Section 6.1 Does it really make sense to sign the CAP alert when the sender might be a sensor that may not even by IP-connected, and the signer might be an aggregator with a different identity from the or the identity in the From: field of the SIP message? If you are going to recommend that, you really need to describe what if anything the receiver can do to validate the signature. ---------------------------- Section 6.2 Additionally, it is RECOMMENDED to make use of SIP security mechanisms, such as SIP Identity [RFC4474], to tie the CAP message to the SIP message. [BA] Since the sender of the CAP message and the SIP message can be different, RFC 4474 only can guarantee that the message isn't modified; it doesn't really "tie them together". For example, an attacker could snoop on a signed CAP message, insert it in a SIP MESSAGE and then use RFC 4474, and the sender wouldn't be able to verify that they are unrelated though the sender would be accountable for the mis-behavior. ---------------------------- Section 6.3 For some types of data-only emergency calls author/originator and the receiver/recipient have a relationship with each other and hence it is possible (using cryptographic techniques) to verify whether a message was indeed issued by an authorized entity. Figure 1 is such an environment. Standard SIP security mechanisms can be re-used for this purpose. For example, identity based access control is a viable approach utilizing the asserted identity of the alert originator using P-Asserted-Identity [RFC3325] or SIP Identity [RFC4474]. [BA] What is the distinction between "forgery" and "Injecting false alerts"? Verifying the identity of the sender of the SIP message may tell you who is accountable for sending the emergency alert, but that isn't the same as verifying the authenticity of the alert itself. I might suggest that the threat model focus on the following instead: 1. Prevention of modification of data in transit (e.g. sending MESSAGE over TLS) 2. Verification of the sender identity (Section 6.3) 3. Signing of alerts (Section 6.1) -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: additional-data | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Thu Apr 21 15:59:46 2011 Return-Path: X-Original-To: ecrit@ietfc.amsl.com Delivered-To: ecrit@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 79333E06B9 for ; Thu, 21 Apr 2011 15:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-BpkPRo+srd for ; Thu, 21 Apr 2011 15:59:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 96D0AE0695 for ; Thu, 21 Apr 2011 15:59:45 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QD2qf-0007ch-61; Thu, 21 Apr 2011 15:59:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ecrit issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 21 Apr 2011 22:59:45 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/ecrit/trac/ticket/6 Message-ID: <065.a8032252d43271617f6cbe101c7fb927@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Fri, 22 Apr 2011 11:52:45 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] [ecrit] #6: Shida's comments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 22:59:46 -0000 #6: Shida's comments From: shida at ntt-at.com Date: Wed, 20 Apr 2011 11:27:33 +0900 To: ecrit at ietf.org Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 I reviewed the document and followings are some comments/questions. In general, I am having a hard time understanding the intent of the draft. Is it defining a CAP document composition rule (4.2) for delivering the CAP message from citizen to authority only? OR is it defining a SIP usage to transport CAP message as well? If it's latter I think more should be said about how SIP entities should behave. I understand it is an experimental document but I think we need to clarify the scope of the document somewhat. 1. For scenario 1, I really don't think in reality a sensor will be implementing a SIP stack simply to support the transport of CAP message, it just seems like an overkill. I understand how aggregator to PSAP should be SIP to re-use what is defined in Phone-BCP and pre-exising infrastructure. May be text can be added that some other means may be used to deliver a CAP message from CAP to aggregator. 2. I am assuming that any SIP device can use MESSAGE to send CAP to PSAP. If so, some device will be able to handle call-back and some won't. Do we need to distinguish devices that will be issuing the MESSAGE to see whether call-back can be established etc? (I guess PSAP can look at allow header to see if the device can accept INVITE etc.) 3. For both cases, should there be any recommendation on how sensor should behave in case 200 OK is not received or error is received from downstream? Again related to the scoping of the document, this may not be necessary if the main intent is to recommend CAP document composition rule. 4. If non SIP device is used what should be set in "sender" of CAP? What if the CAP message is sent by a sensor which doesn't support SIP and it is the aggregator that acts as the SIP intermediary and SIP endpoint? 5. Use of P-Asserted-Identity doesn't provide any integrity so I would take it out of section 6.3. 6. Why is RFC3265/RFC3903 a normative reference? I think they should be in an informative reference as there is no normative text surrounding their uses. 7. Shouldn't RFC3261(SIP)/RFC3428(MESSAGE)/location-conveyance/ RFC4119(PIDF-LO) be in a normative reference? **Some nits** Section 6: OLD ".. this document and the discussion in.." NEW ".. this document and are discussed in.." Section 6.2 OLD "..alerts and reply them at a later time.." NEW "..alerts and replay them at a later time.." Regards Shida -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: data-only-ea | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Thu Apr 21 16:00:15 2011 Return-Path: X-Original-To: ecrit@ietfc.amsl.com Delivered-To: ecrit@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EDD95E06B9 for ; Thu, 21 Apr 2011 16:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OikiruL3GYU3 for ; Thu, 21 Apr 2011 16:00:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id CC9D6E0695 for ; Thu, 21 Apr 2011 16:00:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QD2r8-0000uD-Cz; Thu, 21 Apr 2011 16:00:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ecrit issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 21 Apr 2011 23:00:14 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/ecrit/trac/ticket/5#comment:1 Message-ID: <074.935efb0de8fafd58d21f37f7123f6240@trac.tools.ietf.org> References: <065.174dd4cfe726ec1c2fd905c874335760@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <065.174dd4cfe726ec1c2fd905c874335760@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Fri, 22 Apr 2011 11:52:45 -0700 Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #5: Review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 23:00:16 -0000 #5: Review Changes (by bernard_aboba@…): * component: additional-data => data-only-ea -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: data-only-ea | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: ecrit From dromasca@avaya.com Thu Apr 28 03:12:30 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3B2E073A; Thu, 28 Apr 2011 03:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNq5rYXyJlaq; Thu, 28 Apr 2011 03:12:29 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5FDE0739; Thu, 28 Apr 2011 03:12:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMBAM08uU3GmAcF/2dsb2JhbACYEI1ud4hwnyYCmkuFdgSTDIlb X-IronPort-AV: E=Sophos;i="4.64,279,1301889600"; d="scan'208";a="186072033" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 28 Apr 2011 06:12:27 -0400 X-IronPort-AV: E=Sophos;i="4.64,279,1301889600"; d="scan'208";a="613818451" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Apr 2011 06:12:26 -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, 28 Apr 2011 12:12:25 +0200 Message-ID: In-Reply-To: <8BEBE8CA-9CAC-404F-8E04-1A9732E25242@brianrosen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: (with DISCUSS and COMMENT) Thread-Index: AcwFPoflAr0/jF92S6ieZaMFfhppHAATF8Gw References: <20110427124143.8317.20417.idtracker@ietfa.amsl.com> <8BEBE8CA-9CAC-404F-8E04-1A9732E25242@brianrosen.net> From: "Romascanu, Dan (Dan)" To: "Brian Rosen" Cc: ecrit-chairs@tools.ietf.org, draft-ietf-ecrit-phonebcp@tools.ietf.org, The IESG , ecrit@ietf.org Subject: Re: [Ecrit] Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 10:12:30 -0000 Hi,=20 See in-line.=20 Thanks and Regards, Dan=20 =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Thursday, April 28, 2011 3:52 AM > To: Romascanu, Dan (Dan) > Cc: The IESG; ecrit-chairs@tools.ietf.org;=20 > draft-ietf-ecrit-phonebcp@tools.ietf.org; ecrit@ietf.org Org > Subject: Re: Dan Romascanu's Discuss on=20 > draft-ietf-ecrit-phonebcp-17: (with DISCUSS and COMMENT) >=20 > Please see inline for my responses to this: > On Apr 27, 2011, at 8:41 AM, Dan Romascanu wrote: >=20 > >=20 > > Part of the issues in the DISCUSS were raised in Bernard=20 > Aboba's OPS-DIR review. I recommend all his review to be=20 > addressed. I included in my DISCUSS those issues that seemed=20 > to me critical.=20 > >=20 > > 1. A number of the recommendations made would appear to assume an=20 > > all-IP NG911 "NENA i3" architecture, as opposed to the "NENA i2"=20 > > transitional architecture. In those cases, the=20 > recommendations would=20 > > represent "Best Future Practice" rather than "Best Current=20 > Practice". > We have tried to base our BCP on other IETF BCPs. Of course,=20 > there is wide variation. This document represents what we=20 > think devices should do going forward. The IETF has no=20 > document type called "Best Future Practice". >=20 I know :-)=20 The solution is IMO clarifying the language and especially which one of the environments (all-IP) the requirements relate to.=20 > >=20 > > In a number of cases normative language appears to be used in ways=20 > > different from those described in RFC 2119. In some cases,=20 > the term=20 > > "SHOULD" is used in situations where statutes or=20 > regulations may mandate behavior. > We believe this to be the best choice. It's MUST except in=20 > specified circumstances. The circumstances are when=20 > regulations say otherwise. It would be good to clarify this in the document.=20 >=20 > > =20 > >=20 > > I agree here with Bernard that the BCP status is probably=20 > adequate, but in some places the requirements need clarification.=20 > >=20 > > Bernard also writes:=20 > >=20 > > Overall, I was left with the question as to whether the=20 > > recommendations in this document applied beyond "all-IP" > > deployments based on the framework document, to=20 > transitional "NENA i2"=20 > > environments as well. I suspect that the "INT" > > requirements would also apply to gateways between IP and=20 > legacy PSAPs,=20 > > but this isn't stated explicitly. > This is not intended to be a transition document. Transition=20 > needs to be considered in the context of current, nation=20 > specific emergency services. i2 is U.S. specific, and major=20 > changes were made in the Canadian version and are proposed in=20 > the British version of how VoIP is supported in their current=20 > TDM based systems. We believe therefore that the IETF is not=20 > the appropriate venue for a transition document. If the view is that this document is targeting an all IP environment - this needs to be made clear. >=20 > >=20 > > I also find odd the fact that the document does not refer=20 > at least informationaly to the NENA i2 and i3 architectures.=20 > The behavior of the system and requirements may be different=20 > in i2 and i3 environments. There are places where behavior=20 > should be configurable or negotiated to allow for better=20 > behavior in a transitional environment. There are also places=20 > where behavior will be prescribed by local statues or=20 > regulations, so that configuration and/or negotiation is a=20 > practical requirement. > It would be inappropriate to refer to i2 and i3 in -phonebcp.=20 Why? It's not about the specific North-American regulatory aspects, it's about the fact that the document targets an all-IP architecture which is associated to i3 for everybody who deals with emergency.=20 > I do think we could refer to it in -framework however, and=20 > we will draft a paragraph that does that. >=20 > >=20 > > 2. I had a hard time translating some of the AN (Access=20 > Networks related) requirements. For example:=20 > >=20 > > AN-5 Access networks supporting copper, fiber or other=20 > hard wired IP > > packet service SHOULD support location configuration. If=20 > the network > > does not support location configuration, it MUST require=20 > every device > > that connects to the network to support end system=20 > measured location. > >=20 > > If I am an operator of an AN that does not support location=20 > configuration how should I read the requirement? Is this an=20 > administrative requirement, or should the network be designed=20 > so that devices that do not support end system measured=20 > location (and have it activated?) cannot connect to the network?=20 > I think it's very clear. You have a choice - implement an=20 > LCP or require all devices on your net to support end system=20 > measured location. HOW you do that is up to you. It's=20 > access network specific. It may very well be L2 specific. >=20 I am still confused. Is this an administrative requirement? Users of access networks assume that they have access at basic emergency services when connecting to the network. Will the access provider tell them 'no such service unless the device supports end system measured location' and sign him contractually on this?=20 > >=20 > > 3. ED-3 is confusing. I think that it tries to state that=20 > string recognition MUST be supported and that the endpoints=20 > SHOULD provide this function, but if this is not the case the=20 > SP MAY do it. If I am correct than this needs to be an ED/SP=20 > requirement, and I would like the cases of exception to be=20 > clarified. If I mis-understood please help me understand,=20 > maybe with some text changes.=20 > You understand it correctly. SP-7 is the requirement on the=20 > SP. While we could combine this, I personally think it makes=20 > more sense as it is. >=20 > >=20 > > 4. Section 17.2:=20 > >=20 > >> The > > registration process is Expert review by ECRIT working group, its > > successor, or, in their absence, the IESG. =20 > >=20 > > I suggest to define this policy as Expert Review as per RFC=20 > 5226 and have a Designated Expert nominated. The designated=20 > expert can than use help from ECRIT, IESG, or other in the future.=20 > We will do this >=20 > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > COMMENT: > >=20 > ---------------------------------------------------------------------- > >=20 > > I support Pete's part of the DISCUSS that states that section 12=20 > > points to a security hole that needs to be addressed > We agree. We will have to do something for this >=20 > >=20 >=20 >=20 From rbarnes@bbn.com Thu Apr 28 04:50:36 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD598E06E5; Thu, 28 Apr 2011 04:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eI-bbgJ+I6Ye; Thu, 28 Apr 2011 04:50:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1D939E068D; Thu, 28 Apr 2011 04:50:36 -0700 (PDT) Received: from [128.89.253.235] (port=62699 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QFPjt-000Kzq-6e; Thu, 28 Apr 2011 07:50:33 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4DB93DAA.5070408@cs.tcd.ie> Date: Thu, 28 Apr 2011 07:50:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110427020138.5421.87853.idtracker@ietfa.amsl.com> <5B3D3910-8AC2-4410-940A-D68F94498BE6@brianrosen.net> <4DB93DAA.5070408@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1082) Cc: ecrit-chairs@tools.ietf.org, draft-ietf-ecrit-framework@tools.ietf.org, The IESG , "ecrit@ietf.org Org" Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-framework-12: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 11:50:36 -0000 Hey Stephen, Couple of points inline below. >>> (1) Section 3 says: "a caller must obtain his location...prior to = making >>> emergency calls." That seems overstated - if I can't find my = location=20 >>> are you saying that the call can't happen? (A "should" would be = right >>> here I think.) >> This is in an overview section, it's not MUST and it's properly = qualified later. Anyone in emergency services will tell you that the = three most important things about emergency calling are location, = location and location (which is a U.S. specific reference to a joke = about real estate) >> We usually get all these rules must this, must that, and when you = enquire what happens when something fails and you can't follow the = rules, you find they take them and deal with them. >>=20 >> I'd prefer not to change it in the document, but of course we can (to = should). >=20 > Well, I think must just isn't correct, even though this isn't 2119 > language so some other wording is needed. I'd be fine with "really > should" or anything that's accurate. I agree that we're sort of arguing style/taste here. But I did want to = emphasize that location actually is *really* important for this process. = This whole document is about how you do urgent, location-based call = routing. In order for an emergency call to work, somebody needs to know the = caller's location, either the caller himself or his VoIP provider. In = general, the latter case is infeasible; the only case where that really = happens is for carrier-provided VoIP services, like the Comcast "digital = voice" service that they sell alongside their Internet service. For = all other VoIP services in all other classes of network, the end device = needs to do the location bits, because it's the only device that talks = to both the access network (for location) and VoIP system (for call = delivery). Given that location is such an important thing that so often has to be = done by the end device, it seems to me that saying "must" here sets the = proper context for the reader. >>> (2) Is MESSAGE/MSRP the right IM choice to make for emergencies? = Would >>> xmpp be more likely to be useful? (Just checking.) >> We've considered xmpp. We would have to extend xmpp in several ways, = and then extend framework and phonebcp in ways compatible with the = extensions. Absent the extensions in at least draft form, we'll = probably update -framework and -phonebcp later. >=20 > Fair enough. >=20 >>> (3) How would any of this work with p2psip? (Just checking again.) >> Same as above, but fall back to sip is something p2psip devices do. >=20 > Not sure I understand quite. Are you saying that a p2psip device > where the user has no account with a service provider can still > make an emergency call by following this framework and the phonebcp? > I'd have thought that a sentence is needed somewhere about that. There are two key parts to the framework: (1) Figuring out where to send a call, and=20 (2) Sending the call to the PSAP The first part is not dependent on SIP at all -- you can plug in any URI = you want into LoST, including XMPP. I've done demos using the "wave:" = URI scheme to allow PSAPs to invite emergency callers to join a Google = Wave collaboration space. The second part can also in principle be done over any protocol, but = there are some features that you lose relative to this document. In = particular, this document embeds the caller's geolocation in the call = signaling, and marks the call as an emergency call. So if you were to = use XMPP, you would lose these features, but still be able to talk to a = PSAP. If you were to use P2PSIP, I think the main challenge would be = making sure that the call marking would not interfere with call routing = -- I think in principle it shouldn't, but I don't know the P2PSIP specs = very well. =20 Hope this helps, --Richard From stephen.farrell@cs.tcd.ie Thu Apr 28 03:13:01 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFC6E0721; Thu, 28 Apr 2011 03:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVW+-SHHX95n; Thu, 28 Apr 2011 03:13:01 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id B0EFDE06D6; Thu, 28 Apr 2011 03:13:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 27D42171C21; Thu, 28 Apr 2011 11:13:00 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1303985579; bh=eUb7mYN2P/qx3t EJY01h0VJW8fYKz5NDA1R0NGjNFVI=; b=G9A+mNdfjPxzEB6gI1frxvXAcNBxJI TWWrHZCZHaLWmQke53KGxkkvgi6wkFb02kKMsfIisVrjGBKM2WsAho1VZuvy3KE1 cn02+nK+HQSrzWR9SiSKXRnOl9AJ915gPBh/dykSwmhFGeTQ2hYFmSFnu0vqrveK +zVVJFKBJwkbGgLQxuSkFuMBU63qzUnPadZJdfSFW8UpItr0gDwZYTwZjtVMYod7 wS3jtth0HyX4nJZqe2r09R6W2fH8/sa5Rl0xB1YSzrmSS08JJX9p8fLDLdOhUO/Z 9PqLgLjSZvPGfa1bW99nrpEJ9oqr8L/dq+cTkxLFrKppxHlTmuPPXGLQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Es4RSwcXaZ-G; Thu, 28 Apr 2011 11:12:59 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 14002171BFA; Thu, 28 Apr 2011 11:12:58 +0100 (IST) Message-ID: <4DB93DAA.5070408@cs.tcd.ie> Date: Thu, 28 Apr 2011 11:12:58 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Brian Rosen References: <20110427020138.5421.87853.idtracker@ietfa.amsl.com> <5B3D3910-8AC2-4410-940A-D68F94498BE6@brianrosen.net> In-Reply-To: <5B3D3910-8AC2-4410-940A-D68F94498BE6@brianrosen.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Apr 2011 05:22:33 -0700 Cc: ecrit-chairs@tools.ietf.org, The IESG , "ecrit@ietf.org Org" , draft-ietf-ecrit-framework@tools.ietf.org Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-framework-12: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 10:13:01 -0000 On 28/04/11 02:45, Brian Rosen wrote: > Please see my responses inline for the DISCUSS portion > > On Apr 26, 2011, at 10:01 PM, Stephen Farrell wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-ecrit-framework-12: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> (1) Section 3 says: "a caller must obtain his location...prior to making >> emergency calls." That seems overstated - if I can't find my location >> are you saying that the call can't happen? (A "should" would be right >> here I think.) > This is in an overview section, it's not MUST and it's properly qualified later. Anyone in emergency services will tell you that the three most important things about emergency calling are location, location and location (which is a U.S. specific reference to a joke about real estate) > We usually get all these rules must this, must that, and when you enquire what happens when something fails and you can't follow the rules, you find they take them and deal with them. > > I'd prefer not to change it in the document, but of course we can (to should). Well, I think must just isn't correct, even though this isn't 2119 language so some other wording is needed. I'd be fine with "really should" or anything that's accurate. >> (2) Is MESSAGE/MSRP the right IM choice to make for emergencies? Would >> xmpp be more likely to be useful? (Just checking.) > We've considered xmpp. We would have to extend xmpp in several ways, and then extend framework and phonebcp in ways compatible with the extensions. Absent the extensions in at least draft form, we'll probably update -framework and -phonebcp later. Fair enough. >> (3) How would any of this work with p2psip? (Just checking again.) > Same as above, but fall back to sip is something p2psip devices do. Not sure I understand quite. Are you saying that a p2psip device where the user has no account with a service provider can still make an emergency call by following this framework and the phonebcp? I'd have thought that a sentence is needed somewhere about that. Thanks, S. > >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> (1) I support Sean's discuss wrt IPR and LC processes. I'm also unclear >> how IPR that affects this informational document would not affect the >> phonebcp document but who knows with these things. >> >> (2) Intro: "there are currently no international standards" - doesn't 112 >> qualify as an international standard for an existing emergency call system? >> Then: "However, the Internet crosses national boundaries, and thus >> international standards for equipment and software are required." Don't you >> mean that Internet standards are required? >> >> > From stephen.farrell@cs.tcd.ie Thu Apr 28 05:11:19 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8354EE06A5; Thu, 28 Apr 2011 05:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYAm96Imcbxz; Thu, 28 Apr 2011 05:11:18 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 562C0E068F; Thu, 28 Apr 2011 05:11:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 117D4171C1F; Thu, 28 Apr 2011 13:11:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1303992676; bh=IzLeXj6sWhnbVv h8Q9Fh/y83zGHBGWQwAYMu0rEcfoA=; b=3/mUnFLbtV9l7lWoLa7fD3jj8A8OF1 +JGuUIz7rgJg9o4Gsq4sr82IQnasMxYFSaacvOfnzvpGNKepXYqmj8Vr7EfgTTUP DNQ7ApKQlEJfkikHe8kkjhP0AbjgekJaXuUHtwKtTlItv4MfIbVmoN3b0pNX9etC WVlWHY952WIrVf3zygWj+/586tZoTlZeqqhTtYLToLl0POWHrhLZWdNtTyKrulLp LbDyzGFGKAzfJI4KKKADD8i5pNO7DFLJI/XFFqH9waws4liShXfV9qAgvj5gA9U3 DLGRVKexCTCbOou40ovc2k7CyKJtuJQZtvhqsI0chjuhGmGS9XRaIUXw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ADsDJtNi7l8J; Thu, 28 Apr 2011 13:11:16 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 79641171C08; Thu, 28 Apr 2011 13:11:15 +0100 (IST) Message-ID: <4DB95963.2080908@cs.tcd.ie> Date: Thu, 28 Apr 2011 13:11:15 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Richard L. Barnes" References: <20110427020138.5421.87853.idtracker@ietfa.amsl.com> <5B3D3910-8AC2-4410-940A-D68F94498BE6@brianrosen.net> <4DB93DAA.5070408@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Apr 2011 05:22:33 -0700 Cc: ecrit-chairs@tools.ietf.org, draft-ietf-ecrit-framework@tools.ietf.org, "ecrit@ietf.org Org" , The IESG Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-framework-12: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 12:11:19 -0000 Hi Richard, On 28/04/11 12:50, Richard L. Barnes wrote: > Hey Stephen, > > Couple of points inline below. > >>>> (1) Section 3 says: "a caller must obtain his location...prior to making >>>> emergency calls." That seems overstated - if I can't find my location >>>> are you saying that the call can't happen? (A "should" would be right >>>> here I think.) >>> This is in an overview section, it's not MUST and it's properly qualified later. Anyone in emergency services will tell you that the three most important things about emergency calling are location, location and location (which is a U.S. specific reference to a joke about real estate) >>> We usually get all these rules must this, must that, and when you enquire what happens when something fails and you can't follow the rules, you find they take them and deal with them. >>> >>> I'd prefer not to change it in the document, but of course we can (to should). >> >> Well, I think must just isn't correct, even though this isn't 2119 >> language so some other wording is needed. I'd be fine with "really >> should" or anything that's accurate. > > I agree that we're sort of arguing style/taste here. Disagree. I think that "must" is misleading here. > But I did want to emphasize that location actually is *really* important for this process. This whole document is about how you do urgent, location-based call routing. > > In order for an emergency call to work, somebody needs to know the caller's location, either the caller himself or his VoIP provider. In general, the latter case is infeasible; the only case where that really happens is for carrier-provided VoIP services, like the Comcast "digital voice" service that they sell alongside their Internet service. For all other VoIP services in all other classes of network, the end device needs to do the location bits, because it's the only device that talks to both the access network (for location) and VoIP system (for call delivery). > > Given that location is such an important thing that so often has to be done by the end device, it seems to me that saying "must" here sets the proper context for the reader. I understand what you're saying. How about if it said that devices must be able to do this and should actually do it, which'd be something like: "a caller's device must be able to, and should, obtain..." >>>> (2) Is MESSAGE/MSRP the right IM choice to make for emergencies? Would >>>> xmpp be more likely to be useful? (Just checking.) >>> We've considered xmpp. We would have to extend xmpp in several ways, and then extend framework and phonebcp in ways compatible with the extensions. Absent the extensions in at least draft form, we'll probably update -framework and -phonebcp later. >> >> Fair enough. >> >>>> (3) How would any of this work with p2psip? (Just checking again.) >>> Same as above, but fall back to sip is something p2psip devices do. >> >> Not sure I understand quite. Are you saying that a p2psip device >> where the user has no account with a service provider can still >> make an emergency call by following this framework and the phonebcp? >> I'd have thought that a sentence is needed somewhere about that. > > There are two key parts to the framework: > (1) Figuring out where to send a call, and > (2) Sending the call to the PSAP > > The first part is not dependent on SIP at all -- you can plug in any URI you want into LoST, including XMPP. I've done demos using the "wave:" URI scheme to allow PSAPs to invite emergency callers to join a Google Wave collaboration space. > > The second part can also in principle be done over any protocol, but there are some features that you lose relative to this document. In particular, this document embeds the caller's geolocation in the call signaling, and marks the call as an emergency call. So if you were to use XMPP, you would lose these features, but still be able to talk to a PSAP. If you were to use P2PSIP, I think the main challenge would be making sure that the call marking would not interfere with call routing -- I think in principle it shouldn't, but I don't know the P2PSIP specs very well. A sentence that just said that p2psip isn't covered here would be fine from my p-o-v. Given that this is largely about SIP, and p2psip exists, I think that'd be helpful to the reader who could otherwise be mislead. I'm not asking that this framework say how to handle emergency calling in p2psip if that's not a well-known thing. (I'm not sure how that'd best be worded though sorry.) S. > > Hope this helps, > --Richard > > > > > > From stephen.farrell@cs.tcd.ie Thu Apr 28 06:17:24 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80866E0685; Thu, 28 Apr 2011 06:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69Cduuf1BUD0; Thu, 28 Apr 2011 06:17:22 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id E6F1BE0669; Thu, 28 Apr 2011 06:17:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B7992171C1A; Thu, 28 Apr 2011 14:17:20 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1303996640; bh=dSJxkLJPMriTJw ymbrKAxtIAYOYC1wbTGZ1y2S+G5yo=; b=dYTnW5Sb3nnHKsrVDRMofK2BUuYLwh +UuFmMby8A+WzHQoxM6UTi7bd6Ag8J+cU5LKExcTOZvslwM3+6yZZEpRsotMHrLD ogr7WRguSbUsSVvlkfI12A1yVTRW9efeyZxRSWVFXD1ZIwxA6gdVLO2T+E9rB996 xOpx5h0zj18DrlT/h7O+w2bUTbvSWLa+dudHZZ8GPyQNKpo+KW8foJrDeXkdVtIx h2otWVI/fmWQz93NzHf4C2fURTDoIDOfjlvjIV1pc1AH79ECuEo48sgKfYofRB41 Ifa/JS64lAT5PtGT3twHpcLXxZJ2kQC3xHiucFrmXghE2WVQ5JSuvjMA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id H84QmAdxQUQp; Thu, 28 Apr 2011 14:17:20 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6B5CD171C08; Thu, 28 Apr 2011 14:17:19 +0100 (IST) Message-ID: <4DB968DE.4000906@cs.tcd.ie> Date: Thu, 28 Apr 2011 14:17:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Brian Rosen References: <20110427020138.5421.87853.idtracker@ietfa.amsl.com> <5B3D3910-8AC2-4410-940A-D68F94498BE6@brianrosen.net> <4DB93DAA.5070408@cs.tcd.ie> <491FA96C-F437-43FB-B6C8-E3891BF618C0@brianrosen.net> In-Reply-To: <491FA96C-F437-43FB-B6C8-E3891BF618C0@brianrosen.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Apr 2011 07:03:56 -0700 Cc: ecrit-chairs@tools.ietf.org, The IESG , "ecrit@ietf.org Org" , draft-ietf-ecrit-framework@tools.ietf.org Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-framework-12: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 13:17:24 -0000 On 28/04/11 14:12, Brian Rosen wrote: >>>> (3) How would any of this work with p2psip? (Just checking again.) >>> Same as above, but fall back to sip is something p2psip devices do. >> >> Not sure I understand quite. Are you saying that a p2psip device >> where the user has no account with a service provider can still >> make an emergency call by following this framework and the phonebcp? >> I'd have thought that a sentence is needed somewhere about that. > Let's just leave it the same as xmpp. We would need to extend p2psip to deal with LoST, and when we do that (really after we do that) we can extend -framework and -phonebcp. I don't want to divert either p2psip from finishing RELOAD, or divert ecrit to deal with p2psip and make -phonebcp dependent on reload base. To be clear - I'm not asking anyone to do anything other than say that this doc doesn't cover p2psip, which I think would be worthwhile. S. From turners@ieca.com Thu Apr 28 06:23:43 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B799BE0669 for ; Thu, 28 Apr 2011 06:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6hCDG8cb2Pd for ; Thu, 28 Apr 2011 06:23:43 -0700 (PDT) Received: from nm13-vm0.bullet.mail.sp2.yahoo.com (nm13-vm0.bullet.mail.sp2.yahoo.com [98.139.91.244]) by ietfa.amsl.com (Postfix) with SMTP id 0F0F7E0663 for ; Thu, 28 Apr 2011 06:23:43 -0700 (PDT) Received: from [98.139.91.65] by nm13.bullet.mail.sp2.yahoo.com with NNFMP; 28 Apr 2011 13:23:43 -0000 Received: from [98.139.91.12] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 28 Apr 2011 13:23:43 -0000 Received: from [127.0.0.1] by omp1012.mail.sp2.yahoo.com with NNFMP; 28 Apr 2011 13:23:42 -0000 X-Yahoo-Newman-Id: 993257.15108.bm@omp1012.mail.sp2.yahoo.com Received: (qmail 53267 invoked from network); 28 Apr 2011 13:23:42 -0000 Received: from thunderfish.local (turners@96.231.128.87 with plain) by smtp113.biz.mail.sp1.yahoo.com with SMTP; 28 Apr 2011 06:23:41 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: eXRghoIVM1lWnNV20c23V7t1GbT_UsPNgMfS1XBmx00xp7H ua3FQMU4ngdgG4nvJgRvowYWFNkTFlbyHTJ49ukqfc.1L3gBMJZOkck9c3rY q.dRttUjGExcbeWkveVxfD5cDyZRwcfmvCF3PKNBa45_O0SrHGRpqL_ftcJ. IDfB395zv0exZtxnCr3j7pp9KGDRICRS.tpv7zWd7VaBh7mSQGhMH7ckaCbx 2uaaTrsRFsgM_tVb5lNd2f1dwCdYHoM_VdvWrY7z3M39qZpzheuGzevE2419 GvonKfEhoFGO_bUKPDYpXfNFJ21SaR9aKh91s6w.kvQmLHTiQi_ydxZO6vFz BN04Eg1GK7j93bDZaa.e6mWeKvByUKiy.ONnYaLhU X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DB96A5B.2090100@ieca.com> Date: Thu, 28 Apr 2011 09:23:39 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brian Rosen References: <20110427161005.8104.78165.idtracker@ietfa.amsl.com> <14EBC61F-348C-4587-B4F7-23869089B736@brianrosen.net> In-Reply-To: <14EBC61F-348C-4587-B4F7-23869089B736@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Apr 2011 07:03:56 -0700 Cc: ecrit-chairs@tools.ietf.org, draft-ietf-ecrit-phonebcp@tools.ietf.org, The IESG , "ecrit@ietf.org Org" Subject: Re: [Ecrit] Sean Turner's Discuss on draft-ietf-ecrit-phonebcp-17: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 13:23:43 -0000 On 4/27/11 9:15 PM, Brian Rosen wrote: > See inline for my responses > > On Apr 27, 2011, at 12:10 PM, Sean Turner wrote: > >> Sean Turner has entered the following ballot position for >> draft-ietf-ecrit-phonebcp-17: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This is an updated discuss. >> >> Section 6.1: For the 1st paragraph which entity is the requirement on? All the other requirements statements are targeted at an entity or entities. > I get the point. It might be a bit difficult to word, but I'll take a shot at it. It applies to any entity that gets location from somewhere other than a mechanism that delivers a PIDF. > >> >> ED-74 made me wonder whether there should be a statement that if the endpoints support video it should remain on? > I'm not aware of anything approaching silence suppression with video. Motion sensing? Even something like blanking the video when you detected silence doesn't work at all. > > Before we have a requirement, it would be nice if we had a real problem. I would propose that we not do anything. Fair enough. I'll update the discuss to nix this bit. Thanks, spt From Martin.Dawson@commscope.com Thu Apr 28 19:05:43 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974F4E0731; Thu, 28 Apr 2011 19:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVCc-90vuXAT; Thu, 28 Apr 2011 19:05:42 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 9A43FE0715; Thu, 28 Apr 2011 19:05:42 -0700 (PDT) X-AuditID: 0a0404e9-b7b57ae00000256b-7b-4dba1cf69bd3 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id BF.39.09579.6FC1ABD4; Thu, 28 Apr 2011 21:05:42 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 28 Apr 2011 21:05:41 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 29 Apr 2011 10:05:36 +0800 From: "Dawson, Martin" To: Stephen Farrell , "Richard L. Barnes" Date: Fri, 29 Apr 2011 10:05:34 +0800 Thread-Topic: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-framework-12: (with DISCUSS and COMMENT) Thread-Index: AcwFnvqXoJUopwg7RrG3Z0Z2Ldg94wAcpSug Message-ID: <8B0A9FCBB9832F43971E38010638454F040474FA2F@SISPE7MB1.commscope.com> References: <20110427020138.5421.87853.idtracker@ietfa.amsl.com> <5B3D3910-8AC2-4410-940A-D68F94498BE6@brianrosen.net> <4DB93DAA.5070408@cs.tcd.ie> <4DB95963.2080908@cs.tcd.ie> In-Reply-To: <4DB95963.2080908@cs.tcd.ie> 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-Brightmail-Tracker: AAAAAA== Cc: The IESG , "ecrit-chairs@tools.ietf.org" , "draft-ietf-ecrit-framework@tools.ietf.org" , "ecrit@ietf.org Org" Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-framework-12: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 02:05:43 -0000 > I understand what you're saying. How about if it said that devices must b= e able to do this and should actually do it, which'd be something like: > > "a caller's device must be able to, and should, obtain..." I think that's more in the right spirit. To tighten it further it could be: "...must be able and attempt to obtain..." - after that it's a matter of di= stinguishing what it must do if it succeeds in getting location and should = do if it did not. Regards, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of S= tephen Farrell Sent: Thursday, 28 April 2011 10:11 PM To: Richard L. Barnes Cc: ecrit-chairs@tools.ietf.org; draft-ietf-ecrit-framework@tools.ietf.org;= ecrit@ietf.org Org; The IESG Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-framewor= k-12: (with DISCUSS and COMMENT) Hi Richard, On 28/04/11 12:50, Richard L. Barnes wrote: > Hey Stephen, >=20 > Couple of points inline below. >=20 >>>> (1) Section 3 says: "a caller must obtain his location...prior to maki= ng >>>> emergency calls." That seems overstated - if I can't find my location= =20 >>>> are you saying that the call can't happen? (A "should" would be right >>>> here I think.) >>> This is in an overview section, it's not MUST and it's properly qualifi= ed later. Anyone in emergency services will tell you that the three most i= mportant things about emergency calling are location, location and location= (which is a U.S. specific reference to a joke about real estate) >>> We usually get all these rules must this, must that, and when you enqui= re what happens when something fails and you can't follow the rules, you fi= nd they take them and deal with them. >>> >>> I'd prefer not to change it in the document, but of course we can (to s= hould). >> >> Well, I think must just isn't correct, even though this isn't 2119 >> language so some other wording is needed. I'd be fine with "really >> should" or anything that's accurate. >=20 > I agree that we're sort of arguing style/taste here. =20 Disagree. I think that "must" is misleading here. > But I did want to emphasize that location actually is *really* important for this process. This whole document is about how you do urgent, location-based call routing. >=20 > In order for an emergency call to work, somebody needs to know the caller= 's location, either the caller himself or his VoIP provider. In general, t= he latter case is infeasible; the only case where that really happens is fo= r carrier-provided VoIP services, like the Comcast "digital voice" service = that they sell alongside their Internet service. For all other VoIP servi= ces in all other classes of network, the end device needs to do the locatio= n bits, because it's the only device that talks to both the access network = (for location) and VoIP system (for call delivery). >=20 > Given that location is such an important thing that so often has to be do= ne by the end device, it seems to me that saying "must" here sets the prope= r context for the reader. I understand what you're saying. How about if it said that devices must be able to do this and should actually do it, which'd be something like: "a caller's device must be able to, and should, obtain..." >>>> (2) Is MESSAGE/MSRP the right IM choice to make for emergencies? Would >>>> xmpp be more likely to be useful? (Just checking.) >>> We've considered xmpp. We would have to extend xmpp in several ways, a= nd then extend framework and phonebcp in ways compatible with the extension= s. Absent the extensions in at least draft form, we'll probably update -fr= amework and -phonebcp later. >> >> Fair enough. >> >>>> (3) How would any of this work with p2psip? (Just checking again.) >>> Same as above, but fall back to sip is something p2psip devices do. >> >> Not sure I understand quite. Are you saying that a p2psip device >> where the user has no account with a service provider can still >> make an emergency call by following this framework and the phonebcp? >> I'd have thought that a sentence is needed somewhere about that. >=20 > There are two key parts to the framework: > (1) Figuring out where to send a call, and=20 > (2) Sending the call to the PSAP >=20 > The first part is not dependent on SIP at all -- you can plug in any URI = you want into LoST, including XMPP. I've done demos using the "wave:" URI = scheme to allow PSAPs to invite emergency callers to join a Google Wave col= laboration space. >=20 > The second part can also in principle be done over any protocol, but ther= e are some features that you lose relative to this document. In particular= , this document embeds the caller's geolocation in the call signaling, and = marks the call as an emergency call. So if you were to use XMPP, you would= lose these features, but still be able to talk to a PSAP. If you were to = use P2PSIP, I think the main challenge would be making sure that the call m= arking would not interfere with call routing -- I think in principle it sho= uldn't, but I don't know the P2PSIP specs very well. =20 A sentence that just said that p2psip isn't covered here would be fine from my p-o-v. Given that this is largely about SIP, and p2psip exists, I think that'd be helpful to the reader who could otherwise be mislead. I'm not asking that this framework say how to handle emergency calling in p2psip if that's not a well-known thing. (I'm not sure how that'd best be worded though sorry.) S. >=20 > Hope this helps, > --Richard >=20 >=20 >=20 >=20 >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit