From rbarnes@bbn.com Tue Feb 14 14:58:06 2012 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 9630F21F869C for ; Tue, 14 Feb 2012 14:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.502 X-Spam-Level: X-Spam-Status: No, score=-106.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2HTyXrSZd9X for ; Tue, 14 Feb 2012 14:58:05 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 352C621F861A for ; Tue, 14 Feb 2012 14:57:31 -0800 (PST) Received: from [128.89.255.13] (port=61256) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RxRJS-0000GZ-EF for ecrit@ietf.org; Tue, 14 Feb 2012 17:57:30 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Richard Barnes In-Reply-To: Date: Tue, 14 Feb 2012 17:57:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8740CFE2-7987-4313-B6D4-989779B5D05C@bbn.com> References: To: "ecrit@ietf.org Org" X-Mailer: Apple Mail (2.1251.1) Subject: Re: [Ecrit] Adding top-level service labels 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: Tue, 14 Feb 2012 22:58:06 -0000 Dear WG, There has been little response to this proposal from Andrea. In = discussions with the ADs, the chairs have concluded that if this = document progresses, it will have to be through the working group. So = we would like to issue a consensus call for whether the WG should take = this document on as a WG item. =20 Please send comments to the list no later than 21 Feb 2012. Thanks, Richard and Marc On Dec 19, 2011, at 4:16 PM, Andrea G. Forte wrote: > Dear all, >=20 > Recently, the LoST Extensions draft has been ratified as RFC 6451. = This > means that people can start using LoST for non-emergency services. > Furthermore, Telecom Italia (the first Italian mobile carrier) has > contacted us for knowing the status of the service classification = draft as > they were interested in working in that area. >=20 > We think that times have matured enough to resume our discussion on > non-emergency location-based services. However, given that this is the > ECRIT working group, I wanted to bring to the group's attention the = draft > on service URN update policy > [http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy-00]. >=20 > As a reminder, this draft would update "Section 4.1 of [RFC5031] in = that > the policy for adding top-level service labels is "Expert Review". = The > expert is designated by the RAI Area Director". Today standard action = is > required for this, which is a significant overkill to just add "food" = or > "lodging". I do not see any harm in introducing this change in policy = but > I would like to know the opinion of the WG. >=20 > Thanks, > -- Andrea G. Forte >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From martin.thomson@gmail.com Tue Feb 14 15:19:56 2012 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 44F4121F8723 for ; Tue, 14 Feb 2012 15:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.841 X-Spam-Level: X-Spam-Status: No, score=-4.841 tagged_above=-999 required=5 tests=[AWL=-1.242, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rrfslminavvo for ; Tue, 14 Feb 2012 15:19:55 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6960D21F8718 for ; Tue, 14 Feb 2012 15:19:51 -0800 (PST) Received: by bkuw12 with SMTP id w12so498308bku.31 for ; Tue, 14 Feb 2012 15:19:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qczNvyAGKD7vT4WHmEWYHJOOUGfWMGFyPe9c8w8ayPE=; b=MB6zys/Qj/uKxHffuycBVQx3jAbyfegrRPJxf02a9nFhxjrLGwsHefMvgqpEtsWxTt ZvMJOPLVjk8OrjU+21tf9jNQM6ir/w/0z/O3uGHeQQePGExZqM9PwkVWdn6tmukLacMu DG7HZ+gqf5VGivAq0rcuo0ue4nf+GGU7P0OEk= MIME-Version: 1.0 Received: by 10.204.151.77 with SMTP id b13mr10656963bkw.57.1329261590522; Tue, 14 Feb 2012 15:19:50 -0800 (PST) Received: by 10.204.241.81 with HTTP; Tue, 14 Feb 2012 15:19:50 -0800 (PST) In-Reply-To: <8740CFE2-7987-4313-B6D4-989779B5D05C@bbn.com> References: <8740CFE2-7987-4313-B6D4-989779B5D05C@bbn.com> Date: Tue, 14 Feb 2012 15:19:50 -0800 Message-ID: From: Martin Thomson To: Richard Barnes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Adding top-level service labels 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: Tue, 14 Feb 2012 23:19:56 -0000 I have no problem with opening registration. In the interests of democratization of the space, is there anything prohibiting someone from using an http: URI to identify a service? The only reason that you want some portion of the urn:service: space is for interoperability. The only other stricture is global uniqueness. --Martin On 14 February 2012 14:57, Richard Barnes wrote: > Dear WG, > > There has been little response to this proposal from Andrea. =C2=A0In dis= cussions with the ADs, the chairs have concluded that if this document prog= resses, it will have to be through the working group. =C2=A0So we would lik= e to issue a consensus call for whether the WG should take this document on= as a WG item. > > Please send comments to the list no later than 21 Feb 2012. > > Thanks, > Richard and Marc > > > On Dec 19, 2011, at 4:16 PM, Andrea G. Forte wrote: > >> Dear all, >> >> Recently, the LoST Extensions draft has been ratified as RFC 6451. This >> means that people can start using LoST for non-emergency services. >> Furthermore, Telecom Italia (the first Italian mobile carrier) has >> contacted us for knowing the status of the service classification draft = as >> they were interested in working in that area. >> >> We think that times have matured enough to resume our discussion on >> non-emergency location-based services. However, given that this is the >> ECRIT working group, I wanted to bring to the group's attention the draf= t >> on service URN update policy >> [http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy-00]. >> >> As a reminder, this draft would update "Section 4.1 of [RFC5031] in that >> the policy for adding top-level service labels is "Expert Review". =C2= =A0The >> expert is designated by the RAI Area Director". Today standard action is >> required for this, which is a significant overkill to just add "food" or >> "lodging". I do not see any harm in introducing this change in policy bu= t >> I would like to know the opinion of the WG. >> >> Thanks, >> -- Andrea G. Forte >> >> >> >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Tue Feb 14 15:28:32 2012 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 956AA21E810B for ; Tue, 14 Feb 2012 15:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.506 X-Spam-Level: X-Spam-Status: No, score=-106.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJEdh1iGq-9L for ; Tue, 14 Feb 2012 15:28:31 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C0D2B21E80E3 for ; Tue, 14 Feb 2012 15:28:30 -0800 (PST) Received: from [128.89.255.13] (port=61340) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RxRnS-0005Hz-0H; Tue, 14 Feb 2012 18:28:30 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: Date: Tue, 14 Feb 2012 18:28:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <33E147B1-D7EF-47A5-A181-752CD299E2AC@bbn.com> References: <8740CFE2-7987-4313-B6D4-989779B5D05C@bbn.com> To: Martin Thomson X-Mailer: Apple Mail (2.1251.1) Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Adding top-level service labels 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: Tue, 14 Feb 2012 23:28:32 -0000 Well, RFC 5222 does frequently refer to "service URNs", e.g.: " 1. If the requested service, identified by the service URN [9] in the element of the request, exists for the location indicated, then the LoST server copies the service URN from the request into the element. " (Reference [9] is RFC 5031.) So while it wouldn't necessarily cause the schema validator to choke, I = wouldn't be surprised if there were implementors that read the document = to imply that only "urn:service:*" names would appear in the = field. =20 But I like your idea for extensibility better, and would like the above = to be proven wrong... --Richard On Feb 14, 2012, at 6:19 PM, Martin Thomson wrote: > I have no problem with opening registration. >=20 > In the interests of democratization of the space, is there anything > prohibiting someone from using an http: URI to identify a service? > The only reason that you want some portion of the urn:service: space > is for interoperability. The only other stricture is global > uniqueness. >=20 > --Martin >=20 > On 14 February 2012 14:57, Richard Barnes wrote: >> Dear WG, >>=20 >> There has been little response to this proposal from Andrea. In = discussions with the ADs, the chairs have concluded that if this = document progresses, it will have to be through the working group. So = we would like to issue a consensus call for whether the WG should take = this document on as a WG item. >>=20 >> Please send comments to the list no later than 21 Feb 2012. >>=20 >> Thanks, >> Richard and Marc >>=20 >>=20 >> On Dec 19, 2011, at 4:16 PM, Andrea G. Forte wrote: >>=20 >>> Dear all, >>>=20 >>> Recently, the LoST Extensions draft has been ratified as RFC 6451. = This >>> means that people can start using LoST for non-emergency services. >>> Furthermore, Telecom Italia (the first Italian mobile carrier) has >>> contacted us for knowing the status of the service classification = draft as >>> they were interested in working in that area. >>>=20 >>> We think that times have matured enough to resume our discussion on >>> non-emergency location-based services. However, given that this is = the >>> ECRIT working group, I wanted to bring to the group's attention the = draft >>> on service URN update policy >>> = [http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy-00]. >>>=20 >>> As a reminder, this draft would update "Section 4.1 of [RFC5031] in = that >>> the policy for adding top-level service labels is "Expert Review". = The >>> expert is designated by the RAI Area Director". Today standard = action is >>> required for this, which is a significant overkill to just add = "food" or >>> "lodging". I do not see any harm in introducing this change in = policy but >>> I would like to know the opinion of the WG. >>>=20 >>> Thanks, >>> -- Andrea G. Forte >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit From ted.ietf@gmail.com Tue Feb 14 15:28:57 2012 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 419D821E80E3 for ; Tue, 14 Feb 2012 15:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.689 X-Spam-Level: X-Spam-Status: No, score=-3.689 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bl-ukQ1EhZf for ; Tue, 14 Feb 2012 15:28:56 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 490EC21E807F for ; Tue, 14 Feb 2012 15:28:56 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so430213vbb.31 for ; Tue, 14 Feb 2012 15:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gKU/Ws9cY+x0xsrcK94SLnP0xz208CSghkJzUqJcgXQ=; b=EbdH9kHMjDupBfspFJ4Bif4A+KaeKh1vXaAlyuITPX6s0yQ1VNrVSlavYd2FNzP8IC 9/6dBLKA1puufwUikkCoCJfh2p2Nni0SV5SqdnQNxQbZAscU5nNGt5jgloX4MGZZEC/+ szZymIe+HAXgEx6MVux2ggMIFfMQpDfdIwJB8= MIME-Version: 1.0 Received: by 10.52.91.196 with SMTP id cg4mr10039009vdb.68.1329262135854; Tue, 14 Feb 2012 15:28:55 -0800 (PST) Received: by 10.52.31.68 with HTTP; Tue, 14 Feb 2012 15:28:55 -0800 (PST) In-Reply-To: References: <8740CFE2-7987-4313-B6D4-989779B5D05C@bbn.com> Date: Tue, 14 Feb 2012 15:28:55 -0800 Message-ID: From: Ted Hardie To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Adding top-level service labels 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: Tue, 14 Feb 2012 23:28:57 -0000 On Tue, Feb 14, 2012 at 3:19 PM, Martin Thomson wrote: > I have no problem with opening registration. > > In the interests of democratization of the space, is there anything > prohibiting someone from using an http: URI to identify a service? > The only reason that you want some portion of the urn:service: space > is for interoperability. =A0The only other stricture is global > uniqueness. RFC 6451 says it is compatible with RFC 5222, which specifies service URNs; I think if it were to relax from a managed namespace to any URI (or even HTTP URIs), then I think you'd need to update at least 6451, and maybe 5222. If you don't want interoperablity, you could use a UUID, with a mapping known only to the application. But I suspect the value is in some intersection of interoperablity, human readability, and uniqueness. regards, Ted > > --Martin > > On 14 February 2012 14:57, Richard Barnes wrote: >> Dear WG, >> >> There has been little response to this proposal from Andrea. =A0In discu= ssions with the ADs, the chairs have concluded that if this document progre= sses, it will have to be through the working group. =A0So we would like to = issue a consensus call for whether the WG should take this document on as a= WG item. >> >> Please send comments to the list no later than 21 Feb 2012. >> >> Thanks, >> Richard and Marc >> >> >> On Dec 19, 2011, at 4:16 PM, Andrea G. Forte wrote: >> >>> Dear all, >>> >>> Recently, the LoST Extensions draft has been ratified as RFC 6451. This >>> means that people can start using LoST for non-emergency services. >>> Furthermore, Telecom Italia (the first Italian mobile carrier) has >>> contacted us for knowing the status of the service classification draft= as >>> they were interested in working in that area. >>> >>> We think that times have matured enough to resume our discussion on >>> non-emergency location-based services. However, given that this is the >>> ECRIT working group, I wanted to bring to the group's attention the dra= ft >>> on service URN update policy >>> [http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy-00]. >>> >>> As a reminder, this draft would update "Section 4.1 of [RFC5031] in tha= t >>> the policy for adding top-level service labels is "Expert Review". =A0T= he >>> expert is designated by the RAI Area Director". Today standard action i= s >>> required for this, which is a significant overkill to just add "food" o= r >>> "lodging". I do not see any harm in introducing this change in policy b= ut >>> I would like to know the opinion of the WG. >>> >>> Thanks, >>> -- Andrea G. Forte >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Tue Feb 14 15:31:43 2012 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 9EB5721E8130 for ; Tue, 14 Feb 2012 15:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.925 X-Spam-Level: X-Spam-Status: No, score=-101.925 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NCcLlCDFFIp for ; Tue, 14 Feb 2012 15:31:41 -0800 (PST) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 64FF021E812F for ; Tue, 14 Feb 2012 15:31:41 -0800 (PST) X-ASG-Debug-ID: 1329262297-04d0356c7345630001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id M6OyfjzsI9DbIW4C; Tue, 14 Feb 2012 15:31:37 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.75]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RxRqU-003oaZ-DH; Tue, 14 Feb 2012 15:31:38 -0800 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [Ecrit] Adding top-level service labels Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Tue, 14 Feb 2012 18:31:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <706A1B33-E4B7-4A4C-9D5C-DAFB1C12A3B3@brianrosen.net> References: <8740CFE2-7987-4313-B6D4-989779B5D05C@bbn.com> To: Martin Thomson X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1329262297 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.88564 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Adding top-level service labels 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: Tue, 14 Feb 2012 23:31:43 -0000 On this subject, let me note that NENA has a urn namespace (urn:nena), = in which it has defined urn:nena:service, in which it has several urns = defined which are intended to be used with LoST inside an Emergency = Services IP Network. We will, for example, route a call to the correct = police department with one of them. Since it's in private networks, and = not in the urn:service namespace, there is no need to ask the IETF to do = anything, and of course it is in the realm of emergency services. = However, it's illustrative of not needing standards track to get more = services. Brian On Feb 14, 2012, at 6:19 PM, Martin Thomson wrote: > I have no problem with opening registration. >=20 > In the interests of democratization of the space, is there anything > prohibiting someone from using an http: URI to identify a service? > The only reason that you want some portion of the urn:service: space > is for interoperability. The only other stricture is global > uniqueness. >=20 > --Martin >=20 > On 14 February 2012 14:57, Richard Barnes wrote: >> Dear WG, >>=20 >> There has been little response to this proposal from Andrea. In = discussions with the ADs, the chairs have concluded that if this = document progresses, it will have to be through the working group. So = we would like to issue a consensus call for whether the WG should take = this document on as a WG item. >>=20 >> Please send comments to the list no later than 21 Feb 2012. >>=20 >> Thanks, >> Richard and Marc >>=20 >>=20 >> On Dec 19, 2011, at 4:16 PM, Andrea G. Forte wrote: >>=20 >>> Dear all, >>>=20 >>> Recently, the LoST Extensions draft has been ratified as RFC 6451. = This >>> means that people can start using LoST for non-emergency services. >>> Furthermore, Telecom Italia (the first Italian mobile carrier) has >>> contacted us for knowing the status of the service classification = draft as >>> they were interested in working in that area. >>>=20 >>> We think that times have matured enough to resume our discussion on >>> non-emergency location-based services. However, given that this is = the >>> ECRIT working group, I wanted to bring to the group's attention the = draft >>> on service URN update policy >>> = [http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy-00]. >>>=20 >>> As a reminder, this draft would update "Section 4.1 of [RFC5031] in = that >>> the policy for adding top-level service labels is "Expert Review". = The >>> expert is designated by the RAI Area Director". Today standard = action is >>> required for this, which is a significant overkill to just add = "food" or >>> "lodging". I do not see any harm in introducing this change in = policy but >>> I would like to know the opinion of the WG. >>>=20 >>> Thanks, >>> -- Andrea G. Forte >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From ted.ietf@gmail.com Tue Feb 14 15:31:57 2012 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 CD9B321E813B for ; Tue, 14 Feb 2012 15:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.687 X-Spam-Level: X-Spam-Status: No, score=-3.687 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIMHS8EpZDJ1 for ; Tue, 14 Feb 2012 15:31:57 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4465721E813A for ; Tue, 14 Feb 2012 15:31:57 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so427263vcb.31 for ; Tue, 14 Feb 2012 15:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=sNohWbbTrDz26aBiMnV40vK+a7qGFXMOn2L8H8TF+uU=; b=wYHBrs8yeTRRfb60LySThRzW5FbvZ/qYFM/ouvyDFOoP/Q40Xl1x5npFpekAcviFbI WLzKRYHrgso8WmYRDSv9HMy2DChiiay08oTJNNr5PoCyx1Usvl/ZVmOEPvYHTssjV6t3 8u5BeVdfvaCP/aec7bSbBWIjGs1fOAFxmDsrc= MIME-Version: 1.0 Received: by 10.220.148.196 with SMTP id q4mr11886139vcv.42.1329262316715; Tue, 14 Feb 2012 15:31:56 -0800 (PST) Received: by 10.52.31.68 with HTTP; Tue, 14 Feb 2012 15:31:56 -0800 (PST) In-Reply-To: <33E147B1-D7EF-47A5-A181-752CD299E2AC@bbn.com> References: <8740CFE2-7987-4313-B6D4-989779B5D05C@bbn.com> <33E147B1-D7EF-47A5-A181-752CD299E2AC@bbn.com> Date: Tue, 14 Feb 2012 15:31:56 -0800 Message-ID: From: Ted Hardie To: Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Adding top-level service labels 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: Tue, 14 Feb 2012 23:31:57 -0000 On Tue, Feb 14, 2012 at 3:28 PM, Richard Barnes wrote: > > > Well, RFC 5222 does frequently refer to "service URNs", e.g.: > " > =A0 1. =A0If the requested service, identified by the service URN [9] in > =A0 =A0 =A0 the element of the request, exists for the location > =A0 =A0 =A0 indicated, then the LoST server copies the service URN from t= he > =A0 =A0 =A0 request into the element. > " > (Reference [9] is RFC 5031.) > > So while it wouldn't necessarily cause the schema validator to choke, I w= ouldn't be surprised if there were implementors that read the document to i= mply that only "urn:service:*" names would appear in the field. > > But I like your idea for extensibility better, and would like the above t= o be proven wrong... > I think there is a huge rat hole down the "are HTTP URIs which depend on the domain name system stable enough or not". The rats down there are friendly enough, as people don't visit them that much any more, but that means they'll want to discuss it ad naseum if not infinitum. I'd say that creating a tree under the service tree that does not require standards action is easy enough, even if you don't want to change it for the whole tree: Ted From martin.thomson@gmail.com Tue Feb 14 16:59:35 2012 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 6EACA21F8747 for ; Tue, 14 Feb 2012 16:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.793 X-Spam-Level: X-Spam-Status: No, score=-4.793 tagged_above=-999 required=5 tests=[AWL=-1.194, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTIvR2054AGz for ; Tue, 14 Feb 2012 16:59:34 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 682E821F8743 for ; Tue, 14 Feb 2012 16:59:33 -0800 (PST) Received: by bkuw12 with SMTP id w12so542686bku.31 for ; Tue, 14 Feb 2012 16:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=70FuMT8S2mGOeZ+q3wZKCORbYlKH9Nxm+dp1f9mueRw=; b=pohuxRFW1v6eSxXZARZ/7v6XbSW7gHPhLluQCpItjfTE3Fzdh2DdSFmYTzGj0XvwmU 9Iczlpk0cmOmzzIiEgBFz9b9sj49VtaBZcZQKJgATwY4tSaB1bs6MSGVqGNxK+fpoQsn xZSk4Fd8dJOtSQm2TVOUIQ7NOxaaHMgLtGJJg= MIME-Version: 1.0 Received: by 10.204.10.86 with SMTP id o22mr10797847bko.111.1329267572542; Tue, 14 Feb 2012 16:59:32 -0800 (PST) Received: by 10.204.241.81 with HTTP; Tue, 14 Feb 2012 16:59:32 -0800 (PST) In-Reply-To: References: <8740CFE2-7987-4313-B6D4-989779B5D05C@bbn.com> <33E147B1-D7EF-47A5-A181-752CD299E2AC@bbn.com> Date: Tue, 14 Feb 2012 16:59:32 -0800 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Adding top-level service labels 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, 15 Feb 2012 00:59:35 -0000 Ted Hardie wrote: > [...] RFC 5222, which specifies service URN [...] It's tempting to suggest that "urn:" scheme URIs don't have a monopoly on Unique Resource Names and risk an interoperability failure. Anyone sufficiently motivated could update the requisite RFCs, but my risk analysis suggests that that energy might be better saved against the outside chance that a fire breaks out. From ted.ietf@gmail.com Wed Feb 15 10:39:45 2012 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 1437B21E8027 for ; Wed, 15 Feb 2012 10:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.684 X-Spam-Level: X-Spam-Status: No, score=-3.684 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yF55BsFjMWXw for ; Wed, 15 Feb 2012 10:39:44 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC7021E805B for ; Wed, 15 Feb 2012 10:39:43 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so1092954vcb.31 for ; Wed, 15 Feb 2012 10:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R29pSCaSJlhY3xhTWfTukEhgIqKlMqORNrOS+Z9UdA4=; b=p/aBlAJaI80pUldb5KEz/NFUJ1oVMWP+G0rDNRvVprtfHWgAMeA04L53bOmDf4smYD TNkd0Qn6QJuYchQtuFyNUMGnC1nKMj+h9M9cqUyTbr61HWrumUuYDEX+MBV0BSbDOdWf 21JiWLbD8xS1bomp4WK/Alw1bPQXZqMGgXmgA= MIME-Version: 1.0 Received: by 10.52.91.196 with SMTP id cg4mr11543279vdb.68.1329331183621; Wed, 15 Feb 2012 10:39:43 -0800 (PST) Received: by 10.52.31.68 with HTTP; Wed, 15 Feb 2012 10:39:43 -0800 (PST) In-Reply-To: References: <8740CFE2-7987-4313-B6D4-989779B5D05C@bbn.com> <33E147B1-D7EF-47A5-A181-752CD299E2AC@bbn.com> Date: Wed, 15 Feb 2012 10:39:43 -0800 Message-ID: From: Ted Hardie To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Adding top-level service labels 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, 15 Feb 2012 18:39:45 -0000 On Tue, Feb 14, 2012 at 4:59 PM, Martin Thomson wrote: > Ted Hardie wrote: >> [...] RFC 5222, which specifies service URN [...] > > It's tempting to suggest that "urn:" scheme URIs don't have a monopoly > on Unique Resource Names and risk an interoperability failure. urn URIs are "Uniform Resource Names"; they do aim to have the property that they are unique, but it is really the persistence aspect that is the rathole: Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space. Therefore, the URN syntax provides a means to encode character data in a form that can be sent in existing protocols, transcribed on most keyboards, etc. (RFC 2141) Because domain owners can change the resource available at a location-dependent URI, or the domain owner can change, http URIs generally aren't seen to have that property. Something like Larry Masinter's dated URI syntax would get that property, since it is "at this location-dependent URI at a specific time". Personally, I'm not sure services need to be named in a location-independent way; I do hope that the names are persistent, though, as that adds significantly to the chance they won't get re-invented (and thus to interoperability). regards, Ted > > Anyone sufficiently motivated could update the requisite RFCs, but my > risk analysis suggests that that energy might be better saved against > the outside chance that a fire breaks out. From forte@att.com Wed Feb 15 11:31:41 2012 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 E93F221F8642 for ; Wed, 15 Feb 2012 11:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmmGCkND-zzR for ; Wed, 15 Feb 2012 11:31:38 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 20B1B21F862D for ; Wed, 15 Feb 2012 11:31:38 -0800 (PST) X-Env-Sender: forte@att.com X-Msg-Ref: server-13.tower-120.messagelabs.com!1329334297!63825861!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8441 invoked from network); 15 Feb 2012 19:31:37 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-13.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Feb 2012 19:31:37 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1FJW4Rs017373; Wed, 15 Feb 2012 14:32:07 -0500 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1FJW1Wf017320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 14:32:01 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor); Wed, 15 Feb 2012 14:31:27 -0500 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 q1FJVOcC010018; Wed, 15 Feb 2012 14:31:27 -0500 Received: from [151.109.8.213] (dn151-109-8-213.dhcpn.ugn.att.com [151.109.8.213]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q1FJVJKo009571; Wed, 15 Feb 2012 14:31:19 -0500 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 15 Feb 2012 14:32:00 -0500 From: "Andrea G. Forte" Sender: "Andrea G. Forte" To: Ted Hardie , Martin Thomson Message-ID: Thread-Topic: [Ecrit] Adding top-level service labels In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Adding top-level service labels 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, 15 Feb 2012 19:31:42 -0000 The main concern here is interoperability. Do we really want people to start using LoST with whatever URI they like? Do we really want to have 100 different URIs for "school"? In my opinion, the description should be location-independent because it describes a service, not a service at a certain location. The location information is a different layer put on top of the service description so that I can identify the service in a location-independent way and then specify the past, present or future location I want to use in querying for that service. Thanks, -- Andrea On 2/15/12 1:39 PM, "Ted Hardie" wrote: >On Tue, Feb 14, 2012 at 4:59 PM, Martin Thomson > wrote: >> Ted Hardie wrote: >>> [...] RFC 5222, which specifies service URN [...] >> >> It's tempting to suggest that "urn:" scheme URIs don't have a monopoly >> on Unique Resource Names and risk an interoperability failure. > >urn URIs are "Uniform Resource Names"; they do aim to have the property >that they are unique, but it is really the persistence aspect that is >the rathole: > > Uniform Resource Names (URNs) are intended to serve as persistent, > location-independent, resource identifiers and are designed to make > it easy to map other namespaces (which share the properties of URNs) > into URN-space. Therefore, the URN syntax provides a means to encode > character data in a form that can be sent in existing protocols, > transcribed on most keyboards, etc. >(RFC 2141) > >Because domain owners can change the resource available at a >location-dependent URI, or the domain owner can change, http URIs >generally aren't seen to have that property. Something like Larry >Masinter's dated URI syntax would get that property, since it is "at >this location-dependent URI at a specific time". > >Personally, I'm not sure services need to be named in a >location-independent way; I do hope that the names are persistent, >though, as that adds significantly to the chance they won't get >re-invented (and thus to interoperability). > >regards, > >Ted > >> >> Anyone sufficiently motivated could update the requisite RFCs, but my >> risk analysis suggests that that energy might be better saved against >> the outside chance that a fire breaks out. >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Mon Feb 20 03:36:50 2012 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 6ED8021F86A7 for ; Mon, 20 Feb 2012 03:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.946 X-Spam-Level: X-Spam-Status: No, score=-9.946 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShX+UT35Sw6A for ; Mon, 20 Feb 2012 03:36:49 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7BF21F86DF for ; Mon, 20 Feb 2012 03:36:49 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-75-4f422b12ee75 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 92.57.01970.21B224F4; Mon, 20 Feb 2012 12:14:26 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Mon, 20 Feb 2012 12:14:24 +0100 From: Christer Holmberg To: "ecrit@ietf.org" Date: Mon, 20 Feb 2012 12:14:23 +0100 Thread-Topic: PSAP Callback - A New Beginning Thread-Index: Acyzj8ozzQuHH/W6Ssi7VTz+XJsyIA8LYvkw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> References: <4EDA48A1.7040906@alum.mit.edu> <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> <4EDA584E.2050604@alum.mit.edu> <255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu> <4EDA74C3.9070603@alum.mit.edu> <2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net> <4EDCF4A4.60901@alum.mit.edu> <4EDD2EF6.8060707@alum.mit.edu> In-Reply-To: <4EDD2EF6.8060707@alum.mit.edu> 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: [Ecrit] PSAP Callback - A New Beginning 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, 20 Feb 2012 11:36:50 -0000 =20 Hi, We need to try to find a way forward with the PSAP callback issue. There are basically two requirements: (1). Make sure the PSAP callback call reaches the device that made the asso= ciated emergency call (2). PSAP callback indicator I don't think there are any major issues regarding (1). The Contact should = work, at least for callbacks made not too long after the emergency call. If= the callback is made later, when the Contact e.g. is not registered anymor= e, the PSAP can use the AOR. (2) is where we've had most discussions. One question has been whether the UA should provide some nonce value, which= is then used in the callback. The UA can check whether the nonce value in = the callback is something it has generated - assuming the callback reaches = the same UA that made the emergency call. Intermediaires can use the nonce value (or, the protocol element carrying i= t) to trigger callback specific procedures, but they will not know whether = the actual nonce value was created by the UA. Regards, Christer From br@brianrosen.net Mon Feb 20 05:54:47 2012 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 DCAEF21F873B for ; Mon, 20 Feb 2012 05:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.24 X-Spam-Level: X-Spam-Status: No, score=-102.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYNY59xDSmcj for ; Mon, 20 Feb 2012 05:54:44 -0800 (PST) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 049C121F8723 for ; Mon, 20 Feb 2012 05:54:44 -0800 (PST) X-ASG-Debug-ID: 1329746083-04d035199410c5b0001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id nPkFqdaU7g25zgSr; Mon, 20 Feb 2012 05:54:43 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.45]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RzThS-000nl8-Nx; Mon, 20 Feb 2012 05:54:42 -0800 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [Ecrit] PSAP Callback - A New Beginning Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 20 Feb 2012 08:54:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3D40B922-E458-4C20-B2F7-CD61E5B3BFDB@brianrosen.net> References: <4EDA48A1.7040906@alum.mit.edu> <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> <4EDA584E.2050604@alum.mit.edu> <255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu> <4EDA74C3.9070603@alum.mit.edu> <2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net> <4EDCF4A4.60901@alum.mit.edu> <4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1329746083 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.89018 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - A New Beginning 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, 20 Feb 2012 13:54:48 -0000 I don't have a problem with a nonce. We require TLS protection of signaling (because of privacy concerns = carrying location and other personal information), which would protect = the nonce from misuse. But, can't the UA and his system construct the contact to contain the = nonce if it wants to, with no involvement of the PSAP? Brian On Feb 20, 2012, at 6:14 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > We need to try to find a way forward with the PSAP callback issue. >=20 > There are basically two requirements: >=20 > (1). Make sure the PSAP callback call reaches the device that made the = associated emergency call > (2). PSAP callback indicator >=20 >=20 > I don't think there are any major issues regarding (1). The Contact = should work, at least for callbacks made not too long after the = emergency call. If the callback is made later, when the Contact e.g. is = not registered anymore, the PSAP can use the AOR. >=20 >=20 > (2) is where we've had most discussions. >=20 > One question has been whether the UA should provide some nonce value, = which is then used in the callback. The UA can check whether the nonce = value in the callback is something it has generated - assuming the = callback reaches the same UA that made the emergency call. >=20 > Intermediaires can use the nonce value (or, the protocol element = carrying it) to trigger callback specific procedures, but they will not = know whether the actual nonce value was created by the UA. >=20 > Regards, >=20 > Christer > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Mon Feb 20 05:57:41 2012 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 B4FD021F8751 for ; Mon, 20 Feb 2012 05:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.976 X-Spam-Level: X-Spam-Status: No, score=-9.976 tagged_above=-999 required=5 tests=[AWL=0.623, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmGVyq+vxS+8 for ; Mon, 20 Feb 2012 05:57:37 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7121F21F8723 for ; Mon, 20 Feb 2012 05:57:37 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-db-4f425150fe91 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8E.C7.01970.051524F4; Mon, 20 Feb 2012 14:57:36 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 20 Feb 2012 14:57:36 +0100 From: Christer Holmberg To: Brian Rosen Date: Mon, 20 Feb 2012 14:57:35 +0100 Thread-Topic: [Ecrit] PSAP Callback - A New Beginning Thread-Index: Aczv1zRBwbCN/owbTE24PPHc/+fpxAAADsDw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D914DF8@ESESSCMS0356.eemea.ericsson.se> References: <4EDA48A1.7040906@alum.mit.edu> <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> <4EDA584E.2050604@alum.mit.edu> <255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu> <4EDA74C3.9070603@alum.mit.edu> <2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net> <4EDCF4A4.60901@alum.mit.edu> <4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> <3D40B922-E458-4C20-B2F7-CD61E5B3BFDB@brianrosen.net> In-Reply-To: <3D40B922-E458-4C20-B2F7-CD61E5B3BFDB@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 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - A New Beginning 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, 20 Feb 2012 13:57:41 -0000 Hi,=20 > I don't have a problem with a nonce. > > We require TLS protection of signaling (because of privacy concerns carry= ing location and other personal information), which would protect the nonce= from misuse. > > But, can't the UA and his system construct the contact to contain the non= ce if it wants to, with no involvement of the PSAP? Sure. The PSAP only needs to make sure the nonce is sent in the callback IN= VITE, and if it copies the R-URI from the Contact that should not be a prob= lem. Regards, Christer On Feb 20, 2012, at 6:14 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > We need to try to find a way forward with the PSAP callback issue. >=20 > There are basically two requirements: >=20 > (1). Make sure the PSAP callback call reaches the device that made the=20 > associated emergency call (2). PSAP callback indicator >=20 >=20 > I don't think there are any major issues regarding (1). The Contact shoul= d work, at least for callbacks made not too long after the emergency call. = If the callback is made later, when the Contact e.g. is not registered anym= ore, the PSAP can use the AOR. >=20 >=20 > (2) is where we've had most discussions. >=20 > One question has been whether the UA should provide some nonce value, whi= ch is then used in the callback. The UA can check whether the nonce value i= n the callback is something it has generated - assuming the callback reache= s the same UA that made the emergency call. >=20 > Intermediaires can use the nonce value (or, the protocol element carrying= it) to trigger callback specific procedures, but they will not know whethe= r the actual nonce value was created by the UA. >=20 > Regards, >=20 > Christer > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@nsn.com Mon Feb 20 11:02:26 2012 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 540F521F850F for ; Mon, 20 Feb 2012 11:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.285 X-Spam-Level: X-Spam-Status: No, score=-106.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 362ZGNv92OaW for ; Mon, 20 Feb 2012 11:02:22 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id C544521F86CF for ; Mon, 20 Feb 2012 11:02:21 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1KJ2JBX004706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Feb 2012 20:02:20 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1KJ2JKS028932; Mon, 20 Feb 2012 20:02:19 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 20:01:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Feb 2012 21:03:33 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718D0120A9C7@FIESEXC035.nsn-intra.net> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PSAP Callback - A New Beginning Thread-Index: Acyzj8ozzQuHH/W6Ssi7VTz+XJsyIA8LYvkwAAZh/oA= References: <4EDA48A1.7040906@alum.mit.edu><02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu><4EDA584E.2050604@alum.mit.edu><255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu><4EDA74C3.9070603@alum.mit.edu><2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net><4EDCF4A4.60901@alum.mit.edu><4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Christer Holmberg" , X-OriginalArrivalTime: 20 Feb 2012 19:01:55.0518 (UTC) FILETIME=[1D115DE0:01CCF002] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2122 X-purgate-ID: 151667::1329764540-000015E0-FB8CB0DF/0-0/0-0 Subject: Re: [Ecrit] PSAP Callback - A New Beginning 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, 20 Feb 2012 19:02:26 -0000 Hi Christer,=20 there is only one requirement for PSAP callback, namely the ability to distinguish the PSAP callback (by SIP proxies as well as the SIP UA itself) from a regular call to avoid having the callback blocked by user configured authorization policies, or forwarded to an answering machine, etc.=20 The solution has to work with a GRUU and an AoR. If the emergency caller cannot be reached at the provided GRUU then I expect the PSAP calltaker user agent software tries the AoR.=20 The indicator is a solution - not a requirement.=20 Ciao Hannes > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of ext Christer Holmberg > Sent: Monday, February 20, 2012 1:14 PM > To: ecrit@ietf.org > Subject: [Ecrit] PSAP Callback - A New Beginning >=20 >=20 >=20 > Hi, >=20 > We need to try to find a way forward with the PSAP callback issue. >=20 > There are basically two requirements: >=20 > (1). Make sure the PSAP callback call reaches the device that made the > associated emergency call > (2). PSAP callback indicator >=20 >=20 > I don't think there are any major issues regarding (1). The Contact > should work, at least for callbacks made not too long after the > emergency call. If the callback is made later, when the Contact e.g. is > not registered anymore, the PSAP can use the AOR. >=20 >=20 > (2) is where we've had most discussions. >=20 > One question has been whether the UA should provide some nonce value, > which is then used in the callback. The UA can check whether the nonce > value in the callback is something it has generated - assuming the > callback reaches the same UA that made the emergency call. >=20 > Intermediaires can use the nonce value (or, the protocol element > carrying it) to trigger callback specific procedures, but they will not > know whether the actual nonce value was created by the UA. >=20 > Regards, >=20 > Christer > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Mon Feb 20 11:36:42 2012 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 44F1F21F8792 for ; Mon, 20 Feb 2012 11:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.99 X-Spam-Level: X-Spam-Status: No, score=-9.99 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKzvhIrtbjQK for ; Mon, 20 Feb 2012 11:36:38 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id F224F21F86E0 for ; Mon, 20 Feb 2012 11:36:37 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-c9-4f42a0c49e79 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E6.53.27041.4C0A24F4; Mon, 20 Feb 2012 20:36:36 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 20 Feb 2012 20:36:36 +0100 From: Christer Holmberg To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ecrit@ietf.org" Date: Mon, 20 Feb 2012 20:34:54 +0100 Thread-Topic: [Ecrit] PSAP Callback - A New Beginning Thread-Index: Acyzj8ozzQuHH/W6Ssi7VTz+XJsyIA8LYvkwAAZh/oAAC/aynw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D31BA34@ESESSCMS0356.eemea.ericsson.se> References: <4EDA48A1.7040906@alum.mit.edu><02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu><4EDA584E.2050604@alum.mit.edu><255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu><4EDA74C3.9070603@alum.mit.edu><2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net><4EDCF4A4.60901@alum.mit.edu><4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se>, <999913AB42CC9341B05A99BBF358718D0120A9C7@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D0120A9C7@FIESEXC035.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] PSAP Callback - A New Beginning 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, 20 Feb 2012 19:36:42 -0000 Hi, > there is only one requirement for PSAP callback, namely the ability to > distinguish the PSAP callback (by SIP proxies as well as the SIP UA > itself) from a regular call to avoid having the callback blocked by user > configured authorization policies, or forwarded to an answering machine, > etc. Correct. > The solution has to work with a GRUU and an AoR. If the emergency caller > cannot be reached at the provided GRUU then I expect the PSAP calltaker > user agent software tries the AoR. Yes. > The indicator is a solution - not a requirement. Agree. My misstake. Regards, Christer > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of ext Christer Holmberg > Sent: Monday, February 20, 2012 1:14 PM > To: ecrit@ietf.org > Subject: [Ecrit] PSAP Callback - A New Beginning > > > > Hi, > > We need to try to find a way forward with the PSAP callback issue. > > There are basically two requirements: > > (1). Make sure the PSAP callback call reaches the device that made the > associated emergency call > (2). PSAP callback indicator > > > I don't think there are any major issues regarding (1). The Contact > should work, at least for callbacks made not too long after the > emergency call. If the callback is made later, when the Contact e.g. is > not registered anymore, the PSAP can use the AOR. > > > (2) is where we've had most discussions. > > One question has been whether the UA should provide some nonce value, > which is then used in the callback. The UA can check whether the nonce > value in the callback is something it has generated - assuming the > callback reaches the same UA that made the emergency call. > > Intermediaires can use the nonce value (or, the protocol element > carrying it) to trigger callback specific procedures, but they will not > know whether the actual nonce value was created by the UA. > > Regards, > > Christer > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@nsn.com Tue Feb 21 01:16:46 2012 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 2653A21F8627 for ; Tue, 21 Feb 2012 01:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.294 X-Spam-Level: X-Spam-Status: No, score=-106.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlvMe9-6KlGg for ; Tue, 21 Feb 2012 01:16:41 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEB121F8551 for ; Tue, 21 Feb 2012 01:16:41 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1L9Gb9K023548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Feb 2012 10:16:38 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1L9GTWa013739; Tue, 21 Feb 2012 10:16:37 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 10:16:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Feb 2012 11:18:28 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718D0120ABA7@FIESEXC035.nsn-intra.net> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning Thread-Index: Acyzj8ozzQuHH/W6Ssi7VTz+XJsyIA8LYvkwAC78AlA= References: <4EDA48A1.7040906@alum.mit.edu><02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu><4EDA584E.2050604@alum.mit.edu><255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu><4EDA74C3.9070603@alum.mit.edu><2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net><4EDCF4A4.60901@alum.mit.edu><4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Christer Holmberg" , X-OriginalArrivalTime: 21 Feb 2012 09:16:37.0503 (UTC) FILETIME=[838348F0:01CCF079] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2170 X-purgate-ID: 151667::1329815798-00007EDF-F846ABC4/0-0/0-0 Subject: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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: Tue, 21 Feb 2012 09:16:46 -0000 Hi Christer, Hi Brian, we had spoken about the Nonce idea in the past (under a different name, namely the token).=20 We also argued that the GRUU could fulfill that purpose. The problem with that concept was that it only works when the forward and the reverse path are the same. In our scenarios (at the beginning of the draft) we argue that this is not the case.=20 This brought us back to the PSAP callback indicator (which of course could take many forms, including the Resource Priority Header, or the stuff we had put in http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 Ciao Hannes > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of ext Christer Holmberg > Sent: Monday, February 20, 2012 1:14 PM > To: ecrit@ietf.org > Subject: [Ecrit] PSAP Callback - A New Beginning >=20 >=20 >=20 > Hi, >=20 > We need to try to find a way forward with the PSAP callback issue. >=20 > There are basically two requirements: >=20 > (1). Make sure the PSAP callback call reaches the device that made the > associated emergency call > (2). PSAP callback indicator >=20 >=20 > I don't think there are any major issues regarding (1). The Contact > should work, at least for callbacks made not too long after the > emergency call. If the callback is made later, when the Contact e.g. is > not registered anymore, the PSAP can use the AOR. >=20 >=20 > (2) is where we've had most discussions. >=20 > One question has been whether the UA should provide some nonce value, > which is then used in the callback. The UA can check whether the nonce > value in the callback is something it has generated - assuming the > callback reaches the same UA that made the emergency call. >=20 > Intermediaires can use the nonce value (or, the protocol element > carrying it) to trigger callback specific procedures, but they will not > know whether the actual nonce value was created by the UA. >=20 > Regards, >=20 > Christer > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Tue Feb 21 02:46:58 2012 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 9F87B21F86B1 for ; Tue, 21 Feb 2012 02:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yS2FWtzDieRS for ; Tue, 21 Feb 2012 02:46:54 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1B65F21F86AA for ; Tue, 21 Feb 2012 02:46:53 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-0e-4f43761c2188 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 90.51.01970.C16734F4; Tue, 21 Feb 2012 11:46:53 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 21 Feb 2012 11:46:52 +0100 From: Christer Holmberg To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ecrit@ietf.org" Date: Tue, 21 Feb 2012 11:46:51 +0100 Thread-Topic: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning Thread-Index: Acyzj8ozzQuHH/W6Ssi7VTz+XJsyIA8LYvkwAC78AlAAAs2RoA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D9152FF@ESESSCMS0356.eemea.ericsson.se> References: <4EDA48A1.7040906@alum.mit.edu><02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu><4EDA584E.2050604@alum.mit.edu><255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu><4EDA74C3.9070603@alum.mit.edu><2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net><4EDCF4A4.60901@alum.mit.edu><4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ABA7@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D0120ABA7@FIESEXC035.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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: Tue, 21 Feb 2012 10:46:58 -0000 Hi Hannes, When I have been talking about the nonce, I have been talking about the ind= icator. But, in order to avoid confusion, until we have decided how to impl= ement it, let's talk about the indicator :) Then, how to implement it? One alternative would be to use a media feature tag, e.g. +g.sip.emg. The f= eature tag could also contain a nonce value, created by the UA. For example= : +g.sip.emg=3D6fdxtg4es6 The UA would register the feature tag with its registrar. That way, the hom= e network would be aware of the value. The UA, when making an emg call, would include the feature tag in the Conta= ct header field of the INVITE. The PSAP, when making a callback, would include the feature tag in the Acce= pt-Contact header field of the INVITE. In addition to acting as a callback = indicator, the feature tag would help in finding the correct UA (e.g. if GR= UU is not supported). The home network can also compare the value with the registered value. And,= if they don't match, the home network could reject the request, or don't g= ive callback processing, based on network policy. (Another alternative would be to define a URI parameter, used in the Contac= t of the emg call INVITE, and in the R-URI of the callback INVITE. The prob= lem, however, is that the R-URI is overwritten by the home network. If Hist= ory-Info is supported, it would be put there, but then entities (and the UA= ) would have to scan through the History-Info list.) Regards, Christer =20 -----Original Message----- From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com= ]=20 Sent: 21. helmikuuta 2012 11:18 To: Christer Holmberg; ecrit@ietf.org Subject: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning Hi Christer, Hi Brian, we had spoken about the Nonce idea in the past (under a different name, nam= ely the token).=20 We also argued that the GRUU could fulfill that purpose. The problem with that concept was that it only works when the forward and t= he reverse path are the same. In our scenarios (at the beginning of the dra= ft) we argue that this is not the case.=20 This brought us back to the PSAP callback indicator (which of course could = take many forms, including the Resource Priority Header, or the stuff we ha= d put in http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 Ciao Hannes > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=20 > Of ext Christer Holmberg > Sent: Monday, February 20, 2012 1:14 PM > To: ecrit@ietf.org > Subject: [Ecrit] PSAP Callback - A New Beginning >=20 >=20 >=20 > Hi, >=20 > We need to try to find a way forward with the PSAP callback issue. >=20 > There are basically two requirements: >=20 > (1). Make sure the PSAP callback call reaches the device that made the=20 > associated emergency call (2). PSAP callback indicator >=20 >=20 > I don't think there are any major issues regarding (1). The Contact=20 > should work, at least for callbacks made not too long after the=20 > emergency call. If the callback is made later, when the Contact e.g. is > not registered anymore, the PSAP can use the AOR. >=20 >=20 > (2) is where we've had most discussions. >=20 > One question has been whether the UA should provide some nonce value,=20 > which is then used in the callback. The UA can check whether the nonce=20 > value in the callback is something it has generated - assuming the=20 > callback reaches the same UA that made the emergency call. >=20 > Intermediaires can use the nonce value (or, the protocol element=20 > carrying it) to trigger callback specific procedures, but they will not > know whether the actual nonce value was created by the UA. >=20 > Regards, >=20 > Christer > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@nsn.com Tue Feb 21 04:10:48 2012 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 B2CBF21F85AE for ; Tue, 21 Feb 2012 04:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.303 X-Spam-Level: X-Spam-Status: No, score=-106.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYrbzN8FVO5L for ; Tue, 21 Feb 2012 04:10:40 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id CDA1321F85DB for ; Tue, 21 Feb 2012 04:10:38 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1LCATw3009807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Feb 2012 13:10:29 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1LCAQLf016217; Tue, 21 Feb 2012 13:10:29 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 13:10:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Feb 2012 14:12:05 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718D0120AD5B@FIESEXC035.nsn-intra.net> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D9152FF@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning Thread-Index: Acyzj8ozzQuHH/W6Ssi7VTz+XJsyIA8LYvkwAC78AlAAAs2RoAADQJGQ References: <4EDA48A1.7040906@alum.mit.edu><02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu><4EDA584E.2050604@alum.mit.edu><255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu><4EDA74C3.9070603@alum.mit.edu><2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net><4EDCF4A4.60901@alum.mit.edu><4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ABA7@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9152FF@ESESSCMS0356.eemea.ericsson.se> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Christer Holmberg" , X-OriginalArrivalTime: 21 Feb 2012 12:10:20.0530 (UTC) FILETIME=[C81EFD20:01CCF091] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5129 X-purgate-ID: 151667::1329826229-00007EDF-ABD556DB/0-0/0-0 Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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: Tue, 21 Feb 2012 12:10:48 -0000 Hi Christer,=20 thanks for the clarification.=20 But wouldn't we essentially re-implement parts of the GRUU functionality with this specific feature tag?=20 I was proposing earlier to use the GRUU (when available) for the purpose of reaching the calling device.=20 Then, in addition there was the actual callback marking, see http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02#section-4 Finally, there was the security related functionality of which I believe only the identity-based authorization is practical. Richard had proposed another mechanism based on LoST, which I found worthwhile to explore as well.=20 Ciao Hannes > -----Original Message----- > From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, February 21, 2012 12:47 PM > To: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org > Subject: RE: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning >=20 >=20 > Hi Hannes, >=20 > When I have been talking about the nonce, I have been talking about the > indicator. But, in order to avoid confusion, until we have decided how > to implement it, let's talk about the indicator :) >=20 > Then, how to implement it? >=20 > One alternative would be to use a media feature tag, e.g. +g.sip.emg. > The feature tag could also contain a nonce value, created by the UA. For > example: +g.sip.emg=3D6fdxtg4es6 >=20 > The UA would register the feature tag with its registrar. That way, the > home network would be aware of the value. >=20 > The UA, when making an emg call, would include the feature tag in the > Contact header field of the INVITE. >=20 > The PSAP, when making a callback, would include the feature tag in the > Accept-Contact header field of the INVITE. In addition to acting as a > callback indicator, the feature tag would help in finding the correct UA > (e.g. if GRUU is not supported). >=20 > The home network can also compare the value with the registered value. > And, if they don't match, the home network could reject the request, or > don't give callback processing, based on network policy. >=20 > (Another alternative would be to define a URI parameter, used in the > Contact of the emg call INVITE, and in the R-URI of the callback INVITE. > The problem, however, is that the R-URI is overwritten by the home > network. If History-Info is supported, it would be put there, but then > entities (and the UA) would have to scan through the History-Info list.) >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: 21. helmikuuta 2012 11:18 > To: Christer Holmberg; ecrit@ietf.org > Subject: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning >=20 > Hi Christer, Hi Brian, >=20 > we had spoken about the Nonce idea in the past (under a different name, > namely the token). >=20 > We also argued that the GRUU could fulfill that purpose. >=20 > The problem with that concept was that it only works when the forward > and the reverse path are the same. In our scenarios (at the beginning of > the draft) we argue that this is not the case. >=20 > This brought us back to the PSAP callback indicator (which of course > could take many forms, including the Resource Priority Header, or the > stuff we had put in > http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 >=20 > Ciao > Hannes >=20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > Of ext Christer Holmberg > > Sent: Monday, February 20, 2012 1:14 PM > > To: ecrit@ietf.org > > Subject: [Ecrit] PSAP Callback - A New Beginning > > > > > > > > Hi, > > > > We need to try to find a way forward with the PSAP callback issue. > > > > There are basically two requirements: > > > > (1). Make sure the PSAP callback call reaches the device that made the > > associated emergency call (2). PSAP callback indicator > > > > > > I don't think there are any major issues regarding (1). The Contact > > should work, at least for callbacks made not too long after the > > emergency call. If the callback is made later, when the Contact e.g. > is > > not registered anymore, the PSAP can use the AOR. > > > > > > (2) is where we've had most discussions. > > > > One question has been whether the UA should provide some nonce value, > > which is then used in the callback. The UA can check whether the nonce > > value in the callback is something it has generated - assuming the > > callback reaches the same UA that made the emergency call. > > > > Intermediaires can use the nonce value (or, the protocol element > > carrying it) to trigger callback specific procedures, but they will > not > > know whether the actual nonce value was created by the UA. > > > > Regards, > > > > Christer > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Tue Feb 21 04:14:46 2012 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 E06D821F8760 for ; Tue, 21 Feb 2012 04:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKab5AGIh6kH for ; Tue, 21 Feb 2012 04:14:42 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 15F2F21F8738 for ; Tue, 21 Feb 2012 04:14:41 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-2e-4f438ab16a5f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 20.C1.01970.0BA834F4; Tue, 21 Feb 2012 13:14:41 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 21 Feb 2012 13:14:40 +0100 From: Christer Holmberg To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ecrit@ietf.org" Date: Tue, 21 Feb 2012 13:14:39 +0100 Thread-Topic: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning Thread-Index: Acyzj8ozzQuHH/W6Ssi7VTz+XJsyIA8LYvkwAC78AlAAAs2RoAADQJGQAAAl65A= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D9153FE@ESESSCMS0356.eemea.ericsson.se> References: <4EDA48A1.7040906@alum.mit.edu><02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu><4EDA584E.2050604@alum.mit.edu><255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu><4EDA74C3.9070603@alum.mit.edu><2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net><4EDCF4A4.60901@alum.mit.edu><4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ABA7@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9152FF@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120AD5B@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D0120AD5B@FIESEXC035.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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: Tue, 21 Feb 2012 12:14:47 -0000 Hi,=20 > thanks for the clarification.=20 > > But wouldn't we essentially re-implement parts of the GRUU functionality = with this specific feature tag?=20 As far as reaching the UA, yes, but the main purpose is to provide the call= back indicator. (Also keep in mind that not every UA support GRUU.) > I was proposing earlier to use the GRUU (when available) for the purpose = of reaching the calling device.=20 > Then, in addition there was the actual callback marking, see > http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02#section-4 I am only focusing on the callback marking. But, again, a feature tag may a= lso help in reaching the terminal (in cases where GRUU is not used, AND the= home registrar supports feature capabilities). Regards, Christer Finally, there was the security related functionality of which I believe on= ly the identity-based authorization is practical. Richard had proposed anot= her mechanism based on LoST, which I found worthwhile to explore as well.=20 Ciao Hannes > -----Original Message----- > From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, February 21, 2012 12:47 PM > To: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org > Subject: RE: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning >=20 >=20 > Hi Hannes, >=20 > When I have been talking about the nonce, I have been talking about the > indicator. But, in order to avoid confusion, until we have decided how=20 > to implement it, let's talk about the indicator :) >=20 > Then, how to implement it? >=20 > One alternative would be to use a media feature tag, e.g. +g.sip.emg. > The feature tag could also contain a nonce value, created by the UA. For > example: +g.sip.emg=3D6fdxtg4es6 >=20 > The UA would register the feature tag with its registrar. That way, the > home network would be aware of the value. >=20 > The UA, when making an emg call, would include the feature tag in the=20 > Contact header field of the INVITE. >=20 > The PSAP, when making a callback, would include the feature tag in the=20 > Accept-Contact header field of the INVITE. In addition to acting as a=20 > callback indicator, the feature tag would help in finding the correct UA > (e.g. if GRUU is not supported). >=20 > The home network can also compare the value with the registered value. > And, if they don't match, the home network could reject the request, or > don't give callback processing, based on network policy. >=20 > (Another alternative would be to define a URI parameter, used in the=20 > Contact of the emg call INVITE, and in the R-URI of the callback INVITE. > The problem, however, is that the R-URI is overwritten by the home=20 > network. If History-Info is supported, it would be put there, but then=20 > entities (and the UA) would have to scan through the History-Info list.) >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo)=20 > [mailto:hannes.tschofenig@nsn.com] > Sent: 21. helmikuuta 2012 11:18 > To: Christer Holmberg; ecrit@ietf.org > Subject: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning >=20 > Hi Christer, Hi Brian, >=20 > we had spoken about the Nonce idea in the past (under a different name, > namely the token). >=20 > We also argued that the GRUU could fulfill that purpose. >=20 > The problem with that concept was that it only works when the forward=20 > and the reverse path are the same. In our scenarios (at the beginning of > the draft) we argue that this is not the case. >=20 > This brought us back to the PSAP callback indicator (which of course=20 > could take many forms, including the Resource Priority Header, or the=20 > stuff we had put in > http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 >=20 > Ciao > Hannes >=20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > Of ext Christer Holmberg > > Sent: Monday, February 20, 2012 1:14 PM > > To: ecrit@ietf.org > > Subject: [Ecrit] PSAP Callback - A New Beginning > > > > > > > > Hi, > > > > We need to try to find a way forward with the PSAP callback issue. > > > > There are basically two requirements: > > > > (1). Make sure the PSAP callback call reaches the device that made the > > associated emergency call (2). PSAP callback indicator > > > > > > I don't think there are any major issues regarding (1). The Contact=20 > > should work, at least for callbacks made not too long after the=20 > > emergency call. If the callback is made later, when the Contact e.g. > is > > not registered anymore, the PSAP can use the AOR. > > > > > > (2) is where we've had most discussions. > > > > One question has been whether the UA should provide some nonce value, > > which is then used in the callback. The UA can check whether the nonce > > value in the callback is something it has generated - assuming the=20 > > callback reaches the same UA that made the emergency call. > > > > Intermediaires can use the nonce value (or, the protocol element=20 > > carrying it) to trigger callback specific procedures, but they will > not > > know whether the actual nonce value was created by the UA. > > > > Regards, > > > > Christer > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@nsn.com Tue Feb 21 04:42:02 2012 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 0A65221F8699 for ; Tue, 21 Feb 2012 04:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.311 X-Spam-Level: X-Spam-Status: No, score=-106.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0xE3oUK-KBd for ; Tue, 21 Feb 2012 04:41:57 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB6D21F86CE for ; Tue, 21 Feb 2012 04:41:57 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1LCfjg7031649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Feb 2012 13:41:46 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1LCfeIG001269; Tue, 21 Feb 2012 13:41:45 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 13:41:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Feb 2012 14:43:19 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718D0120ADB8@FIESEXC035.nsn-intra.net> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D9153FE@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning Thread-Index: Acyzj8ozzQuHH/W6Ssi7VTz+XJsyIA8LYvkwAC78AlAAAs2RoAADQJGQAAAl65AAAPiFIA== References: <4EDA48A1.7040906@alum.mit.edu><02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu><4EDA584E.2050604@alum.mit.edu><255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu><4EDA74C3.9070603@alum.mit.edu><2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net><4EDCF4A4.60901@alum.mit.edu><4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ABA7@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9152FF@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120AD5B@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9153FE@ESESSCMS0356.eemea.ericsson.se> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Christer Holmberg" , X-OriginalArrivalTime: 21 Feb 2012 12:41:31.0971 (UTC) FILETIME=[23963930:01CCF096] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6482 X-purgate-ID: 151667::1329828108-000015E0-A337AF4C/0-0/0-0 Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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: Tue, 21 Feb 2012 12:42:02 -0000 Hi Christer,=20 we are introducing new functionality to get the PSAP callback functionality to work and this requires changes to SIP UAs and to proxies. Existing devices clearly do not support this functionality yet. So, the argument that GRUU is not supported by certain SIP UAs is correct but not relevant. Am I missing something? Ciao Hannes > -----Original Message----- > From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, February 21, 2012 2:15 PM > To: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org > Subject: RE: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning >=20 >=20 > Hi, >=20 > > thanks for the clarification. > > > > But wouldn't we essentially re-implement parts of the GRUU > functionality with this specific feature tag? >=20 > As far as reaching the UA, yes, but the main purpose is to provide the > callback indicator. >=20 > (Also keep in mind that not every UA support GRUU.) >=20 > > I was proposing earlier to use the GRUU (when available) for the > purpose of reaching the calling device. > > Then, in addition there was the actual callback marking, see > > http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02#section-4 >=20 > I am only focusing on the callback marking. But, again, a feature tag > may also help in reaching the terminal (in cases where GRUU is not used, > AND the home registrar supports feature capabilities). >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 > Finally, there was the security related functionality of which I believe > only the identity-based authorization is practical. Richard had proposed > another mechanism based on LoST, which I found worthwhile to explore as > well. >=20 > Ciao > Hannes >=20 >=20 > > -----Original Message----- > > From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, February 21, 2012 12:47 PM > > To: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org > > Subject: RE: Nonce value -- RE: [Ecrit] PSAP Callback - A New > Beginning > > > > > > Hi Hannes, > > > > When I have been talking about the nonce, I have been talking about > the > > indicator. But, in order to avoid confusion, until we have decided how > > to implement it, let's talk about the indicator :) > > > > Then, how to implement it? > > > > One alternative would be to use a media feature tag, e.g. +g.sip.emg. > > The feature tag could also contain a nonce value, created by the UA. > For > > example: +g.sip.emg=3D6fdxtg4es6 > > > > The UA would register the feature tag with its registrar. That way, > the > > home network would be aware of the value. > > > > The UA, when making an emg call, would include the feature tag in the > > Contact header field of the INVITE. > > > > The PSAP, when making a callback, would include the feature tag in the > > Accept-Contact header field of the INVITE. In addition to acting as a > > callback indicator, the feature tag would help in finding the correct > UA > > (e.g. if GRUU is not supported). > > > > The home network can also compare the value with the registered value. > > And, if they don't match, the home network could reject the request, > or > > don't give callback processing, based on network policy. > > > > (Another alternative would be to define a URI parameter, used in the > > Contact of the emg call INVITE, and in the R-URI of the callback > INVITE. > > The problem, however, is that the R-URI is overwritten by the home > > network. If History-Info is supported, it would be put there, but then > > entities (and the UA) would have to scan through the History-Info > list.) > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > -----Original Message----- > > From: Tschofenig, Hannes (NSN - FI/Espoo) > > [mailto:hannes.tschofenig@nsn.com] > > Sent: 21. helmikuuta 2012 11:18 > > To: Christer Holmberg; ecrit@ietf.org > > Subject: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning > > > > Hi Christer, Hi Brian, > > > > we had spoken about the Nonce idea in the past (under a different > name, > > namely the token). > > > > We also argued that the GRUU could fulfill that purpose. > > > > The problem with that concept was that it only works when the forward > > and the reverse path are the same. In our scenarios (at the beginning > of > > the draft) we argue that this is not the case. > > > > This brought us back to the PSAP callback indicator (which of course > > could take many forms, including the Resource Priority Header, or the > > stuff we had put in > > http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 > > > > Ciao > > Hannes > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > > Of ext Christer Holmberg > > > Sent: Monday, February 20, 2012 1:14 PM > > > To: ecrit@ietf.org > > > Subject: [Ecrit] PSAP Callback - A New Beginning > > > > > > > > > > > > Hi, > > > > > > We need to try to find a way forward with the PSAP callback issue. > > > > > > There are basically two requirements: > > > > > > (1). Make sure the PSAP callback call reaches the device that made > the > > > associated emergency call (2). PSAP callback indicator > > > > > > > > > I don't think there are any major issues regarding (1). The Contact > > > should work, at least for callbacks made not too long after the > > > emergency call. If the callback is made later, when the Contact e.g. > > is > > > not registered anymore, the PSAP can use the AOR. > > > > > > > > > (2) is where we've had most discussions. > > > > > > One question has been whether the UA should provide some nonce > value, > > > which is then used in the callback. The UA can check whether the > nonce > > > value in the callback is something it has generated - assuming the > > > callback reaches the same UA that made the emergency call. > > > > > > Intermediaires can use the nonce value (or, the protocol element > > > carrying it) to trigger callback specific procedures, but they will > > not > > > know whether the actual nonce value was created by the UA. > > > > > > Regards, > > > > > > Christer > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Tue Feb 21 04:59:40 2012 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 86B9921F8495 for ; Tue, 21 Feb 2012 04:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.06 X-Spam-Level: X-Spam-Status: No, score=-10.06 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od1BH8lH8--U for ; Tue, 21 Feb 2012 04:59:36 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0434421F845D for ; Tue, 21 Feb 2012 04:59:35 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-0a-4f43953677f7 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E3.0A.01970.635934F4; Tue, 21 Feb 2012 13:59:35 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 21 Feb 2012 13:59:34 +0100 From: Christer Holmberg To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ecrit@ietf.org" Date: Tue, 21 Feb 2012 13:59:33 +0100 Thread-Topic: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning Thread-Index: Acyzj8ozzQuHH/W6Ssi7VTz+XJsyIA8LYvkwAC78AlAAAs2RoAADQJGQAAAl65AAAPiFIAAAhteQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D915478@ESESSCMS0356.eemea.ericsson.se> References: <4EDA48A1.7040906@alum.mit.edu><02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu><4EDA584E.2050604@alum.mit.edu><255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu><4EDA74C3.9070603@alum.mit.edu><2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net><4EDCF4A4.60901@alum.mit.edu><4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ABA7@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9152FF@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120AD5B@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9153FE@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ADB8@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D0120ADB8@FIESEXC035.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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: Tue, 21 Feb 2012 12:59:40 -0000 Hi, > we are introducing new functionality to get the PSAP callback functionali= ty to work and this requires changes to SIP UAs and to proxies. Existing de= vices clearly do not support this=20 > functionality yet. > > So, the argument that GRUU is not supported by certain SIP UAs is correct= but not relevant. > > Am I missing something? I am NOT talking about replacing GRUU with the feature tag. GRUU is still t= he preferred way of routing to the UA. I am just saying that a "side effect" of a feature tag based indicator is t= hat it CAN also be used for routing. I am not saying that we shall mandate = support of feature tag based routing. The main purpose of the feature tag i= s still as indicator. Regards, Christer > -----Original Message----- > From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, February 21, 2012 2:15 PM > To: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org > Subject: RE: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning >=20 >=20 > Hi, >=20 > > thanks for the clarification. > > > > But wouldn't we essentially re-implement parts of the GRUU > functionality with this specific feature tag? >=20 > As far as reaching the UA, yes, but the main purpose is to provide the=20 > callback indicator. >=20 > (Also keep in mind that not every UA support GRUU.) >=20 > > I was proposing earlier to use the GRUU (when available) for the > purpose of reaching the calling device. > > Then, in addition there was the actual callback marking, see > > http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02#section-4 >=20 > I am only focusing on the callback marking. But, again, a feature tag=20 > may also help in reaching the terminal (in cases where GRUU is not used, > AND the home registrar supports feature capabilities). >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 > Finally, there was the security related functionality of which I believe > only the identity-based authorization is practical. Richard had proposed > another mechanism based on LoST, which I found worthwhile to explore as > well. >=20 > Ciao > Hannes >=20 >=20 > > -----Original Message----- > > From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, February 21, 2012 12:47 PM > > To: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org > > Subject: RE: Nonce value -- RE: [Ecrit] PSAP Callback - A New > Beginning > > > > > > Hi Hannes, > > > > When I have been talking about the nonce, I have been talking about > the > > indicator. But, in order to avoid confusion, until we have decided how > > to implement it, let's talk about the indicator :) > > > > Then, how to implement it? > > > > One alternative would be to use a media feature tag, e.g. +g.sip.emg. > > The feature tag could also contain a nonce value, created by the UA. > For > > example: +g.sip.emg=3D6fdxtg4es6 > > > > The UA would register the feature tag with its registrar. That way, > the > > home network would be aware of the value. > > > > The UA, when making an emg call, would include the feature tag in the > > Contact header field of the INVITE. > > > > The PSAP, when making a callback, would include the feature tag in the > > Accept-Contact header field of the INVITE. In addition to acting as a > > callback indicator, the feature tag would help in finding the correct > UA > > (e.g. if GRUU is not supported). > > > > The home network can also compare the value with the registered value. > > And, if they don't match, the home network could reject the request, > or > > don't give callback processing, based on network policy. > > > > (Another alternative would be to define a URI parameter, used in the=20 > > Contact of the emg call INVITE, and in the R-URI of the callback > INVITE. > > The problem, however, is that the R-URI is overwritten by the home=20 > > network. If History-Info is supported, it would be put there, but then > > entities (and the UA) would have to scan through the History-Info > list.) > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > -----Original Message----- > > From: Tschofenig, Hannes (NSN - FI/Espoo)=20 > > [mailto:hannes.tschofenig@nsn.com] > > Sent: 21. helmikuuta 2012 11:18 > > To: Christer Holmberg; ecrit@ietf.org > > Subject: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning > > > > Hi Christer, Hi Brian, > > > > we had spoken about the Nonce idea in the past (under a different > name, > > namely the token). > > > > We also argued that the GRUU could fulfill that purpose. > > > > The problem with that concept was that it only works when the forward > > and the reverse path are the same. In our scenarios (at the beginning > of > > the draft) we argue that this is not the case. > > > > This brought us back to the PSAP callback indicator (which of course=20 > > could take many forms, including the Resource Priority Header, or the > > stuff we had put in > > http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 > > > > Ciao > > Hannes > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > > Of ext Christer Holmberg > > > Sent: Monday, February 20, 2012 1:14 PM > > > To: ecrit@ietf.org > > > Subject: [Ecrit] PSAP Callback - A New Beginning > > > > > > > > > > > > Hi, > > > > > > We need to try to find a way forward with the PSAP callback issue. > > > > > > There are basically two requirements: > > > > > > (1). Make sure the PSAP callback call reaches the device that made > the > > > associated emergency call (2). PSAP callback indicator > > > > > > > > > I don't think there are any major issues regarding (1). The Contact > > > should work, at least for callbacks made not too long after the=20 > > > emergency call. If the callback is made later, when the Contact e.g. > > is > > > not registered anymore, the PSAP can use the AOR. > > > > > > > > > (2) is where we've had most discussions. > > > > > > One question has been whether the UA should provide some nonce > value, > > > which is then used in the callback. The UA can check whether the > nonce > > > value in the callback is something it has generated - assuming the=20 > > > callback reaches the same UA that made the emergency call. > > > > > > Intermediaires can use the nonce value (or, the protocol element=20 > > > carrying it) to trigger callback specific procedures, but they will > > not > > > know whether the actual nonce value was created by the UA. > > > > > > Regards, > > > > > > Christer > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@nsn.com Tue Feb 21 05:02:58 2012 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 15F8421F87C4 for ; Tue, 21 Feb 2012 05:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.319 X-Spam-Level: X-Spam-Status: No, score=-106.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlzEj-Nm5evc for ; Tue, 21 Feb 2012 05:02:56 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C4D6E21F87C7 for ; Tue, 21 Feb 2012 05:02:55 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1LD2miu022632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Feb 2012 14:02:49 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1LD2mP7005181; Tue, 21 Feb 2012 14:02:48 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 14:01:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Feb 2012 15:03:43 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718D0120ADEA@FIESEXC035.nsn-intra.net> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D915478@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning Thread-Index: Acyzj8ozzQuHH/W6Ssi7VTz+XJsyIA8LYvkwAC78AlAAAs2RoAADQJGQAAAl65AAAPiFIAAAhteQAAA+vPA= References: <4EDA48A1.7040906@alum.mit.edu><02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu><4EDA584E.2050604@alum.mit.edu><255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu><4EDA74C3.9070603@alum.mit.edu><2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net><4EDCF4A4.60901@alum.mit.edu><4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ABA7@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9152FF@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120AD5B@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9153FE@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ADB8@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D915478@ESESSCMS0356.eemea.ericsson.se> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Christer Holmberg" , X-OriginalArrivalTime: 21 Feb 2012 13:01:55.0549 (UTC) FILETIME=[FCE568D0:01CCF098] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 596 X-purgate-ID: 151667::1329829370-00007EDF-3A3248CA/0-0/0-0 Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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: Tue, 21 Feb 2012 13:02:58 -0000 > I am NOT talking about replacing GRUU with the feature tag. GRUU is > still the preferred way of routing to the UA. >=20 > I am just saying that a "side effect" of a feature tag based indicator > is that it CAN also be used for routing. I am not saying that we shall > mandate support of feature tag based routing. The main purpose of the > feature tag is still as indicator. But wouldn't it then be sufficient to have just a SIP header field set by the PSAP when it sends the callback that says "callback"?=20 Anything else would just be replicating existing functionality.=20 From hgs@cs.columbia.edu Tue Feb 21 05:03:43 2012 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 9C50E21F87C8 for ; Tue, 21 Feb 2012 05:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXpFyfQGeyk8 for ; Tue, 21 Feb 2012 05:03:40 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF2821F87C3 for ; Tue, 21 Feb 2012 05:03:39 -0800 (PST) Received: from [10.0.0.4] (c-98-218-140-58.hsd1.va.comcast.net [98.218.140.58]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q1LD3ZxY000878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 21 Feb 2012 08:03:36 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D915478@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 21 Feb 2012 08:03:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EDA48A1.7040906@alum.mit.edu><02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu><4EDA584E.2050604@alum.mit.edu><255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu><4EDA74C3.9070603@alum.mit.edu><2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net><4EDCF4A4.60901@alum.mit.edu><4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ABA7@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9152FF@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120AD5B@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9153FE@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ADB8@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D915478@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1257) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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: Tue, 21 Feb 2012 13:03:43 -0000 The problem with any "this is an emergency call back" tags is that = anybody can insert them and thus invoke whatever the callback identifier = is meant to change in terms of call handling. Thus, only nonce-based = mechanisms provide protection against such attacks. With that, the = question is which caller-chosen identifiers or nonces can survive the = round trip. Once you make the environment sufficiently hostile (SBCs, = tel URIs, no changes in UAs, etc.), not much, unfortunately. Henning On Feb 21, 2012, at 7:59 AM, Christer Holmberg wrote: >=20 > Hi, >=20 >> we are introducing new functionality to get the PSAP callback = functionality to work and this requires changes to SIP UAs and to = proxies. Existing devices clearly do not support this=20 >> functionality yet. >>=20 >> So, the argument that GRUU is not supported by certain SIP UAs is = correct but not relevant. >>=20 >> Am I missing something? >=20 > I am NOT talking about replacing GRUU with the feature tag. GRUU is = still the preferred way of routing to the UA. >=20 > I am just saying that a "side effect" of a feature tag based indicator = is that it CAN also be used for routing. I am not saying that we shall = mandate support of feature tag based routing. The main purpose of the = feature tag is still as indicator. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Tuesday, February 21, 2012 2:15 PM >> To: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org >> Subject: RE: Nonce value -- RE: [Ecrit] PSAP Callback - A New > Beginning >>=20 >>=20 >> Hi, >>=20 >>> thanks for the clarification. >>>=20 >>> But wouldn't we essentially re-implement parts of the GRUU >> functionality with this specific feature tag? >>=20 >> As far as reaching the UA, yes, but the main purpose is to provide = the=20 >> callback indicator. >>=20 >> (Also keep in mind that not every UA support GRUU.) >>=20 >>> I was proposing earlier to use the GRUU (when available) for the >> purpose of reaching the calling device. >>> Then, in addition there was the actual callback marking, see >>>=20 > http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02#section-4 >>=20 >> I am only focusing on the callback marking. But, again, a feature tag=20= >> may also help in reaching the terminal (in cases where GRUU is not > used, >> AND the home registrar supports feature capabilities). >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Finally, there was the security related functionality of which I > believe >> only the identity-based authorization is practical. Richard had > proposed >> another mechanism based on LoST, which I found worthwhile to explore > as >> well. >>=20 >> Ciao >> Hannes >>=20 >>=20 >>> -----Original Message----- >>> From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Tuesday, February 21, 2012 12:47 PM >>> To: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org >>> Subject: RE: Nonce value -- RE: [Ecrit] PSAP Callback - A New >> Beginning >>>=20 >>>=20 >>> Hi Hannes, >>>=20 >>> When I have been talking about the nonce, I have been talking about >> the >>> indicator. But, in order to avoid confusion, until we have decided > how >>> to implement it, let's talk about the indicator :) >>>=20 >>> Then, how to implement it? >>>=20 >>> One alternative would be to use a media feature tag, e.g. > +g.sip.emg. >>> The feature tag could also contain a nonce value, created by the UA. >> For >>> example: +g.sip.emg=3D6fdxtg4es6 >>>=20 >>> The UA would register the feature tag with its registrar. That way, >> the >>> home network would be aware of the value. >>>=20 >>> The UA, when making an emg call, would include the feature tag in > the >>> Contact header field of the INVITE. >>>=20 >>> The PSAP, when making a callback, would include the feature tag in > the >>> Accept-Contact header field of the INVITE. In addition to acting as > a >>> callback indicator, the feature tag would help in finding the > correct >> UA >>> (e.g. if GRUU is not supported). >>>=20 >>> The home network can also compare the value with the registered > value. >>> And, if they don't match, the home network could reject the request, >> or >>> don't give callback processing, based on network policy. >>>=20 >>> (Another alternative would be to define a URI parameter, used in the=20= >>> Contact of the emg call INVITE, and in the R-URI of the callback >> INVITE. >>> The problem, however, is that the R-URI is overwritten by the home=20= >>> network. If History-Info is supported, it would be put there, but > then >>> entities (and the UA) would have to scan through the History-Info >> list.) >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Tschofenig, Hannes (NSN - FI/Espoo)=20 >>> [mailto:hannes.tschofenig@nsn.com] >>> Sent: 21. helmikuuta 2012 11:18 >>> To: Christer Holmberg; ecrit@ietf.org >>> Subject: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning >>>=20 >>> Hi Christer, Hi Brian, >>>=20 >>> we had spoken about the Nonce idea in the past (under a different >> name, >>> namely the token). >>>=20 >>> We also argued that the GRUU could fulfill that purpose. >>>=20 >>> The problem with that concept was that it only works when the > forward >>> and the reverse path are the same. In our scenarios (at the > beginning >> of >>> the draft) we argue that this is not the case. >>>=20 >>> This brought us back to the PSAP callback indicator (which of course=20= >>> could take many forms, including the Resource Priority Header, or > the >>> stuff we had put in >>> http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 >>>=20 >>> Ciao >>> Hannes >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >>>> Of ext Christer Holmberg >>>> Sent: Monday, February 20, 2012 1:14 PM >>>> To: ecrit@ietf.org >>>> Subject: [Ecrit] PSAP Callback - A New Beginning >>>>=20 >>>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>> We need to try to find a way forward with the PSAP callback issue. >>>>=20 >>>> There are basically two requirements: >>>>=20 >>>> (1). Make sure the PSAP callback call reaches the device that made >> the >>>> associated emergency call (2). PSAP callback indicator >>>>=20 >>>>=20 >>>> I don't think there are any major issues regarding (1). The > Contact >>>> should work, at least for callbacks made not too long after the=20 >>>> emergency call. If the callback is made later, when the Contact > e.g. >>> is >>>> not registered anymore, the PSAP can use the AOR. >>>>=20 >>>>=20 >>>> (2) is where we've had most discussions. >>>>=20 >>>> One question has been whether the UA should provide some nonce >> value, >>>> which is then used in the callback. The UA can check whether the >> nonce >>>> value in the callback is something it has generated - assuming the=20= >>>> callback reaches the same UA that made the emergency call. >>>>=20 >>>> Intermediaires can use the nonce value (or, the protocol element=20 >>>> carrying it) to trigger callback specific procedures, but they > will >>> not >>>> know whether the actual nonce value was created by the UA. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From pkyzivat@alum.mit.edu Tue Feb 21 06:48:13 2012 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 AAA2A21F884B for ; Tue, 21 Feb 2012 06:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhq0LSZnSDim for ; Tue, 21 Feb 2012 06:48:12 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id F121421F8846 for ; Tue, 21 Feb 2012 06:48:11 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta08.westchester.pa.mail.comcast.net with comcast id ceYB1i0080SCNGk58eoCo1; Tue, 21 Feb 2012 14:48:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta09.westchester.pa.mail.comcast.net with comcast id ceoB1i00T07duvL3VeoCZ8; Tue, 21 Feb 2012 14:48:12 +0000 Message-ID: <4F43AEAA.1050902@alum.mit.edu> Date: Tue, 21 Feb 2012 09:48:10 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: ecrit@ietf.org References: <4EDA48A1.7040906@alum.mit.edu><02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu><4EDA584E.2050604@alum.mit.edu><255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu><4EDA74C3.9070603@alum.mit.edu><2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net><4EDCF4A4.60901@alum.mit.edu><4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ABA7@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D0120ABA7@FIESEXC035.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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: Tue, 21 Feb 2012 14:48:13 -0000 On 2/21/12 4:18 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Christer, Hi Brian, > > we had spoken about the Nonce idea in the past (under a different name, > namely the token). > > We also argued that the GRUU could fulfill that purpose. > > The problem with that concept was that it only works when the forward > and the reverse path are the same. In our scenarios (at the beginning of > the draft) we argue that this is not the case. Its irrelevant if the paths are different. What part of When a UAC sends a request that can establish a dialog (such as an INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e., the same SIP URI can be used in messages outside this dialog) in the Contact header field of the request. isn't clear? Its certainly possible that a call to the provided contact will follow a different path than the call from it. But that is not an issue for the ua doing the callback. The most difficult case seems to be when the PSAP is behind a PSTN gateway. In that case the PSAP won't receive the caller's contact address - all it can receive is a phone number. That has various sub-cases: - there is no PSTN phone number assigned to the calling UA Its hard to make callback from a pstn psap work in this case. A possible approach would be for the GW to assign a temporary phone number that maps to the caller's Contact. Then callback by the PSAP to this temporary phone number will be mapped to the original calling contact. If that contact contains an indication that its for an emergency call then the call can be given priority, at least by those that understand the encoding. - there is a PSTN phone number that reaches the UA that made the emergency call. This could be treated like the case where the callback to the contact doesn't work, with fallback to the caller's AOR (the phone number). The limitation is that the callback then looks like a normal call. It would also be possible to use the temporary phone number approach here. > This brought us back to the PSAP callback indicator (which of course > could take many forms, including the Resource Priority Header, or the > stuff we had put in > http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 The problem here is of course one of abuse, unless you have an entirely closed network. But because support for emergency calls is so important, its likely that the network will be more forgiving than normal, leaving it more open to abuse. Thanks, Paul > Ciao > Hannes > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of ext Christer Holmberg >> Sent: Monday, February 20, 2012 1:14 PM >> To: ecrit@ietf.org >> Subject: [Ecrit] PSAP Callback - A New Beginning >> >> >> >> Hi, >> >> We need to try to find a way forward with the PSAP callback issue. >> >> There are basically two requirements: >> >> (1). Make sure the PSAP callback call reaches the device that made the >> associated emergency call >> (2). PSAP callback indicator >> >> >> I don't think there are any major issues regarding (1). The Contact >> should work, at least for callbacks made not too long after the >> emergency call. If the callback is made later, when the Contact e.g. > is >> not registered anymore, the PSAP can use the AOR. >> >> >> (2) is where we've had most discussions. >> >> One question has been whether the UA should provide some nonce value, >> which is then used in the callback. The UA can check whether the nonce >> value in the callback is something it has generated - assuming the >> callback reaches the same UA that made the emergency call. >> >> Intermediaires can use the nonce value (or, the protocol element >> carrying it) to trigger callback specific procedures, but they will > not >> know whether the actual nonce value was created by the UA. >> >> Regards, >> >> Christer >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From pkyzivat@alum.mit.edu Tue Feb 21 07:09:45 2012 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 F30BA21F8820 for ; Tue, 21 Feb 2012 07:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZP-EpmO57k1 for ; Tue, 21 Feb 2012 07:09:39 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1B03A21F8617 for ; Tue, 21 Feb 2012 07:09:38 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta06.westchester.pa.mail.comcast.net with comcast id cf3F1i0080QuhwU56f9fug; Tue, 21 Feb 2012 15:09:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta02.westchester.pa.mail.comcast.net with comcast id cf9f1i00V07duvL3Nf9fvW; Tue, 21 Feb 2012 15:09:39 +0000 Message-ID: <4F43B3B1.8070001@alum.mit.edu> Date: Tue, 21 Feb 2012 10:09:37 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: ecrit@ietf.org References: <4EDA48A1.7040906@alum.mit.edu><02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu><4EDA584E.2050604@alum.mit.edu><255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu><4EDA74C3.9070603@alum.mit.edu><2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net><4EDCF4A4.60901@alum.mit.edu><4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ABA7@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9152FF@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120AD5B@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9153FE@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ADB8@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D915478@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ADEA@FIESEXC035.nsn-intra.ne t> In-Reply-To: <999913AB42CC9341B05A99BBF358718D0120ADEA@FIESEXC035.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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: Tue, 21 Feb 2012 15:09:45 -0000 Ignoring the problem of callback from a PSTN-based psap (which I commented on in earlier message), why isn't the following sufficient: - the caller uses callerprefs to indicate that it doesn't want to talk to an automaton. - the original emergency caller encodes its contact for the emergency call with something *it* understands (e.g. a nonce) that it will subsequently treat as granting priority to an incoming call carrying it. In this way nobody but the calling UA need know the nonce mechanism. It need not be standardized. (And it need not be used at all if the caller is willing to tolerate some priority spit.) The callerprefs will prevent the rest of the infrastructure from diverting the call. This would then be understood to be a mechanism that anybody can use, not just emergency calls. Of course this would require widespread support for callerprefs. But any solution here is going to require widespread support of something. Thanks, Paul On 2/21/12 8:03 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> I am NOT talking about replacing GRUU with the feature tag. GRUU is >> still the preferred way of routing to the UA. >> >> I am just saying that a "side effect" of a feature tag based indicator >> is that it CAN also be used for routing. I am not saying that we shall >> mandate support of feature tag based routing. The main purpose of the >> feature tag is still as indicator. > > But wouldn't it then be sufficient to have just a SIP header field set > by the PSAP when it sends the callback that says "callback"? > > Anything else would just be replicating existing functionality. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From christer.holmberg@ericsson.com Tue Feb 21 07:13:17 2012 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 C3C8421F8861 for ; Tue, 21 Feb 2012 07:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.071 X-Spam-Level: X-Spam-Status: No, score=-10.071 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2QVzAWJlhRo for ; Tue, 21 Feb 2012 07:13:12 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 467CB21F86D9 for ; Tue, 21 Feb 2012 07:13:11 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-6a-4f43b4863b8c Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 77.47.27041.684B34F4; Tue, 21 Feb 2012 16:13:10 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Tue, 21 Feb 2012 16:13:10 +0100 From: Christer Holmberg To: Paul Kyzivat , "ecrit@ietf.org" Date: Tue, 21 Feb 2012 16:13:09 +0100 Thread-Topic: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning Thread-Index: AczwqtrjoEus2wtDQKqIkTSPHCo8iwAAEc8w Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D915595@ESESSCMS0356.eemea.ericsson.se> References: <4EDA48A1.7040906@alum.mit.edu><02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu><4EDA584E.2050604@alum.mit.edu><255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu><4EDA74C3.9070603@alum.mit.edu><2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net><4EDCF4A4.60901@alum.mit.edu><4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ABA7@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9152FF@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120AD5B@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9153FE@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ADB8@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D915478@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ADEA@FIESEXC035.nsn-intra.ne t> <4F43B3B1.8070001@alum.mit.edu> In-Reply-To: <4F43B3B1.8070001@alum.mit.edu> 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] Nonce value -- RE: PSAP Callback - A New Beginning 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: Tue, 21 Feb 2012 15:13:18 -0000 Hi,=20 > Ignoring the problem of callback from a PSTN-based psap (which I commente= d on in earlier message), why isn't the following sufficient: > > - the caller uses callerprefs to indicate that it doesn't want to > talk to an automaton. > > - the original emergency caller encodes its contact for the emergency cal= l with something *it* understands (e.g. a nonce) that it will subsequently = treat as granting priority to an incoming=20 > call carrying it. > > In this way nobody but the calling UA need know the nonce mechanism. It n= eed not be standardized. (And it need not be used at all if the caller is w= illing to tolerate some priority spit.) The=20 > callerprefs will prevent the rest of the infrastructure from diverting th= e call. This would then be understood to be a mechanism that anybody can us= e, not just emergency calls. > > Of course this would require widespread support for callerprefs. But any = solution here is going to require widespread support of something. It is not only the calling UA that needs to know. Intermediaries also need = to identify a callback, in order to give special treatment. Regards, Christer On 2/21/12 8:03 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> I am NOT talking about replacing GRUU with the feature tag. GRUU is=20 >> still the preferred way of routing to the UA. >> >> I am just saying that a "side effect" of a feature tag based=20 >> indicator is that it CAN also be used for routing. I am not saying=20 >> that we shall mandate support of feature tag based routing. The main=20 >> purpose of the feature tag is still as indicator. > > But wouldn't it then be sufficient to have just a SIP header field set=20 > by the PSAP when it sends the callback that says "callback"? > > Anything else would just be replicating existing functionality. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Tue Feb 21 12:48:00 2012 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 BCF9A21F8850 for ; Tue, 21 Feb 2012 12:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rvi2E42K-XVy for ; Tue, 21 Feb 2012 12:47:56 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3687521F855E for ; Tue, 21 Feb 2012 12:47:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=8368; q=dns/txt; s=iport; t=1329857276; x=1331066876; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=ds/m6Mk8SBPL1DrvJ+L3ApnkY8BKQty+m8zaGSYB9DM=; b=HPJ+498w7Y/5jzd2Mt6jlybhhuodrYu+UAAZa46jX4PaK12xwiJy9Oog H7iGjf7iDEKdAlGlIPfaQe9fjg43gqITmyKNmln+Kqb4YJxprrgtZsmve 45F+lhh42DaEizys2Dzn3OlCELmZ6erDlvT11ZFl2mPd748Bk7ioYHqPh w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGcCRE+rRDoJ/2dsb2JhbAA5CQ6yOYEHgXMBAQEEAQEBDwElAjQLDAQHBA4DBAEBAR4JBxkOHwkIBgESIodnoA8BlzWJXIIZAQcCAw4bAgYDBQ0Gg3gCKwgHCoJQYwSIT58fVg X-IronPort-AV: E=Sophos;i="4.73,459,1325462400"; d="scan'208";a="29822898" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 21 Feb 2012 20:47:54 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1LKlsnD005202; Tue, 21 Feb 2012 20:47:54 GMT Message-Id: <201202212047.q1LKlsnD005202@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 21 Feb 2012 14:47:52 -0600 To: Henning Schulzrinne , Christer Holmberg From: "James M. Polk" In-Reply-To: References: <4EDA48A1.7040906@alum.mit.edu> <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> <4EDA584E.2050604@alum.mit.edu> <255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu> <4EDA74C3.9070603@alum.mit.edu> <2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net> <4EDCF4A4.60901@alum.mit.edu> <4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ABA7@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9152FF@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120AD5B@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9153FE@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ADB8@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D915478@ESESSCMS0356.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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: Tue, 21 Feb 2012 20:48:00 -0000 At 07:03 AM 2/21/2012, Henning Schulzrinne wrote: >The problem with any "this is an emergency call back" tags is that >anybody can insert them and thus invoke whatever the callback >identifier is meant to change in terms of call handling. and we don't want to give telemarketers any more weapons to get through to us ... :-( >Thus, only nonce-based mechanisms provide protection against such >attacks. With that, the question is which caller-chosen identifiers >or nonces can survive the round trip. Once you make the environment >sufficiently hostile (SBCs, tel URIs, no changes in UAs, etc.), not >much, unfortunately. > >Henning > >On Feb 21, 2012, at 7:59 AM, Christer Holmberg wrote: > > > > > Hi, > > > >> we are introducing new functionality to get the PSAP callback > functionality to work and this requires changes to SIP UAs and to > proxies. Existing devices clearly do not support this > >> functionality yet. > >> > >> So, the argument that GRUU is not supported by certain SIP UAs > is correct but not relevant. > >> > >> Am I missing something? > > > > I am NOT talking about replacing GRUU with the feature tag. GRUU > is still the preferred way of routing to the UA. > > > > I am just saying that a "side effect" of a feature tag based > indicator is that it CAN also be used for routing. I am not saying > that we shall mandate support of feature tag based routing. The > main purpose of the feature tag is still as indicator. > > > > Regards, > > > > Christer > > > > > > > > > > > >> -----Original Message----- > >> From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >> Sent: Tuesday, February 21, 2012 2:15 PM > >> To: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org > >> Subject: RE: Nonce value -- RE: [Ecrit] PSAP Callback - A New > > Beginning > >> > >> > >> Hi, > >> > >>> thanks for the clarification. > >>> > >>> But wouldn't we essentially re-implement parts of the GRUU > >> functionality with this specific feature tag? > >> > >> As far as reaching the UA, yes, but the main purpose is to provide the > >> callback indicator. > >> > >> (Also keep in mind that not every UA support GRUU.) > >> > >>> I was proposing earlier to use the GRUU (when available) for the > >> purpose of reaching the calling device. > >>> Then, in addition there was the actual callback marking, see > >>> > > http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02#section-4 > >> > >> I am only focusing on the callback marking. But, again, a feature tag > >> may also help in reaching the terminal (in cases where GRUU is not > > used, > >> AND the home registrar supports feature capabilities). > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> > >> > >> > >> Finally, there was the security related functionality of which I > > believe > >> only the identity-based authorization is practical. Richard had > > proposed > >> another mechanism based on LoST, which I found worthwhile to explore > > as > >> well. > >> > >> Ciao > >> Hannes > >> > >> > >>> -----Original Message----- > >>> From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>> Sent: Tuesday, February 21, 2012 12:47 PM > >>> To: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org > >>> Subject: RE: Nonce value -- RE: [Ecrit] PSAP Callback - A New > >> Beginning > >>> > >>> > >>> Hi Hannes, > >>> > >>> When I have been talking about the nonce, I have been talking about > >> the > >>> indicator. But, in order to avoid confusion, until we have decided > > how > >>> to implement it, let's talk about the indicator :) > >>> > >>> Then, how to implement it? > >>> > >>> One alternative would be to use a media feature tag, e.g. > > +g.sip.emg. > >>> The feature tag could also contain a nonce value, created by the UA. > >> For > >>> example: +g.sip.emg=6fdxtg4es6 > >>> > >>> The UA would register the feature tag with its registrar. That way, > >> the > >>> home network would be aware of the value. > >>> > >>> The UA, when making an emg call, would include the feature tag in > > the > >>> Contact header field of the INVITE. > >>> > >>> The PSAP, when making a callback, would include the feature tag in > > the > >>> Accept-Contact header field of the INVITE. In addition to acting as > > a > >>> callback indicator, the feature tag would help in finding the > > correct > >> UA > >>> (e.g. if GRUU is not supported). > >>> > >>> The home network can also compare the value with the registered > > value. > >>> And, if they don't match, the home network could reject the request, > >> or > >>> don't give callback processing, based on network policy. > >>> > >>> (Another alternative would be to define a URI parameter, used in the > >>> Contact of the emg call INVITE, and in the R-URI of the callback > >> INVITE. > >>> The problem, however, is that the R-URI is overwritten by the home > >>> network. If History-Info is supported, it would be put there, but > > then > >>> entities (and the UA) would have to scan through the History-Info > >> list.) > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Tschofenig, Hannes (NSN - FI/Espoo) > >>> [mailto:hannes.tschofenig@nsn.com] > >>> Sent: 21. helmikuuta 2012 11:18 > >>> To: Christer Holmberg; ecrit@ietf.org > >>> Subject: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning > >>> > >>> Hi Christer, Hi Brian, > >>> > >>> we had spoken about the Nonce idea in the past (under a different > >> name, > >>> namely the token). > >>> > >>> We also argued that the GRUU could fulfill that purpose. > >>> > >>> The problem with that concept was that it only works when the > > forward > >>> and the reverse path are the same. In our scenarios (at the > > beginning > >> of > >>> the draft) we argue that this is not the case. > >>> > >>> This brought us back to the PSAP callback indicator (which of course > >>> could take many forms, including the Resource Priority Header, or > > the > >>> stuff we had put in > >>> http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 > >>> > >>> Ciao > >>> Hannes > >>> > >>> > >>>> -----Original Message----- > >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> Behalf > >>>> Of ext Christer Holmberg > >>>> Sent: Monday, February 20, 2012 1:14 PM > >>>> To: ecrit@ietf.org > >>>> Subject: [Ecrit] PSAP Callback - A New Beginning > >>>> > >>>> > >>>> > >>>> Hi, > >>>> > >>>> We need to try to find a way forward with the PSAP callback issue. > >>>> > >>>> There are basically two requirements: > >>>> > >>>> (1). Make sure the PSAP callback call reaches the device that made > >> the > >>>> associated emergency call (2). PSAP callback indicator > >>>> > >>>> > >>>> I don't think there are any major issues regarding (1). The > > Contact > >>>> should work, at least for callbacks made not too long after the > >>>> emergency call. If the callback is made later, when the Contact > > e.g. > >>> is > >>>> not registered anymore, the PSAP can use the AOR. > >>>> > >>>> > >>>> (2) is where we've had most discussions. > >>>> > >>>> One question has been whether the UA should provide some nonce > >> value, > >>>> which is then used in the callback. The UA can check whether the > >> nonce > >>>> value in the callback is something it has generated - assuming the > >>>> callback reaches the same UA that made the emergency call. > >>>> > >>>> Intermediaires can use the nonce value (or, the protocol element > >>>> carrying it) to trigger callback specific procedures, but they > > will > >>> not > >>>> know whether the actual nonce value was created by the UA. > >>>> > >>>> Regards, > >>>> > >>>> Christer > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Wed Feb 22 00:40:46 2012 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 5D08021F880F for ; Wed, 22 Feb 2012 00:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.081 X-Spam-Level: X-Spam-Status: No, score=-10.081 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ti8TWABiEGoj for ; Wed, 22 Feb 2012 00:40:45 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C099621F87EB for ; Wed, 22 Feb 2012 00:40:44 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-5b-4f44aa0bd650 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6D.F3.01970.B0AA44F4; Wed, 22 Feb 2012 09:40:43 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 22 Feb 2012 09:40:43 +0100 From: Christer Holmberg To: "James M. Polk" , Henning Schulzrinne Date: Wed, 22 Feb 2012 09:40:42 +0100 Thread-Topic: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning Thread-Index: Aczw2hhKko/oQL9mTgiURHYzAua1VAAY3MsA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D915859@ESESSCMS0356.eemea.ericsson.se> References: <4EDA48A1.7040906@alum.mit.edu> <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> <4EDA584E.2050604@alum.mit.edu> <255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu> <4EDA74C3.9070603@alum.mit.edu> <2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net> <4EDCF4A4.60901@alum.mit.edu> <4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ABA7@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9152FF@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120AD5B@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9153FE@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ADB8@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D915478@ESESSCMS0356.eemea.ericsson.se> <201202212047.q1LKlsnD005202@mtv-core-4.cisco.com> In-Reply-To: <201202212047.q1LKlsnD005202@mtv-core-4.cisco.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== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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, 22 Feb 2012 08:40:46 -0000 Hi, In many networks the PSAP identity could be asserted, to ensure that the ca= ll doesn't come from "anyone". Regards, Christer =20 -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: 21. helmikuuta 2012 22:48 To: Henning Schulzrinne; Christer Holmberg Cc: ecrit@ietf.org Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning At 07:03 AM 2/21/2012, Henning Schulzrinne wrote: >The problem with any "this is an emergency call back" tags is that=20 >anybody can insert them and thus invoke whatever the callback=20 >identifier is meant to change in terms of call handling. and we don't want to give telemarketers any more weapons to get through to = us ... :-( >Thus, only nonce-based mechanisms provide protection against such=20 >attacks. With that, the question is which caller-chosen identifiers or=20 >nonces can survive the round trip. Once you make the environment=20 >sufficiently hostile (SBCs, tel URIs, no changes in UAs, etc.), not=20 >much, unfortunately. > >Henning > >On Feb 21, 2012, at 7:59 AM, Christer Holmberg wrote: > > > > > Hi, > > > >> we are introducing new functionality to get the PSAP callback > functionality to work and this requires changes to SIP UAs and to=20 > proxies. Existing devices clearly do not support this > >> functionality yet. > >> > >> So, the argument that GRUU is not supported by certain SIP UAs > is correct but not relevant. > >> > >> Am I missing something? > > > > I am NOT talking about replacing GRUU with the feature tag. GRUU > is still the preferred way of routing to the UA. > > > > I am just saying that a "side effect" of a feature tag based > indicator is that it CAN also be used for routing. I am not saying=20 > that we shall mandate support of feature tag based routing. The main=20 > purpose of the feature tag is still as indicator. > > > > Regards, > > > > Christer > > > > > > > > > > > >> -----Original Message----- > >> From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >> Sent: Tuesday, February 21, 2012 2:15 PM > >> To: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org > >> Subject: RE: Nonce value -- RE: [Ecrit] PSAP Callback - A New > > Beginning > >> > >> > >> Hi, > >> > >>> thanks for the clarification. > >>> > >>> But wouldn't we essentially re-implement parts of the GRUU > >> functionality with this specific feature tag? > >> > >> As far as reaching the UA, yes, but the main purpose is to provide=20 > >> the callback indicator. > >> > >> (Also keep in mind that not every UA support GRUU.) > >> > >>> I was proposing earlier to use the GRUU (when available) for the > >> purpose of reaching the calling device. > >>> Then, in addition there was the actual callback marking, see > >>> > > http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02#section > > -4 > >> > >> I am only focusing on the callback marking. But, again, a feature=20 > >> tag may also help in reaching the terminal (in cases where GRUU is=20 > >> not > > used, > >> AND the home registrar supports feature capabilities). > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> > >> > >> > >> Finally, there was the security related functionality of which I > > believe > >> only the identity-based authorization is practical. Richard had > > proposed > >> another mechanism based on LoST, which I found worthwhile to=20 > >> explore > > as > >> well. > >> > >> Ciao > >> Hannes > >> > >> > >>> -----Original Message----- > >>> From: ext Christer Holmberg=20 > >>> [mailto:christer.holmberg@ericsson.com] > >>> Sent: Tuesday, February 21, 2012 12:47 PM > >>> To: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org > >>> Subject: RE: Nonce value -- RE: [Ecrit] PSAP Callback - A New > >> Beginning > >>> > >>> > >>> Hi Hannes, > >>> > >>> When I have been talking about the nonce, I have been talking=20 > >>> about > >> the > >>> indicator. But, in order to avoid confusion, until we have decided > > how > >>> to implement it, let's talk about the indicator :) > >>> > >>> Then, how to implement it? > >>> > >>> One alternative would be to use a media feature tag, e.g. > > +g.sip.emg. > >>> The feature tag could also contain a nonce value, created by the UA. > >> For > >>> example: +g.sip.emg=3D6fdxtg4es6 > >>> > >>> The UA would register the feature tag with its registrar. That=20 > >>> way, > >> the > >>> home network would be aware of the value. > >>> > >>> The UA, when making an emg call, would include the feature tag in > > the > >>> Contact header field of the INVITE. > >>> > >>> The PSAP, when making a callback, would include the feature tag in > > the > >>> Accept-Contact header field of the INVITE. In addition to acting=20 > >>> as > > a > >>> callback indicator, the feature tag would help in finding the > > correct > >> UA > >>> (e.g. if GRUU is not supported). > >>> > >>> The home network can also compare the value with the registered > > value. > >>> And, if they don't match, the home network could reject the=20 > >>> request, > >> or > >>> don't give callback processing, based on network policy. > >>> > >>> (Another alternative would be to define a URI parameter, used in=20 > >>> the Contact of the emg call INVITE, and in the R-URI of the=20 > >>> callback > >> INVITE. > >>> The problem, however, is that the R-URI is overwritten by the home=20 > >>> network. If History-Info is supported, it would be put there, but > > then > >>> entities (and the UA) would have to scan through the History-Info > >> list.) > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Tschofenig, Hannes (NSN - FI/Espoo)=20 > >>> [mailto:hannes.tschofenig@nsn.com] > >>> Sent: 21. helmikuuta 2012 11:18 > >>> To: Christer Holmberg; ecrit@ietf.org > >>> Subject: Nonce value -- RE: [Ecrit] PSAP Callback - A New=20 > >>> Beginning > >>> > >>> Hi Christer, Hi Brian, > >>> > >>> we had spoken about the Nonce idea in the past (under a different > >> name, > >>> namely the token). > >>> > >>> We also argued that the GRUU could fulfill that purpose. > >>> > >>> The problem with that concept was that it only works when the > > forward > >>> and the reverse path are the same. In our scenarios (at the > > beginning > >> of > >>> the draft) we argue that this is not the case. > >>> > >>> This brought us back to the PSAP callback indicator (which of=20 > >>> course could take many forms, including the Resource Priority=20 > >>> Header, or > > the > >>> stuff we had put in > >>> http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 > >>> > >>> Ciao > >>> Hannes > >>> > >>> > >>>> -----Original Message----- > >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> Behalf > >>>> Of ext Christer Holmberg > >>>> Sent: Monday, February 20, 2012 1:14 PM > >>>> To: ecrit@ietf.org > >>>> Subject: [Ecrit] PSAP Callback - A New Beginning > >>>> > >>>> > >>>> > >>>> Hi, > >>>> > >>>> We need to try to find a way forward with the PSAP callback issue. > >>>> > >>>> There are basically two requirements: > >>>> > >>>> (1). Make sure the PSAP callback call reaches the device that=20 > >>>> made > >> the > >>>> associated emergency call (2). PSAP callback indicator > >>>> > >>>> > >>>> I don't think there are any major issues regarding (1). The > > Contact > >>>> should work, at least for callbacks made not too long after the=20 > >>>> emergency call. If the callback is made later, when the Contact > > e.g. > >>> is > >>>> not registered anymore, the PSAP can use the AOR. > >>>> > >>>> > >>>> (2) is where we've had most discussions. > >>>> > >>>> One question has been whether the UA should provide some nonce > >> value, > >>>> which is then used in the callback. The UA can check whether the > >> nonce > >>>> value in the callback is something it has generated - assuming=20 > >>>> the callback reaches the same UA that made the emergency call. > >>>> > >>>> Intermediaires can use the nonce value (or, the protocol element=20 > >>>> carrying it) to trigger callback specific procedures, but they > > will > >>> not > >>>> know whether the actual nonce value was created by the UA. > >>>> > >>>> Regards, > >>>> > >>>> Christer > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From hgs@cs.columbia.edu Wed Feb 22 06:04:48 2012 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 BDD6821F8690 for ; Wed, 22 Feb 2012 06:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ0GVgUZf+SH for ; Wed, 22 Feb 2012 06:04:44 -0800 (PST) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id A72CF21F865C for ; Wed, 22 Feb 2012 06:04:44 -0800 (PST) Received: from [10.0.0.4] (c-98-218-140-58.hsd1.va.comcast.net [98.218.140.58]) (user=hgs10 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q1ME4eYJ000157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Feb 2012 09:04:41 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D915859@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 22 Feb 2012 09:04:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3D0A12D0-B1C3-4EEC-B42D-9989E2C273F5@cs.columbia.edu> References: <4EDA48A1.7040906@alum.mit.edu> <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> <4EDA584E.2050604@alum.mit.edu> <255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu> <4EDA74C3.9070603@alum.mit.edu> <2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net> <4EDCF4A4.60901@alum.mit.edu> <4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ABA7@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9152FF@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120AD5B@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9153FE@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ADB8@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D915478@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D915859@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1257) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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, 22 Feb 2012 14:04:48 -0000 Given that there are 6000+ PSAPs in the US, this is likely to be = challenging. (We have proposed a mechanism, = http://datatracker.ietf.org/doc/draft-ono-dispatch-attribute-validation/, = that would make something like that relatively easy, since there's a US = PSAP registry maintained by the FCC, but this does require some changes = in UA.) On Feb 22, 2012, at 3:40 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > In many networks the PSAP identity could be asserted, to ensure that = the call doesn't come from "anyone". >=20 > Regards, >=20 > Christer From br@brianrosen.net Wed Feb 22 06:25:25 2012 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 6741221F869A for ; Wed, 22 Feb 2012 06:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgVOP3pO8tVd for ; Wed, 22 Feb 2012 06:25:21 -0800 (PST) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 7013A21F8682 for ; Wed, 22 Feb 2012 06:25:21 -0800 (PST) X-ASG-Debug-ID: 1329920712-04d0354d100fd40001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id EWnulj8TdlsDPurv; Wed, 22 Feb 2012 06:25:12 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.45]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1S0D83-003DnD-Tz; Wed, 22 Feb 2012 06:25:12 -0800 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <3D0A12D0-B1C3-4EEC-B42D-9989E2C273F5@cs.columbia.edu> Date: Wed, 22 Feb 2012 09:25:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0E11220B-E41F-43B8-8C40-29510625105A@brianrosen.net> References: <4EDA48A1.7040906@alum.mit.edu> <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> <4EDA584E.2050604@alum.mit.edu> <255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu> <4EDA74C3.9070603@alum.mit.edu> <2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net> <4EDCF4A4.60901@alum.mit.edu> <4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ABA7@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9152FF@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120AD5B@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D9153FE@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718D0120ADB8@FIESEXC035.nsn-intra.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D915478@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C3D915859@ESESSCMS0356.eemea.ericsson.se> <3D0A12D0-B1C3-4EEC-B42D-9989E2C273F5@cs.columbia.edu> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1329920712 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.89202 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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, 22 Feb 2012 14:25:25 -0000 The US PSAP registry maintained by the FCC is generally thought of the = weakest of the available listings, primarily because: a) It has more missing PSAPs than the other available registries b) It doesn't differentiate between primary and secondary PSAPs (and = there are more than 6000 primary PSAPs). Primary PSAPs answer 9-1-1 = calls and may dispatch. Secondary PSAPs only dispatch responders. A = call dispatched by a secondary PSAP is answered initially by a primary = PSAP. There are several other registries that are better. The NENA registry = is better, but the commercial database is probably the best. None are = super accurate. NENA thinks a PKI for primary PSAPs is practical and is working on the = CP for it now. 6000 is not a very big number, and if you do it national = to state to regional hierarchy, you can get good quality credentials. We need PSAP credentials to allow LIS operators to obscure location for = non emergency use. I think assuming some reasonable credential is acceptable. Brian On Feb 22, 2012, at 9:04 AM, Henning Schulzrinne wrote: > Given that there are 6000+ PSAPs in the US, this is likely to be = challenging. (We have proposed a mechanism, = http://datatracker.ietf.org/doc/draft-ono-dispatch-attribute-validation/, = that would make something like that relatively easy, since there's a US = PSAP registry maintained by the FCC, but this does require some changes = in UA.) >=20 > On Feb 22, 2012, at 3:40 AM, Christer Holmberg wrote: >=20 >>=20 >> Hi, >>=20 >> In many networks the PSAP identity could be asserted, to ensure that = the call doesn't come from "anyone". >>=20 >> Regards, >>=20 >> Christer >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From mserra@ravemobilesafety.com Wed Feb 22 14:29:43 2012 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 DC4A221E804B for ; Wed, 22 Feb 2012 14:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVHUPRn67QNO for ; Wed, 22 Feb 2012 14:29:41 -0800 (PST) Received: from server505.appriver.com (server505d.appriver.com [98.129.35.8]) by ietfa.amsl.com (Postfix) with ESMTP id A11ED21E8015 for ; Wed, 22 Feb 2012 14:29:40 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/22/2012 4:29:40 PM X-Note-AR-Scan: None - PIPE Received: by server505.appriver.com (CommuniGate Pro PIPE 5.4.3k) with PIPE id 259197822; Wed, 22 Feb 2012 16:29:40 -0600 Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.3k) with ESMTPS id 259197816 for ecrit@ietf.org; Wed, 22 Feb 2012 16:29:39 -0600 Received: from MBX05.exg5.exghost.com ([169.254.1.17]) by HT05.exg5.exghost.com ([98.129.23.150]) with mapi; Wed, 22 Feb 2012 16:29:38 -0600 From: Matt Serra To: "ecrit@ietf.org" Date: Wed, 22 Feb 2012 16:29:27 -0600 Thread-Topic: Input on ECRIT Additional Data Draft from the NENA Add'l Data Work Group Thread-Index: AczxsEsLKUGWhYB3RpuYXL5Gfr5qpAAAPmQQ Message-ID: <6B92B1E73D1E7B468E5C97CAE569CBA1068A2F8B6B@MBX05.exg5.exghost.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_6B92B1E73D1E7B468E5C97CAE569CBA1068A2F8B6BMBX05exg5exgh_" MIME-Version: 1.0 X-Note-AR-ScanTimeLocal: 2/22/2012 4:29:39 PM X-Policy: GLOBAL - ravemobilesafety.com X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @ravemobilesafety.com ALLOWED X-Note: VCH-CT/SI:0-1762/SG:1 2/22/2012 4:29:17 PM X-Virus-Scan: V-X0M0 X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: X-Note-Return-Path: mserra@ravemobilesafety.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G222 G223 G224 G225 G229 G230 G241 G332 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER Subject: [Ecrit] Input on ECRIT Additional Data Draft from the NENA Add'l Data Work Group 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, 22 Feb 2012 22:29:44 -0000 --_004_6B92B1E73D1E7B468E5C97CAE569CBA1068A2F8B6BMBX05exg5exgh_ Content-Type: multipart/alternative; boundary="_000_6B92B1E73D1E7B468E5C97CAE569CBA1068A2F8B6BMBX05exg5exgh_" --_000_6B92B1E73D1E7B468E5C97CAE569CBA1068A2F8B6BMBX05exg5exgh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Resubmitting due to file size restrictions] I am submitting the attached Microsoft Word document on behalf of NENA's Ad= ditional Data WG. This feedback is submitted against http://tools.ietf.org= /html/draft-ietf-ecrit-additional-data-02, and includes the Additional Data= WG's findings upon reviewing V02 of the Additional Data draft. Should you have follow up questions, or prefer to receive this material in = a different format, please let me know. Thank you, Matt Serra Matthew A. Serra, ENP Sr. Director, Product Management Rave Mobile Safety | Smart911 Mobile: 201.245.1557 mserra@ravemobilesafety.com --_000_6B92B1E73D1E7B468E5C97CAE569CBA1068A2F8B6BMBX05exg5exgh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Resubmitting du= e to file size restrictions]

 =

I am submitting the attached Microsoft Word = document on behalf of NENA’s Additional Data WG.  This feedback = is submitted against http://tools.ietf.org/html/draft-ietf-ecrit-additional= -data-02, and includes the Additional Data WG’s findings upon rev= iewing V02 of the Additional Data draft.

 

Should you have follow up questi= ons, or prefer to receive this material in a different format, please let m= e know.

 

Thank you,

 

Matt Serra

&= nbsp;

Matthew A. Serra, ENP
Sr. Director, Produ= ct Management
Rave Mobile Safety | Smart911
Mobile:  201.2= 45.1557
mserra@ravemobile= safety.com

=  

= --_000_6B92B1E73D1E7B468E5C97CAE569CBA1068A2F8B6BMBX05exg5exgh_-- --_004_6B92B1E73D1E7B468E5C97CAE569CBA1068A2F8B6BMBX05exg5exgh_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="NENA Recommendations to ECRIT Addl Data DRAFT_20120222.docx" Content-Description: NENA Recommendations to ECRIT Addl Data DRAFT_20120222.docx Content-Disposition: attachment; filename="NENA Recommendations to ECRIT Addl Data DRAFT_20120222.docx"; size=30348; creation-date="Wed, 22 Feb 2012 21:20:48 GMT"; modification-date="Wed, 22 Feb 2012 22:14:39 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDa845ZvAEAADEIAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lU1r20AQhu+F/gex12Ktk0MpxXIO+TimgbrQ63p3ZC/dL3bGSfzvO5IjURJHohG6CITY53133pnR 6urZu+IRMtoYKnFRLkUBQUdjw64SvzZ3i2+iQFLBKBcDVOIIKK7Wnz+tNscEWPDpgJXYE6XvUqLe g1dYxgSBv9Qxe0X8mncyKf1H7UBeLpdfpY6BINCCGoZYr36wgWwNFA8q073yrCOfYjayjpFCJMCS caK4Pp1rpCuhUnJWK2Lj8jGYV6KLWNdWg4n64FmqbHApRw2IfDXvyh79pUHL8yb0ASn6395JS+Af ckx4MdlKD214kMkCdh5uoFYHR8XtM9fnFEkGh/9385dSl3yyrQ7ubRpSGC7tQHXaiPoKD2M+kFBP 9sqGrkLvtko4+C1kznZyPm9apUePmkA6ujma9cQdlYdgZpqWjjxkgfNqJ0TyZE4OAZoJMGAWPLSv huTdFkAg4gaYYVl05KHr9wsL8vQd8aYHm3UFeVSfeAGDbJ/TTbSYUcmal/JGbR1MzvzMpV/Qoyae YPtztvT/gY8a2YMyszTACTyk38+fjvkDYXS/jeb0mamT7Q9//RcAAP//AwBQSwMEFAAGAAgAAAAh AB6RGrfzAAAATgIAAAsACAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMkttKA0EMhu8F32HIfTfbCiLS2d5I oXci6wOEmewBdw7MpNq+vaMgulDbXub058tP1puDm9Q7pzwGr2FZ1aDYm2BH32t4bbeLB1BZyFua gmcNR86waW5v1i88kZShPIwxq6Lis4ZBJD4iZjOwo1yFyL5UupAcSQlTj5HMG/WMq7q+x/RXA5qZ ptpZDWln70C1x1g2X9YOXTcafgpm79jLiRXIB2Fv2S5iKmxJxnKNain1LBpsMM8lnZFirAo24Gmi 1fVE/1+LjoUsCaEJic/zfHWcA1peD3TZonnHrzsfIVksFn17+0ODsy9oPgEAAP//AwBQSwMEFAAG AAgAAAAhAC3P/4VUAQAATgYAABwACAF3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzIKIEASig AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArFXLTsMwELwj8Q+R78RpgfJQ014QUq8QJK6u s3mI2I7sLZC/Z2lVN6WVufhiaSfKzGh2vZ4vv1WXfIJ1rdE5m6QZS0BLU7a6ztlb8Xx1zxKHQpei MxpyNoBjy8XlxfwFOoH0k2va3iXEol3OGsT+kXMnG1DCpaYHTV8qY5VAKm3NeyE/RA18mmUzbscc bHHEmazKnNlVSfrF0JPy/9ymqloJT0ZuFGg8I8EbECVYYhS2BiTObT1JySTj5/WvY+o7HDoK0Ovv 6pD8XUx50KU2ODawR0IWpjEt6I1ag6XpOoTgoZCJSUwTcuPQqHdquu9EmnKP8hZBBYdiFtNNZQz+ aYuHgpFEzQTpysIhj23Jt2cwiduYSXzB+hUQaTpGd2QEBtOgzRVvUVRGYyHW3SgRD4Vc3MQ04U6y 2CMhCw8xLfwO4nhh7mo/EfzoFVj8AAAA//8DAFBLAwQUAAYACAAAACEAAhN9dGssAABpBwEAEQAA AHdvcmQvZG9jdW1lbnQueG1s7F3bcttIer5PVd6hSxcbT5Vli9TJ1q45RZPSjLK2RyXJmSR3EAmK iEGCAUDJnKt5h9xkq3Zv8mjzJPn+v7vB7kaDgA42qRnvYcYmwUb3fz73X77/PInFTZhmUTJ9s9V6 sbMlwukgGUbT6zdbHy9Ptl9tiSwPpsMgTqbhm61FmG193/nnf/rL7dEwGcwn4TQXWGKaHd3g23Ge z45evswG43ASZC+SWTjFl6MknQQ5/ppev5wE6af5bHuQTGZBHl1FcZQvXrZ3dg621DLJm615Oj1S S2xPokGaZMkop58cJaNRNAjVv/Qv0ibvlb/sqy3zG1+mYYw9JNNsHM0yvdrkvqvhiGO9yM2qQ9xM Yv3c7azJ24ZpcAt8TGK57dskHc7SZBBmGT7tyy+LFVs7q96tAEhLFL9osgX7nXonkyCaFssQdTj4 L5D3Ash7Kd/9kpZaHgSw6ICWrpLhgv49E7dHoMXh+ZutnZ3Dw/ZJ+2RLf3QGRJc+7IejYB7n5W/O jI945bOU/pXKf1297Pzlpfob/j1TX3pfVfGz26O8s/tC9II43j6djhJxMQsHEeiTaYpWz+U7+J+z L3u6tHLneedyHIo4mF7Pg+tQRFORj6NMZOGASN/aJuBRuYwHbjgg8exRNgsGwP0sDbMwvQm3OqLx qnknmg4JYmGGbYWiH96Av5+L7oCoW5ylyU00DNPnAgJInE7zMJ2EwyhIFyIMBmPxvvsfApxAz8hT RcDDC/ftBPmqnYrLRFyF7oaxZjI6Tgka+WKGs12nweQiD9J8C3QDMPGSnXCazdPQeZ33t8fTofnL CrDxmQagJwEEBQOWkdMoHIqrhQhyEYdBlgtIYSCRRPIgFMmI6U8Mgzx4Lm5DkYb4FYTyUEyTHNLh yNodUfr66PC3X//P2s0qcssD4tBKvEk6yeiQLu4kbvwQnufQN78ALCIo/ayS8itIh2gdtKrpLy0t uGL7eSJmMZgG22B0NwdLZzIHDWiaj3Lrl170tvt7x7utRxKi1fIh79wdvdivlMmSnX4ehyngCS4j uiZxQMB5zn/KrIOupJyOi5j3Hy8uC5AF4irIooF4KSbRNJoEMbNMOrTW9wLS0UarFc/B/uHbvfYW M1ut4vG/bmf3ZPewwJvxOhujrOeM1zkoUg/TRvwivNOH7CgkrTjtW5DQGCprTfBmx5Yu6tkKfhE2 g3jPbJ/sfPWZDyWADBDPLvJFHIKRb4L4zda7KMvPgjSA7J6NpfSdzifyIFF8E+vndorvTof6sz36 DFtUP6DNKixKUiWVOs9Yn2bit1//PkigxkifBvFvv/5DLMKcqTadx1BsyTReiGE4iiC5A3o6Gyfz eIgHXwiI7ynJbc3RV2EOJSeu59FQCnh8Ow6Vzr6NoBqgrWbJbA7LNRx+L8RP4JP0NsqgNOWyIsrp GbwmmRU7+t5FqpZ2ZCTtHbT2Dg+ZVitxdxam42CWicEYhgQJUGLPURLHCVmmAgItSyYhLAv8JY4+ 8fsbvFNvQ5p25kY6701BR2877YtIioWS6IW6jBOyIoDAiDYBOP/XPI0y2BYEA0GGao7/0/ayOSyH 0/5vv/4tewEcWLv8ElQJCwfHjMMRjNTW3p4iN8WM6UkyzTN8H2SDKHqz1UuwbRDAh/CWWH/cnWbl TweZ/SBryuwXPM+E3zqQFJ390qOVjc9wPH6vQc94gO1tiYHXu4eHvWMmhbVukITLJZmpZNiIix9/ +viuz5Qvjb2hpgTCemyh2kKnLb3WA+tKG8aWh9jq5qJCsw/cBmIeiCwwYwz5atvaXu7Z29l9ddAr 9JjidPh13b3iQ0PQK6muYCGduLUIehsbe3LDWvqDMkdRGIMOM9gR7IeLUZpMpK3C0Y8moJGCV7/J gIKShCYUDOGodBH5XSTQIDxGUBqQLm1EbyBqoGjebLUhadRfzqGG3mwF8zyRgqGCtbtpFCAyUUid 4u8kb+RfWNJcOfKmzdry9siUN/IzV974CcSGgiSQk5P9vVbXRyAbDZqlEG4OlBLnq7MbJpsruQrM KP1Q/P3BmCLBeweD8KtuzO/TiUt46K7UBxEbWm3dAC2ZyV9qe3chv2q9ZCsmL88etPdOdr3y+0uy J21FmeE2BA3ZqOyGauk8mKcpBa0RVB3lMrA0DBFHUBEoiveQ+wkFp2zywqYkI9TlDfEsfHH9Qnw4 /tAVPYppTxf46XcbK/w1CL1YtXVvjftluJwaKWUnUb/ONsRIgeAbpYYqfI4eDONgkIuP56dHj+47 9g533r56bbrnj+c7svWN45V9R5toDc+cY7SIfcCaCAQoMJFh2lD8+/t3IoxDyrLAVzzNEawIhngo E3+K8z87Uq8UecxmYRybYcsVGyBwp4A3wN1o2WVEc8Wif7rO/yz9Vzilyj2lE3ypA3yJ/VvQ8LJN d6/da+8Wtoo0YJwPDdvODnKwhfsVybFgO1d1f3XPk21pv07/WTrxJHARx+iH2SCNOJhBwRULITiO pj8KZSioSzPdCofbkVLnZ/u9/d7JzqoICHZyE6RRMs/EDEmIeS4Th6QpEPthQUW5B8pzUrwBAZhB jOehhoZg3KZb9kPjJElF+DmYzGIEeVQ0iDI6CATntwi8QDggZQv9FUCEMHvlyTViMZQ3Ad+RixIs OFSObSVXN3wKfI2kAv9gFKapCuLQeohXhMjbQimCZwfhlI6dlQ/RXNoQYkwIU0LKgYh/sbKMcZfy A0wHDICCeVZK7lQSjH+xW4rVAaFTBPAQWVvgjwQsFaiTYb3hSgwrY0kSJSWyKEkzHUSxClex0wg6 54AiUTgvyuFEB0zW1i2QNjA4bLlzXiembAH2TUx58pzA2Y/JrfiYyRSdgyw/TZvqWFJED0mOPPgU po1+v+QJ+WuiF2Lv2yBNA3CsEjsyCQ2ufS+zHIhAkzSl3DtHoPN0PsiRvKSfK8UM4ZCGk+QGhylC GRADOhejxYyzy4IkLXqSeyv5PfRxRfDh66ifaqen6lgkcVZxzuYeySRNojFxSUQGWxopb62ziCac kw9DyoxEQxx8C39A1GicILY0QdA9DegThGQpvLTTam/v4H+Hlzuvj/Z3jnZ2/lPGjU19vApy6rl+ iFyNlYRYM4UAAJfh5wqvJJvPZjEF6KH4CXDqYenP8D/xCdEEUvQ4IIGRc68PA6Ph364ZOBVgga2A Oi6IGJQpEG2lScwVDFTEgdyQRWKAGoDDfNOUVDaXyTwMtMR8++EMtPGYh5aj8hvHAvpd4TgY6tyu Tcgmk7P79ztnclYiFaxcMnbciqmnz+rQe6WqIe+xCxMNqkDpAA6VPow8nrAq7SghkaKSWNmdK3Vn YVM+BeOr08D1soPiZmDVkO8Pi6JeEdBkseIMdSmU6IMQTvmf5Zo/h5hWR6fUw6SEH7ZHClmcw6VA mdfwDJt8i2DFJ04mukmnd6pc9Vn2nbiAyZWkqO2wRI8TwTECP8pCahRkFtuuSAfEqp2E0sOmVDO2 kHc+RHllyRqbu612/+CVjDg5ZVRA26MjzKxBOUSWmIG+VlOSTunN5WxSCco5Km4RzUNcDwU54RC+ ExV66yDfFB/B8IF9OwypMpnqu1ChhGh9eo2A3MKl1821YivpWjr1m4QSXfsllSk5HQOUo1DR83zK heRcASbrMNxCUKAxGj1drCwdi/0ax6K1Dee89Zo8871Xfs98/7jV3u1Lj13x4VpK0SBsO4GFkwrf YYM27A8UPyEmKrpBqFQIDCPLSqU8a2DOKFRo5WdYD/Y3HDQuWw+bq4y8qtc+07kUidUGlP04g0B9 ZBhQmwsCw67aPOFfGdI8RRqOQpwcRyeNQI0hSH8Hn4rOp2euPeb13czwvKbvzYPDdxSG9NnE3jMV /mjhV23ciSokKrJtFGDTOl+7kajasTQGh2GBLYq2oo90ZdC6RjVakFEE0JcRaoOL12o5L4POnNOu jEA/OWyj/mSayY7cAuWsm0gxkZmNDBVicfhzNK3EP3fMrIi0/I7wX8E0BJonSBQdIJiYHekDakdv 2ERrZ6nNyIqqT1M8zHrYKFljN98fKeic6x5KUBpSvA6plURsZZUVR6+67d2u7K2peNtNr3vu9lz5 37GU44Yn2SzMgWzVmQrUb79dUNKX6hC+wuEc4K0Ce899VqGOW8HbtXD8ClCkOMDF/Iqqka6QAqRa UIDSm+WuyJM5pUBee9Mm3BqS/pKVY4cqiFguZOQYWQfliKgtmqUhCoiCKzTegYOvo5sQ3WsNUVkB JbP3DQlFsnRQVIVGOtn+5SzuZxafIecwZN65cZZi8sw79+TIitPIHqYi8m2UWxR9fM9FeIMmP5R1 cq9gwBVC3MbNYhBlHB9p1APLR6fUWPWh4KcBdw2iRMw9lMlHe0bc0a8/AsAbDS2ET1V0tnJBM+rp XxBY41bb+WR5LEhWrtDOuOQ1W/kGc8sd2XLomvIKbzYnNmEuae7diePKEfvHKx2WnXvYeJnlNBKt HUs+/On8Bwvlf5iDd/vnf8iD+/ns8videGaoJyirt3OIDarB0PU+pMEgL3moxnfi2TSYUIXt/7j8 11ykesiRFIKFFkT63XkabDMt7Zlq4vYfVYibhOeEjILPz8UAVe7fWW/8w3DA8fvu6bvf8dGlgPtg nbAUoTLM+rzzzHnWT3o+68BDymCPRss1oeTOH5REL08v3x0LFy1KY58pWeRA2QldmAiuEAhkN/1B Afyu++GHj90fqmDsB5ihJ5rDvnM/KBv5AWXLKXn/xYvKqz0YW+MYXpTy0ud4gAcnkN0dF+UUMlOW d6gv64LbvMVpls1dKVHQL3kcrbd7b3t9CksaLal3fqNt2xoy0HgFS0s/voXoLqvYyHHV8YBUnE7I wSLnyjgVHLsIYwDRKjlAk+RVOOBOCuWA6f6QwQL+CjslDg01F7ru7jv3CYdo0LqLVYBiecwGua5q 3+BVe6d78lrj9Z4BJgdwFuHUxjwqzsdWHQ9qoREtKYV5bnoBCv+BPiVwh3YUSH7dMLxhQtvYYpX3 K85PeuJgd78F7w+BAq4HpjgfYSENYSxSY4HsmsL+HjEkBff+Ho581ekw3gpBMx724+DsbsRuQqzz +ZE3iEDBZSK97egXDqWO4AEkU+4Doy4RRNBV4xJiNYwPCtoAHWiTUg75Jp+xguBfCPy3DisrC1KX 0UWaY/aPRostjb6Vcvdncygfj14EEiR3IqkxTpP5NcZBoZUPPKEnqtrv93ozdprZjBKaeSraWUXc +UJVxxxPb6I0mVKLcUnHrDyYBXDvHruvMb+TE3Ks+Qw7wN79F7cDXtVEMrtQfyiEmCWYEoUWy5Ca JSnlBJTACIiG9M85GiyXnVKfwhminzRnKg2vMQgnXbwQJzQABsVImHqbskDDaCL8Eb4uhlDdIDCH 9VJu8sZr8Cf0b2KF8DOGBtC43eXrtvl1PGBHPMMKPHkLfMpePH7y26//eza/iqMBZlixhJ/x38Q0 RP9m+uk7dumDGI07oC1edoRCNjVsV0ZRod/H4HRKk1+FCD1iMwjhRtkY/ar1iMW8sLevvOMfNgux fnlxInWiU9wHtjfFJKFAB7WJGgBGhKKZfy34OJaYYddVKEQ5mcJdYwWnqVx/hsGFg09o80P/v/tr U2l1D3d7JwdbvGAHdXHLMcurflW/b1lX9y68DmD2dd+dkq6hCV1UeketwlK94G8k7+LwhpoReV4b nnHfLDenBhvocg2IRfwwAtAXxbw2MOE1mPKaqJyO7i5kHlwRpVzbJmIHSUYItwJJ4mSeErdOEjAs iYGfwVfiBwjrGcsGmlaLc0lcqnIT7B/dxpAapFnVOWj+HNrlcJ7pLLmltjG0cv/3PJoxyIYRRjjl gzHqGeT4W7keFia+BLdnkCyALQAScNvZUM4rceQSkuWciaEfoQhmm+Z3A+08lQpYgnC7Illj7xii ZwSZRkNkeabXELOLyVTIbMh55XptObtCyxrluiYMGdSpR/hFNInQsK+puYpklTlNdUiMaxSoLFsr yUKkYOoSwZRkLVBPVQyyR58QpSgDneVU46Jp6fcB/BXCDNZQkH3CiSFMacglGAUBalZiYwCVKLsI WlMZAOYtnIeYBw4uwHCyotBa+guA2iQYhqBxLHuFpZBFk8CUTfvEAiD8qySXWhCWOke+gQUghvgL 8+vhkbBbi8WG8IuxGOmHYt4Cev4HagJAYRVg7x7rqSTlNA2SW/q6e9DvtaRU9mslvJ/4GNNpIUPg VruiTso1ApAeUQQjAzYLajndR6te3KER7KU+cxmK82+K5NUIU+YwpT8CmrR8I7QBO4wuVZxlU64h cJtyYJPUePuw3d4tXG7T6LW/KTnjGiJyM+phgqjXOF7Vp6IQ74K8cq0qBdOXIASuIQCUVw6AJgJu BU0UcKcBWJEBS8fbVrtXYCvtrqFgGOL2N19cYL+uMcTRNtPgODaya8jAQPZMhu++Fd9y+89yWFz9 wFiq0mdrb8hjjKW1ouWQkgAsDUJQL6REyt5FpmtlyChiexHeD8bY0Ej7SSLv/iiEr14F1pTDXJA2 oFwq7sRdJI2KO1sYR7Bb7nuQ3K+6WRQzgA9JPhtUokTCeuYjFaV7FfKYQAN40ICCDv0Zwlt+wgJI M7h1UEM0retMeYdMHmXgA/nzWTIly7RwnmUPAgJSMXxlJqTlbGkMMGHdLz1xQf+BNYApyVkDUeF4 qhIwttAz5Yf9zdrFoRM74mjEnGdinePqmoW2Qhx+sVRFe2ev9XpfuYOwUN1niTqqdFQpaafpiznG XBhTqUoKi1furEyNmJurIHgyeLi0P0kjDB4PclgkMJUCMZ7DsoYXQ5136k4Qad+RuxgUZf9kwcD+ g0QiR1X2iHExmafa2AubzndEuLLuWMZK8VJJkTr0o8JDtgnURBF/DXKkfZDea7KfzTUMLE4IJMDV MGpfTN5igf1Xu+3Xe5IF/FR2jrlHsKX9+L+QgVLy7kBLSFD8NKI8Soi5z6E4/gwHnfxm+tqkExW1 MYI27JTrK6880ZSfx5gIRrIvBbnR/wWqwKjOFO5JMYcNlYIUT4QvhKAAQoGnZ9tQB2SMQ6zaFI5A Jq/F3uUyRlHEJjBxPkxpKH6IsALcHBXcVJI6TuA58RyoWIZ8lH7OZAhiGQkNbgJ4zlQuSM4xdD8Z tFqZLz0unluHt4B3P02T22kDZtndb+8de6OM9jcsptVHJHSUmVdTlreSL+wXnNfxqf34utWGn8Yd DpqGtyp8BaodoBGfA97UyizLm1kJQ9zOQYnsHy/bcJYEJ3NFJ9HnkG6zIN54T2YdTxWTvPIhgYdO gep/QN+7/KXViQSvgUFriK/05RUliWvaquJ/LpplwrI8Z+Ujoxs4xjUvU+rXjguK5CF7fyZ6564S DsXoI2Mp1hS0gKZg0CuONS2O8Zz+OlInfq4kAhuzfGriAQ5uMJfiMjBWXg2I/aC3c9zmvl6jSsA2 VU1DxX6cKU59ZHDAWi1ZzV9so1Y42hj7wBd+iR5c7sx/dxp+qumEzA5lodEpvb57lS1DgTkayiD+ hEGaf6YiSJQ5k8yUYzrlvDxvXfFdXnNk07hX5/bbrYM2j4Zys2L2N4xU9ZGB1BqxVtQOw2OqueSm VV0eQ++TQyzAQTaIGhjdNnEq6flAWv7mtN/HaferAmOgrjta+/aIJkBeJucYwBJylSSYj1xvjro1 6KuD6916za43fkiVKBgdiBV3cTfF/u7uTpsCQPolaulW3aBB3bO3XJvZX4sFqT42aUiFDJVQlZXO cZlxk09Ey9CpQyn7JgE+kNnfYnSIX2tI1Czhx0iieKFGEcN2OSaiVTd6sAKwDN01D4XwU25JvLqT BDePFtCaTvaEQrYyY2QAjfINy5FY8qI7+ZxrKT0VjBjKevMwYQ7oXvovCiM0pluhSpt+6puiY2KV dbC2yFoTPtlorLCxrcfCcWIOtjm5iJifKksuCuaJ4Hwatvk3JrEvi3vwtXBk8xVErzhE/d2UYQYf gWl+wt1Tsgh4gBHUGI37DS2PjxY/lw8T5GTJgyV28XALiTSOuBQdnVybMgipSbdt61KYEMuJxXWD a027wZgvtblayi1+72ZZgiAaxTzowkjE2qiMA7E2i3jhvm28fVFBGZZlAbFJ5Y06ysMVJ4VQpVII z7euEiyHbwx6qZt+a9KLdA6YVDaXXtiAr6AFhL+041I31rXi3F7HRX3Yl/lII5iz1ijOMtt4SuDA 2f2pR4MYmg6nc7y5TSCGTlSB8yIEtXFWrZ//jSmV1oksKd90VNIGIsp/ah27lt6VdfClKDfYt+ms IAcAT5F9/QALrqjzYCVjw/5LRscpMYCcLsyt29X9s5sUhoGvYBHBXRvRN+gsfvypqMJzNgKpflIm 2OQNRVSsV9baFEOiRoVSgK91h+KahhE+boiQsanW3eOHrBCeFK/pGqkvEvgjYBJILAQug39AH0f/ npqmaloFJKt/mhf+fMtBbMxF7k6jDd1AtAyIIrlkZP6K9LNU4YNgFsgyQUeOo56lyP99C72Ft5L3 71rRqfL6VF5FGQhv6Hlp2MvLxVekgPR9UDCX2hX3QdkZTpUZNHKcVdlbF/1aLVBGuG7NNftPGG8N D1u2IlBTvZDNDKOFTvpMwmBKf1bYeL0Nr1HEicxI4wcoKVC3SnJhAQoSpH6fydZp516EpaG7uZqg A7PEarLgQBZFdlWWJKUWGhSecI2fi/tvrP9my7wt7z554Q7XTWLmHN9WiqigLGlEDVygqy2pUkuV jtFgZSAH9DaP0SnrTnf6JoyzR8AIHC1qUUctK5AhpwVSnapD/YY4vkNyt91aFsNvAvt0vreOtZRZ S+dcVsis0DZGbM08ntYMVqBGfbixsTWuD6uMrW2uIK/wSkWfEhMkMmzTAk0h3KAHKfPNqkPVsC01 QKSPksHjHM8VhhZQLWJhR+DPaHiUF9mp8RPZ98gPKSHvtf2+CfbHEOysanEzPSXdgIWAsi3bt+je wPQbmmxbWN4loVi+BmqVrasln1HEbz++zoJCvTkplk2Ln8YIyxLfkey5F+MwnlEnJDKbqp3XNIJR yU6F9hTdokpzkjDy2gdQciJ/yxCHeSw7iZYsYFbicOkuiahwOf9E2jvKBi3sbH5ThBk66ovCKUUH Esrx88Hdq3sNFNlxClnIu3/4dq/N/QqqlF25MFcw9aAr+W/4d3Vbh71oXd3w8nUmw5svuz1a1RLb l3Vsp9ykjREGKWpGLxczrhsvfWeXjxqVKeTKHbb3e4dv+eT38QSN2uD7/Nx8e+dHasO4JY9kRHfk EKWc9lExn2aYEEMeHT6RZQ8UFseINATSSeCqA19QkwaVfxuky5NljPUIRs5afYQObXJyINTgiCTT EQdeznkCtyxnSahR05jMwaOmact66tDyqcHClkXOJkxAVZkAroFXlmU7+3vtneMtLRkMnlDrq2+Y J9TDbLwaFqxNpIi/NiY7WqSKSOwqAOfwJgY6P7sJBuagqnWtEQXLCjQ0FPS0ag5iaqRAZz91rMHf p2E/f/9pRm6a/Er29AC/kzkadCwoOxs1QJYlo/zHxQwUqyRIAce8A+pQNT5wPKSELDEt+YL6oYav zJvci+mQgFQOzocGXdjfuHRRLysNAFmvqiaoCuqWAHp5oUZoFczulplcFHVtRJgu5Kpf2+RGSBsY poy3v6kAU00bgVYvABlzCrq/Q8g26g1iYoRcG8RzJFxV5CDWI7JYoFAC5HYcDcaYz2EOnSvm/bGT y0IV5O1CTWYldUkO8QOE1Irn3qlYGT1pl9RmCDSdOdPsedwHj7zhKVs8kcVWSnR2OvRMiyZSTTZQ vxS4G7xaObG2affY+7lLF8kuBZ+xcTWzHhQjS8cNX76uPsiMHLc5VOGxdLj6BCihboR2XeVNeUXm No1Ryf72fDobsPS49sh/DH5BBBZ3f6LXGC1xLIuFLiHD3yh0e0Lxyt44CkccstE/JcCAg/BPfML/ riWt+r3pU9xVNNbwvIHC2tahBkivqwMqo6gO6XUFK+UVPUjv9fZaJ2+12VGN9P6PFy+Pz7riePsM I3bYtgMdvA9WXbrVgH3Pfy/orSueKSOjDr11BQjlFR+A3g8nwO22+KDZmfn3LIXLCU8dLG2wt+Je X+HbHwnhdRUcZfTUIHy3ru+rvOJDEK4x3UW2M6C5d2SqyDma4iIYhbhK+IfTC/HsQ3f77OIHHib/ TYrv1mUZyjiqw3pdcXl5RQ/Wm6rujx7mLbkBTVXChej/dCnOohkmLiAmQFEAqASMpUzmmYBmCFPM Zcg0MXWHdO0RMjlMeCv3UamFKvyPlYspDdP0UM/Ofnx/0f1OT7xj8xjTTjDhhFxOORPP8747WDT2 6Z6E8bL76Bbr7qNYrE2RytpMu6cUVBLvEwizh+Fxg5wM0ruqQVXTk2VXkcTIOxeTABcbvJ1HMc9X fvbh9OKywSUhG+PqPTbADahJAHXB7bhImELpiJ1TjHM5dkt5x9KNz8JwQo8gWESNMuSQX3JrMwZf I4+BS1tpiIwKi2KMF43NRbQrQW4DFS+08Ar/nVYk310mvTFw5Cm544+No7s4YXu2522g12YKJTUk zj+cdXskB4r5cTrEs0LXFM/SK2iZrxga+RIAUdaDBMi/HfcvLIA0OaSUNrak2Dg959CHJzKz++hO +u6jOOlNzbvT4+Nj0dpvteHKfbwg64z1HJv2MLxGMgMz4JK7x4nL2Ch/fO5XwTMzsaH5ugldPnJI SL96tYywRktxkSLnljgWK/VH0ak6og6FKTSJEfTV8VvSKsbHpBaQBOFVoHcsFjVMeKMElPnZL8aW o9Gg69ylVvyOJqiVmyiKipxmLz/BwTCsELclyfyKTqUUNnfpzlY8YXfdrLq9xMym+09PCvgOh2aY O897d4T2A1JBq6lDZ45SPWEOyNQ3K2B6NRxx51V3hC4djonEXWYFWqVREqVU06iu5zBJjy1m5Ex5 Ol5KWQRCYTET3DaU3Ndq3evSRmdpRLFhRI3Hyjhy8km0JU4e07Hc5flUm5MgWoNQuotFwPOGsMci OWHOkWrt7e0oE8rvTXxdw0naFK3uTktORHLHg9mq5355PRMSdePBHga7h9tYj6zL1nT0O5soq43t k97+Qcs7Pc5DHsbFmZzG9RgX5Ag44se2hh1Va7BExWpaeBmqnOVpkQx3JZopMO0AhwplGXemVbzT 9hirt1xVmWGrIK9Ms4tSHtvwcw2tzs+roKSIYIWCsy8dCzEOuaZaxKzpgaZCqhMh8oftgaIF7NN/ ggJFlR/usAkDeQEgmQA2zB2cWdthK2GcxMMwtRHtRZTtO5iIslFYIUBNBXGInicZzvbrh81pEF5d n1eUbaD3ris+np9S7alsH6LyUyfci9KNhJ2lQhIpA08x39oa7qqHiUvVuTnoqJIzmbwzFuVUhY2n Am9DKqJcxW87Owe9w+MttrY3cjYfVzfrsTHS7dMTZ6L8RSW3PxHUdemmPoyOxZxrYI88AMSNgMai wouyiRhMHqLsCc84mCx5T0B/HD+RKQoU6EUOa+DKBP+hlj6h1utPBMOqvhu66hLYhZDkAeqli5j8 p34aqIQCpTt4SbW7V+n5j/UEkNl5Lt5/vLgUiyiM0WcrQwFLthxy/Ta3ChDTKlPXYU+kxkCsVFi2 W1fWYrSd7RpddV5aVx+quLBh0qxZkeK4VMzijxVpCU4gUg9y3ZpRxWZOEdqtq9qpANgm6LFOpafz RESWqj+2qBloQ5Mog9dLlBsB+ML6cU1PaqaQpcSQw/2IrquDLyKZGrXE1kk3xCr1s5FrARRBzSdC WvDQtPWGLqswQC23PaoDdyi8CF/UR66/WTqg0xPEkjHP9gh3rkTlts9x90s1g1bQpsRsRibshVKY aJbbRjMd99YNC74jduSKIA6wD8NZKK+qRoEkOyzIjTgsaajSuoJBUzN45oVYjLLhqrTzHn0Ot3Tl Mdw5dEWgTQIMxMIMOR8GHvkHzEYKcCv0qzesYYf3zLCGHfDgsIYRfFWRi9rabzPu4UQ9/LahYfKW HqhKV0mcGruriOfd9LrnfYeySi9hyVJYqKWvaQ/Ft474rd1BBeMQEi/0rYbpv2SCIpvOPldFWu3w lVJgFYaYzVl3pAmbWh6dJry76b496CNCoa0OI3zvoVC1QbJGmlLoModTl7nYV1E79QvarQqZ0Pus 24UoFIPJeVNM6KEapXM5eYauM4IBgsS27tlD3nrZsVd00gcxrs4a8fi9RDXpudSgwWE0EfEmKihM 3gSeIj6K/w9wGTCNQYcRxCEHFiQgdL7FmOIQNPw5wMXo3GvL01qsflPcfYRIX5ChkpNuVddZV9w7 PsAYQFykx80Mbpivgh5Lor7gqYZHO5bxE3kHtgsmiRgEJbdnQeQ6p3d902yMHns3XMF8WXG25wI3 A8pb/aJfUCEgF5AVbbMwHQez8o3gd0NslkzuERWSUMnvG4FZRWguAqqOg2RAitBkBTidLk9INHOd /eP97t5rjllWAN65FMwrV2xZZmo++5uKgH6N5tPCwfvqapH2GK++S0ayRqT5pQkFsvpG0+YqnKuj Soqj2oeULm6D1UphkwSGn5pRlqkGmUMKj1GLZ5aj+rP2EkYHktIQMJTAmkMipBO4TT7HpI7l1BQl Yqch6D8L0ghClMDhjpSgIRQQp5C2aIvlYjM5EAA/T3UrdwhhjYYAlNRzYQneAt8XORhXTHntGMPW shhs46H6ojHJQfk6z3ohUbboSPuYxOtnBUfQaNNL3mo9SOaIHV5x0jRH5Q00AJxeBBGj4momTqDq vKhtxt1Rctg4k6aZtJyI95ShYlrjKguJLUsjZjkDDOUrELcrhmRxL027fdk6OFLRSlmutRZ/VEta Q0lYPh4df91iwE88hgxFBvXUGMnId5kSsZBY0KHTwkKDQJDeHkwvmrTNDxXug46gfMAtac+p/Iyk wXMusCdZe4bmhYX4wHfAIsaNi1q55p5NE/UxV9xzYSFWlqWSlGqXVYbF7evywmTkr6h/eZbi2lq6 RgeyCf+jHdWx3ROK4NzDbyzk6ROhRV1EusSm7rsQvWQyI2oggiLk8uQichEIy/yhKkCVpbUq00XW pSQquEt037AiiwlRXOlL9MHTaj4NiPUcUloGg/bq+gjNYNDBclqhtiYt5KgP+/KqDEP2r1l64Ljc JHwJACnlbjiNSzeOzAWCsr7SnLidrlpmZakXIVAaORevktl7fYD/kA4wLo11PjTccPsb1jzqI0Pz 1JjLD7BZ1yzdDfUjjVyrbL1IjPIYsQbGSEkqykXvI4HkL6kFik0QLndiC+T+2/h89wCa9I87tI18 nCbz6zFU1nMB91ecn/TEwe5+y2LvzaHItbK9Jis/OPo7x2+91Zr7+weHOxwhJ9Z99AAdeM2WCup9 RGoKXFdGozYFxc7S6CYYLGDewO8L8mTVRW7ub22DGK9gkvYbU46WuCPc9iyIPjrcHr4btUECQLPA piYgDbXOcZDCz0R8LkMLNmdf2FqDwOGuAG4nR1gPqdFUNm4GFLksoY8YGa5MTJeAQNRNcT3IfIoK EPjrPL4OCmg0n8ppF/gzGa/S7+Ef0WAn1vRnZ6dsYJx1T+VCaUjNNCENNccwc20LY7glBwLwRU5i DPpPbo6sBUzOSZPhXL4LGRJ5ozQZzVGpuYLuIptE12PEW4OFTVcPR44R92+GHEqm0/26cTjK4Wia 1aDe3aiIl817Ns2aASz7G6mRJYE3p5+CodeTZTTI13tqQ+Lc8X6CCvFhKSEcvu6t6wELJKp//6dT 8O41c7a0CGXwKOPkK0xxBIbAIe4hDShu2Hmy+QxR+6w6Pi5Nd0MsrlVdk6YbhCl1dpFpQ6mRGNLW vJShkGnJVN43Ow3z2yT9RPG9s4vuWSE2gziCh05Jc4RkqI0MrW5Sh47i4BqJm2WHl1wfT4/DADKY 08R4FiNG6Y5b443kF8xwWwT102dQwvRvCiNEGczChRSpkL8z7JlvriRHLBazJI6guvFgHNzaMTev mLJjUOcSRbZJYoop+/Gvo3Srd2N/83V28/pwp31yUnhahlOlvjHktce+MoSkwcm2FXVFkoxKBt5s zYLrUKka6QKWm+5tIJjIah/uv97hqrxHtSwLNWPuusm5VrQm+CVkj5IPEQbqkl88CSkmUS1dKPqr YFEJ2QpJrIIhK0StedRKgf7h+EPXldel0HXJW9Raq9H+OwgO/vbr33h+i5Gt9b/FHyG/J4y4wEH8 /EMDQ8ymu3VTpFfsOVuUYs/50GBt+5tHFzQl20W9j+hY5qOW01hghUbI+s9pvpQKL9M9ITMElWHN v4TgT9FAEuIGQGquJ5sb4d9JhKu15HhK9iBGYTi8CgafGiCzVt4p+mWglEVgTRBJiw0vkr7Oq+Gd uT32JR6ViDgv9eX4f7nkO/6dX7aJbo6Ukp3zexJQeB+ki9jedxUImwGiH9xE9npPAg7nycIt+HoI OTjKx7+Umf2VNHmcjcD29m3FNehYK3RVbBFE9EmcxLgzAekq6+ibsLsehOxC/DUNkDfZuM39FUEh 8Q7ts+F04/Z2nlzDpQFyszGcqY3bXi9dIDQVi/eD/hwTgTYRt/l4ge29D1C3tmng8+ux3hh55Bxz VO9u+UoJ9j6C8xwGc+u4T0GEoeQJrZuhOAuRTUf4wDrAJoix0zQQZ4vYKdjbhJ29xXzUqTjHvMHN gxrGt8JqvhUXiKrbCn4TIPev4WgkLhME/J+gyfRjMC1X4/otnWamo8VyVTLjIv9/AQAAAP//lFLL bsIwEPwV5B9oGp5BBAkJqCq1UgQ99WbsTWLVxNbaFNGv79puKFUv7cXyzu6sZybh6NndcnGeYzj8 8sWJ1tTQqWZxF+pwxpZFY+oN4oDQi4WSOQtabzoZ6DRkA99SF52Su5JlWTHN8u2W9VCFAVwV+Taf XME11Pyk/e/x6gaKm6ukYu8vGmjlO9cle1LOVxx5g9y2vY40+GVnzTsFevDKBbz9MNQrdiB8FUz9 R/aeSEHfZjwsVhMW9LXAJeAOakDoRFCYUpLJIBvgXMmS4aOcpbxrY/zfCEUi2Gb/QWvPJbvP81EW ImzpPp7RPX5B2zzz4MQbS/gojaBqWtLalwfjvTl+1xrqm24yUbJpHtcnideyOXlSTL7Tc8JoR685 S9mmmahCGvGASlJHqw4q5QWpHE4iiUJPecc/5mDkJV6IcjpC55efAAAA//8DAFBLAwQUAAYACAAA ACEA7dB9LogCAAAtCAAAEAAAAHdvcmQvZm9vdGVyMS54bWzMVd9P2zAQfp+0/8Hy0yYNkoYVQUSD Kkp5WleNoj27idN6OLZ3dhr63++cX2sRMEalaS91fL777rvvzu7F5UMhyYaDFVqN6OA4pISrVGdC rUb0bjE9OqPEOqYyJrXiI7rlll4m799dVHHugGC0svEGD9bOmTgIbLrmBbPH2nCFh7mGgjncwioo GNyX5ijVhWFOLIUUbhtEYXhKWxg9oiWouIU4KkQK2urc+ZBY57lIebt0EfCavE3kRKdlwZWrMwbA JXLQyq6FsR1a8VY0LHHdgWxeKmJTyM6vMq/JlgGrsBWFbGhXGjIDOuXWonXSHPaIg/Cl3K2AHqKP eA2F/Zwdk4IJ1cP4wXjU/755x9i8oMkdeKjfhaAWCY6RIVWM45d9G9EwPIvC8fScdqYJz1kp3c5J HTGHerl1W8nRdcPkiE61dhxokFwEiNl41G4umV3PxmScZcJ3nEkyYY6R7xruyQ3o0vgAV4ehvw9+ G6s22ZQvoWSwJVH0iUThINqDx1I9umPLhmi9e8JkM2RUxbg0lYisqzMahifnw5Nw6Eut4kyncwbu 6/LHzu6GScmRQivNnK04mZXFEq85+bDQhuiceOPHPYw7JX6WvOG1C4uS9Dzw40orh/fIp3uC+L8z oYr+3YitYSnOnwFuOWw4TepyH6veTZQfpehscBVNqa8gl9nVmgGetl+LrUGwJV/heD9ukVDWwYI/ PJOXzMc318Qn7h27qUKp/o6A5YYBc3yPwy7EIDqdDD/XNUAzIkrPQeu8Jd3YXDI4TAiusj0KXrPn ysehOizZ21Sf3X3xwt+S/03608PU2JO+uYP91Wu2h7xW7Qtp/vCGYiJ8DvEX/+yTXwAAAP//AwBQ SwMEFAAGAAgAAAAhAIc4Lv3qAQAAcQQAABAAAAB3b3JkL2hlYWRlcjEueG1snFTbbtswDH0fsH8Q 9O7YKbZiMOIUw9JgeSuy7ANUi66F6gZKsZe/H+VLlqxYEexJMCmec0geefXwy2jWAQblbMWXi4Iz sLWTyr5U/Odhm33hLERhpdDOQsVPEPjD+uOHVV+2EhlV21B2lGhj9GWeh7oFI8LCebCUbBwaEekT X3Ij8PXos9oZL6J6VlrFU35XFPd8gnEVP6ItJ4jMqBpdcE1MJaVrGlXDdMwVeAvvWLlx9dGAjQNj jqBJg7OhVT7MaOZ/0ajFdgbp3muiM3q+1/tb2CSKnlZh9Ci7dyg9uhpCoOhmTJ4Rl8V73NMAE8S5 4hYJ15yzEiOUPcMkY/y1//PyFrS8fOTOE9SfRmgWa7KRZ31J9pP7ihfF8u5+8/kTn0MbaMRRx7eZ p4vQAPKE6cDxeM7Xq3z6otNPyX/c6MuYDFgGL2pqxCMEwA74erP/uj2wPVAH5Bw5GoZFx3aPh23+ +G2/OzBnWaKKI2FiaE8eUCv7yrBUsuK4k8vUUKtCdHiiRza0fakXf8STBrrTCV3x7zMAv2gjUUwj js7psFAQm+FZtZF2Qj6hd5JiGdSoYiakVMngQmckXFxpJL1nkYNuP4xwHvrFaOfQ2z0MFeNc/bV6 EBJwkj5MPm1goKEfxvo3AAAA//8DAFBLAwQUAAYACAAAACEARK+EJeIAAABmAQAAGwAAAHdvcmQv X3JlbHMvaGVhZGVyMS54bWwucmVsc4TQzUoDMRAA4LvgO4S5Z7P1ICK720sVevAi9QGGZLIJzR/J KO3bmwqKBcHjzDDf/EzbUwzig2rzOc2wGUYQlHQ2Pq0zvB2e5QOIxpgMhpxohjM12C63N9MrBeTe 1JwvTXQltRkcc3lUqmlHEduQC6VesblG5B7WVRXUR1xJ3Y3jvaq/DViuTLE3M9S92YA4nEuf/L+d rfWadlm/R0r8xwjlulSDT8eOYl2Jf1jOObTBE9uvNR3HoExFy/KSk6SrZ4nG+MvNGKRBxm/kJZu+ 39OJqfYSqGVSV99ZPgEAAP//AwBQSwMEFAAGAAgAAAAhAFXTEuGfAQAAawQAABIAAAB3b3JkL2Zv b3Rub3Rlcy54bWzEU8luwjAQvVfqP0S+gwNCVYkIVSXUc0XbD3Adh1i1PZbtkPL3ncQ43RBCvfRC 5FneMjOs7t61yvbCeQmmJLNpTjJhOFTS7Ery8vwwuSWZD8xUTIERJTkIT+7W11errqgBgoEgfIYY xhd7TDch2IJSzxuhmZ+CFQaTNTjNAj7djmrm3lo74aAtC/JVKhkOdJ7nN+QIAyVpnSmOEBMtuQMP dehbCqhrycXxkzrcJbyxcwO81cKEgZE6oVADGN9I6xOa/isaWmwSyP6cib1Wqa6zl7BVjnW4EK2i 7A5cZR1w4T1GNzE5Is7yc9zHAfYQY8clEr5zJiWaSTPC9OfxY//j8qa4PBq5aQ/1aQRnsf5yTFlX hINFJC8scyyAIxiSVUkms6HQ4hOvtdqWJM9vF7PFctlXDKGNqFmrwu/M4xCa5/cPywjy6HpSbxnH CWI7q4PAM8Lr7woleyfzxfjYtgoDrA1A6HpFu8LG9oiRdMYUxvqC4Tf9QU7642CCNO1wf08JI3nN o8rk67eh7X9YPSn5nG2cRJqBX38AAAD//wMAUEsDBBQABgAIAAAAIQBSdB/ZoAEAAGUEAAARAAAA d29yZC9lbmRub3Rlcy54bWzEVMtqwzAQvBf6D0b3RE4IJTFxSiH0HNL2A1RZTkQlrZDkuPn7ri3L pQ9C6KUXm33N7Oyuvb5/1yo7CeclmJLMpjnJhOFQSXMoycvz42RJMh+YqZgCI0pyFp7cb25v1m0h TGUgCJ8hhPHFCaPHEGxBqedHoZmfghUGgzU4zQKa7kA1c2+NnXDQlgX5KpUMZzrP8zsywEBJGmeK AWKiJXfgoQ5dSQF1LbkYXqnCXcMbK7fAGy1M6BmpEwp7AOOP0vqEpv+KhhKPCeR0ScRJq5TX2mvY Ksda3IdWse0WXGUdcOE9ercxOCLO8kvcwwA7iLHimha+cqZONJNmhOmu49v+x+VNcXk0ctMO6lMI zmLzeUtZW4SzRSAvLHMsgCPoklVJJrM+z6KJt1rtS5Lny8VssVp1Gb1rK2rWqPAzsutd8/zhcRVB dq7j9JZxHCCWszoIvCK8/bZQshMyX4zGvlHoYE0AQjdr2hY2lkeM1GcMoa9L6J/D5/GbOg4mSNP0 x/eUEJLSPPaYVP2Us/8Pob+2fEE0jiH9HzYfAAAA//8DAFBLAwQUAAYACAAAACEAlrWt4pYGAABQ GwAAFQAAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ru hx5piZbYUKJA0kl9G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7 /x4fqavX7scMHRIhKU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJg fSLXcduLlErXl5akD8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0 NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uY WrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2 cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0r rdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlK xtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3r54/RccPnh0/+On44cPjBz9a Qs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXw TYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHl owp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH 8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyz ewd1OKvSeoscukjICswqhB8S5pjxOp4oHFeRHOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaW AH1LTt/BULEq3b7LprGLFIoeVNG8gTkvI7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANO Frr7DiWOu0+vBrdp6Ig0CxA9MxHal1CqnQoc0+TvyjGjUI9tDFxcOYYC+OLrxxWR9bYW4k3Yk6oy YftE+V2EO1l0u1wE9O2vuVt4kuwRCPP5jeddyX1Xcr3/fMldlM9nLbSz2gplV/cNtik2LXK8sEMe U8YGasrIDWmaZAn7RNCHQb3OnA5JcWJKI3jM6rqDCwU2a5Dg6iOqokGEU2iw654mEsqMdChRyiUc 7MxwJW2NhyZd2WNhUx8YbD2QWO3ywA6v6OH8XFCQMbtNaA6fOaMVTeCszFauZERB7ddhVtdCnZlb 3YhmSp3DrVAZfDivGgwW1oQGBEHbAlZehfO5Zg0HE8xIoO1u997cLcYLF+kiGeGAZD7Ses/7qG6c lMeKuQmA2KnwkT7knWK1EreWJvsG3M7ipDK7xgJ2uffexEt5BM+8pPP2RDqypJycLEFHba/VXG56 yMdp2xvDmRYe4xS8LnXPh1kIF0O+EjbsT01mk+Uzb7ZyxdwkqMM1hbX7nMJOHUiFVFtYRjY0zFQW AizRnKz8y00w60UpYCP9NaRYWYNg+NekADu6riXjMfFV2dmlEW07+5qVUj5RRAyi4AiN2ETsY3C/ DlXQJ6ASriZMRdAvcI+mrW2m3OKcJV359srg7DhmaYSzcqtTNM9kCzd5XMhg3krigW6Vshvlzq+K SfkLUqUcxv8zVfR+AjcFK4H2gA/XuAIjna9tjwsVcahCaUT9voDGwdQOiBa4i4VpCCq4TDb/BTnU /23OWRomreHAp/ZpiASF/UhFgpA9KEsm+k4hVs/2LkuSZYRMRJXElakVe0QOCRvqGriq93YPRRDq pppkZcDgTsaf+55l0CjUTU4535waUuy9Ngf+6c7HJjMo5dZh09Dk9i9ErNhV7XqzPN97y4roiVmb 1cizApiVtoJWlvavKcI5t1pbseY0Xm7mwoEX5zWGwaIhSuG+B+k/sP9R4TP7ZUJvqEO+D7UVwYcG TQzCBqL6km08kC6QdnAEjZMdtMGkSVnTZq2Ttlq+WV9wp1vwPWFsLdlZ/H1OYxfNmcvOycWLNHZm YcfWdmyhqcGzJ1MUhsb5QcY4xnzSKn914qN74OgtuN+fMCVNMME3JYGh9RyYPIDktxzN0o2/AAAA //8DAFBLAwQUAAYACAAAACEA3whQSL8EAAAqDgAAEQAAAHdvcmQvc2V0dGluZ3MueG1snFfbjts2 EH0v0H8w9FyvRYrUDfEGulhtiqQt6s0H0BJtCyuJAkWvs/36DnWJ43QSBN2XFefMGc6Foo7fvP3U NqsXqYdadVuHPLjOSnalqurutHU+PhXr0FkNRnSVaFQnt86rHJy3jz//9OYaD9IYcBtWEKIbYrV1 LrqLh/IsWzGs27rUalBHsy5VG6vjsS7l/M+ZGXrrnI3p481mJj2oXnYQ7ah0K8zwoPRpMzFzVV5a 2ZkNdV1/o2UjDCQ8nOt+WKK1/zcabHVegrx8r4iXtln8rsT9nudc7lXp6jPjR9KzhF6rUg4DdLZt pnJbUXdLmKH5kThTP9/XBy306xdBHmFs/yjVrq5xL3UJDYWZe9TZWAA2Vse9EUYCPPSyacZDUDZS wPbX+KRF2woY2mQZOZX6Q5knLcrnYpyZPRATII/i0pgncdgb1QP7RUDmAXWnvcqzAJKRet+LEjiZ 6oxWzeI3hs1U22voxMQ4KmU6ZeRf2ua6rIBQV1tnTe6dZvO42ebmPXFlV90CzYuv4txblzB3RDjV vTBjrfDyVIPNyj78DXkuZbguSVxC5potekPgHGfBbkr7K4QEHmEoQv1d7qEIZ9TFoxWMJxnGIdTP OboPYUEa4sg36yEJyfIE3SdlaZZjCHUZiTiKQHIMjUYDSr0I5QQ8ckMUCUlGCxRJqJcEKJKznTcf q/v50IIXBM3a45Tt0L55OS8ylMNcL/TR+TBCcx+thzHXT9FzwLhPMjyaD1NFK2WRD39YD1ju7tL5 drjvAStokaCVcu4HLjofHpA0QGfKQ49GeLSMMYLmxjOeFeibxXeEeuh54zueMDy3guUhOm2fssJD c/M9HnyDw4OUoX3zI5KmaNZ+5u4oekIC1ys8dHIB5VmQYpMLAhKFaAZBQGF2GCd0PbpDex1SNynQ voWeF7pod0JGWIRyIuqlCbpPFLi0QHOLEj/P0PlEGS/wjka55/MdVmnCaEbR9ycJvKxAc0si6BuO JL4boJUmqZ/jd3xKCYwbyy2lcHjQaWd+EBVoPVngpiGaQZYxUqAnJHc55Wg9OSU+RXPLEy/00Btp xz0YEVbPLuGcoL2GqwXucpSzCyKK9qCgPM/RDCxS4JwMLsVxH5AC9hqDb3UbW9Vn9cD0VID+WLWT SMlEe9C1WH2wuhA+8G180M9p3S34QYI+lV8i+8thAdfrCRha0TQFaJwFAEk4IVU99Lk8joGbD0Kf bpHHi6GNNWqt5PH3z9GsdJP6V60u/RT1qkX/rqvAvGxI4CsxYXVn3tftYh8uh/3C6kAefgFduurP F21Jm1uDrrEBRS9th96L7rQoGNmtP+6t6zUuG723ql9+EH0PYg5cDieydZr6dDbESkcDq0ro53Fx ONEZoyMGK4uNC1HaysB7frAO0yN4zQ83m7fYvJuNLTZ2s/HFxm82f7H51nZ+BT0MevcZ1PXyaO1H 1TTqKqvfFuPW+Y9pasJwFr2EuVrVCwdMxaMBhjYaVi+x/ARiW1a1gR9UfV214hNob5dO34nZvRGv 6mLunG0o693fWVeVMAL446zuyDA7UO/3yVzjSpY1nMj9a3u4qeyHKfOmHsxe9iDIjdJQ86jUfxkj 337kPf4LAAD//wMAUEsDBBQABgAIAAAAIQB9IK4MJwwAANBaAAAPAAAAd29yZC9zdHlsZXMueG1s 5Fxbc9s2Fn7fmf0PHD1vat0s2ZkqHV/iTWacNI2d6TNFQRY3FKklqTjur+/BAUiCIEEcmHS6O+1D HYIAPpzbd0CQRz//8n0fed9YmoVJvBpNfhqPPBYHySaMH1ajL/c3r85GXpb78caPkpitRk8sG/3y 5p//+PnxdZY/RSzzYII4e52uRrs8P7w+OcmCHdv72U/JgcVwb5ukez+Hy/ThJNluw4BdJ8Fxz+L8 ZDoeL05SFvk5gGe78JCN5GyPlNkek3RzSJOAZRmsdh+J+fZ+GI/ewPI2SXDNtv4xyjN+mX5K5aW8 wj83SZxn3uNrPwvC8B4WDiLuwzhJ313EWTiCO8zP8oss9Ftv7niv1jtBliuzXYabcHTCEbM/YM5v frQaTadFyxVfQa0t8uOHoo3Fr77cqStZjcqmNcy7Gvnpq7sLPtkJiln8VcQ91ISHK1zKwQ9AcYDj b3MGBgR7cJwo5IaeLhfFxedjBA3+MU8kCE4AYOq0cKlpHOwKVr4TXgJ32fY2Cb6yzV0ON1YjxILG L+8/pWGShvnTanR+zjGh8Y7tw3fhZsO4U8q2L/Eu3LDfdyz+krFN1f7bDbqYnDFIjnEOy18s0Qui bPP2e8AO3MVg6tjnFv7IB0R82kzBwQUdw2o1okFDxcb/FpATYcNWlB3zeRh5uP5OIJT62BtoyiVS BcB5ndY66z/FvP8Up/2nQOftp4tl/1UAefa1iPANxSvpRs2TQDifqofZeYfL8hENL7KOaDiNdUTD R6wjGi5hHdHwAOuIhsGtIxr2tY5omLNzROAjceleNENtkAL7Pswjxsd3EtCkJ9XJVON98lP/IfUP O48nVn3ZXWR5mWyevHv2vTFo3OGud8d1TpMPOfj5DHuXp0n8YFUjpHQe788m8rf7w87PQtgGWew1 7Wmve38dMe/fabixQp0Kj23IhLuZ1rz3KfIDtkuiDUsrizqM/5h4d2JrYl1cT7Pehg+73LvbYZ62 gi0MSjdrQsx/G2bo1Z0RuDCIYpucZMOFwS/Nk39gm/C4L1RD2MIsRBJwMLMGgUvsVtGcm6gZXVYp uAEoIogc4y4Czk9Yv8hI7vNzG1PWL/LXM+cnrF9ku2fOj/7RbV9nprn2068eKbyWzrF7lURJuj1G RQxY6WHpHMElBE0E5yAu5yeRxNI5gmv06V0EATzuUfzU2RYVjzqgOJtDoGCw0WVxNopGexMHiZwN pGFNHbD6ca0DkDPpfmbfQn5a5ZoMkKXLDao1nGcGDUAKIm28fzsmuX3jPTVwHhXlfQxnLBnzaGgz Q+RR0aQ/iXznYON+ic8BqF8GdADqlwodgAz+Yd7zlDmRDtI/OTpgOdNymcXQ7cjMvHRm5hLILQUM lDcJ+y9D9Jp9oZk3CSjOBmrmTQKKs3W0XFbmTQLWYHmTgGXIGmYbqZzqIpRz3lSByp0AQaJhyJsA NAx5E4CGIW8CUH/ytoMMR94ELGduKDlVJW8CEHZxedQvgVTyJgA5c4NgO3lmVOQ9nKX74XYA8iag OBuoSd4EFGfrmMibgIVdXDxBwyqpjoA1DHkTgIYhbwLQMORNABqGvAlAw5A3Aag/edtBhiNvApYz N5ScqpI3AciZHkoglbwJQNjFhRtayRuj/sXJm4DibKAmeRNQnK2jEWq5SSVgORtIwyrJm4CFXVyc QWKhc7sINQx5EyQahrwJQMOQNwFoGPImAPUnbzvIcORNwHLmhpJTVfImADnTQwmkkjcByJkbWskb g/HFyZuA4mygJnkTUJytoxFqyXMELGcDaVgleROw0F96kzcBCLs8F8hFomHImyDRMORNABqGvAlA /cnbDjIceROwnLmh5FSVvAlAzvRQAqnkTQBy5oZW8sYYeXHyJqA4G6hJ3gQUZ+tohFqSNwHL2UAa Vkl1BKxhyJsAhI7Zm7wJQNjlGUAYRS5mGoa8CRINQ94EoP7kbQcZjrwJWM7cUHKqSt4EIGd6KIFU 8iYAOXMD/84Wvhclf546MTgB9TuD4qsGMuDUYCQqoBTwM9uyFMqfmP3rkJ6AhYQOiAb3oIp4mSRf PdrX4DODg5ChwnUUJvgd+BN+paNUL8yWHd9z3/965b0TVTONcehS9S9voORIrTHCmiZebQTrzJ8O UOdzKD5H57NBVREvBpN1Q1i89h6qiGQtEB/Mi4OgI1ZiyWZ8bytR8d9QKLcp+ozHb09n5xcLLhGs Bae0LKKElWLOsEhJBS6qhmZCT2sfap1+5aVLjWVBndbXor2Y7mrnp2JgVfNR9JGFH2Zpxqfz6fit GN6oEVszqOQDnU5EkZi4vICasEx8qy31KkvJZC+8anaSFWZzfCfGL+oVZo+vk2POm2+/RcXisVhO lJxxFUM1H/6p1e+tRvfhHioSP7JH73Oy9/ETsaJ+r/Um1u+13gmyZjM6wFr8/yrDv0o5n3Ts7A+l nA/bYNW4XLOLBGA1P4AavA4/lSUW5QdsWGChe62hDgOX2nQIWY9RbcBFv9oHvtBkXnfOywg61oxl Bp0B5mEXo8dKl7WtsPwkDwXI15HwDvjH+5hHK5SToqsJVth89wUg3L9iUfTBR1/Kk4O5a8S2ubg7 GeNWSptqneR5sjePT7HSAFfSNgGoWF2MuORCmHUfH/drlkJ9YYf+PyZ8C9KgGCiwwHaDW0ARJt6x ad28thrvlpTHMUv3bSwKN0vVbVxBB/k1vRk+2MRBZn6bXIwnUOmEvSS/hegf3Lqr0RKqavBeALVL UIl09CNZhwKtIGxR9Wrg+VoQl0K/g0SUcqZuCFzdQVBN1tZwx45NyQuD1XOTKq2ky4B/0w5Oiqlk DP/d3AiJj0Ujr6SGkBYCW1ir3cq8kAvruHRuqiq8UAw/CiG1lZXP5V2Pp7DJv+rX2Ki1TbGx7Y6Y Qvm/NnJSjTR30vqYO4rZlDk1tGqiqo/QumZydcvBPaawSaFRrhhZM1639OJ0eTmXd4x5+wwZUKZn ccFTLFRKm9Jw4fJ/Zbb9ytJy7zM9E2pTcq4M+VrOxSCGtVu8txauwTED+r7jm0d9f6hqvxHDdS9t tao5kNtsLKYwh7jGySY/MFPzc8SeWuSWrtcd0RgGxtDQbiixbRxni7sq2lIleI3T4Y3qf8rowcxq stbfIMDKfHiTRFHyyDZV9tPzRLPHUPlRC576+R6CWC1Uy6BnkEEFk+JvfeBxzGq0bUiIUw+YYt/d f7j9lPLnMfhllZxtGuHJO3i1Hm0qNOUbfXqedxx5yaraq6v55OZSzCpTFjxM4A+1wN8i8/F9Gd/e HhJ4Gjuf4IM27JQNHSZnM8lEph7T5VzmEFOP2WIhc4qpx/wUTI7qNPU4nZ9bVrqYTywrXc6KbGdC OZvOLSsFhVlWCk/p8CsvncJMxufnlrVOJufwTNQ9yxSWa+kyW8JGpHuW+eIUlwvpDdSC3iJPH8BJ 5NamPFPos7O5So5pCOXrcJLA/Y9yhqAN4ecHahMKpuxcpKgvuXNpjWOdbRtUgSlQ2EHbn9J2Mjqq mOqZOxqVJuQzTKod+ahK/t82VZkDr5I9//2r6uxXN4ofxwn8SBL/ySKgeXkkjR5ENglZ4Vaqnl7P 387kUZG0QeXHBSerfiza7Dvw9udHqZzWR0hFL/wBvdVLTVlNmfclEpqqpcYzmOuDVqXf4khC1a9o s+uXutXXNaN7o7yPv+XRlx0UrF7EoKq74ZR9lNbulJc+7FqTuNUp5T3xUydtQWrySGXSH+6RQybL e38Hh+08TxbH6WUDnqKLKy0B9iEOqmPrCtYdW7VcX8dWsIZ2bD3j/XB9t8eEDGV4dfofFjQPmRWu zmSXtuBoEEIMxA6uhEeUjZvqkUkd/yUi6GZ6en0td7aSZNZCBnz7MzgDS1WiKLqvSmk92cfsrorO Kp2Y9dbLWX+YgmqvN3XVyJvezKwU4tZVvHqWb15bdlBCWfVDAvWlqWGL+n/6VrI97Lm24UWlboSd aG4LcVP+EzNVTtqicOKbKDhAq72WP5uOL27kWPPpAv+5GvHKFc8X5ouWB3t8b1cdQczEE/VQz58w Dz4UcGXiP4D4xIvFQH0j3HE6rehQt4i4NURMgJLQrmQDmaxhlrfd124S+A2Vpq9tRbOLr4mZKL5m fR76+ziXojTducStvs4lZrE5l92bCr/K3vwJAAD//wMAUEsDBBQABgAIAAAAIQAm3fgG4gAAAFUB AAAYACgAY3VzdG9tWG1sL2l0ZW1Qcm9wczEueG1sIKIkACigIAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAJyQwWrDMAyG74O9g9HdtZM0TVrilJUs0OvYoFfXcRJDbAfbKR1j7z6Hnbrj TuKTkL4fVce7ntBNOq+sYZBsKCBphO2UGRh8vLe4BOQDNx2frJEMjIVj/fxUdf7Q8cB9sE6eg9Qo NlSs54bBV/7aJrTdprgoSoq3pyzB+yzPcdom2a4oT03zsv8GFNUmnvEMxhDmAyFejFJzv7GzNHHY W6d5iOgGYvteCdlYsWhpAkkp3RGxRL2+6AnqNc/v9pvs/SOu0Ran/mu5quuk7OD4PH4CqSvyR7Xy wyvqHwAAAP//AwBQSwMEFAAGAAgAAAAhAIRcsOsMCwAAn7YAABIAAAB3b3JkL251bWJlcmluZy54 bWzsXdlu4zgWfR9g/iEw0A/zULH2xehUwyvQjZ7CoDuDeVZsJRZGiyErceW1f6Y/YT6rf2EuJVkl mdRCSnIxCV/KFUmkxMt7eQ/vxh9/+hr4Ny9ufPSi8G4i30qTGzfcRjsvfLqb/Pt+88ma3BwTJ9w5 fhS6d5NX9zj56fPf//bjaRY+Bw9uDA/eQB/hcfYCt/dJcphNp8ft3g2c4210cEO4+RjFgZPAn/HT NHDi/z4fPm2j4OAk3oPne8nrVJEkY5J3E91NnuNwlnfxKfC2cXSMHhPUZBY9PnpbN/85t4i7vDdr uYq2z4EbJukbp7HrwzdE4XHvHY7n3gLW3mCI+3MnL02DeAn883OnQ5e37WLnBHQO/OyzT1G8O8TR 1j0e4eoqu1n0KEtN784JiLooWnT5hOo7z18SOF5YdIPY42L+i8m7hcmbZu+eoq6+DQRo8RmYyXk4 JrGzTb48BzeVv37e3U2k9JHw6O3g3ovjwxVrPlckeTGZosbBs594v7ovrn//enDPz+xfH2Jv9090 z0f3smeT4OCfn1itNUs2JC2747+gGx78oDfCf5ODv4X/apItSZKcfgOIQpycm8tZO5CDTVBcfHj2 fTcperx3vxa3/vrjf8X1X7bnXnz3MX/88K8YjcYL0TDRZRBITUs/Ze+ET6lIqoaE+pieZvnTcdYo 3kRhcoR2znHreXeT31+DhwjY7DTbz4FwlQteCD3v3EcHSJN3lvYCncLg0SeUSSFjpFD7kyKiJYQC 85SOhpYQy+g59tz45ot7KlHj4ur2eDe5uLSno5KCUUlPr8BaA0sMWhoHYaA/qelmWWx0+w+wG9IC sC4WPFS9RkcgFSNQxlgDE4hawkCg2Ag0nIRpGGkyYg1KGmqJ01SFjTCXgpStPxdX+0tcJl/lJZoP idNBYaQyQ7tSVaUro1r1Gp3EAaLCdBi6MihbMeg03WRcyoeTOBMjDQ8SZ2iMa/WFbOUa/+Jqf4mD rcAFQ/EhcSZsH76TxAFkKiHXViCbYYAKkF0ZC3M1tzK9zgpkF7a5NOVF3ksZvaWEKQNZ2eyI3vzo 5Ma/uknixgXoKKPZH+R/FNc7olmYKLp5ogRhJKg6+IpHrUiZMfyFAI8l1txCV1bIX1Wa/RUpr9BV YcX2wylSPqErM6a/ksTxCl2ZIf/QEsctdGXF9sNJHJ/QlRnTX0nieIWuzJC/v8RRQlclhY1V6LpW 1IWu9ISuy42lzLW8l7cKXTuaTmU73ULR78BbwbhySwvG22ApeUgYWAQbPBvETof0WxQ4YfHlle2F ShpR7D3t663lmJFYhg11yVpOHhIO7zaMQ9q5Wy9wckcDsHJlPBppPI3G/zZ8Rx4OBsnGYzqdekht yIw8JAwvjcZ0BmlEzUyHgaZOTIcjnFGYziSNp5Hp2syX5BnCUMl4TGfRD6nF4EgeEgYZRmM6mzSi ZqbDcEMN08HQaOxTmWevrORhD75W18t5PyVvLLW1tjbXxUoPKoMvRyu1aeoqflY2zdrgghbGKxQ9 QO+4p/e7CuPVpFHPtIGb02z0yAYMKUk8eIHaIFItYa60lcbAmMSHFwjDYUDIMvivpVv/rXQ1YAaH dnxEOrQhu1oCCeNVzVJ0JYnDkCgnEoeB0OtJHCWu1TDjlWzpc3Oxtvvh2pWta4qp5ui40XglAgi/ xVLyoGYxW1FX5r2S0GOGNk6Enhm3Da1mcbMdH2qWGb8Np2b5BLbMAO1KEscrsGXGbUNLHLfAtsW+ 92GBLTNAu5LE8Qps305AoY4BW0XeaJqqp1tf9syYhb5ZGyvljXtlccEXAYUfORdG2GSFTRbZ/6m9 IMyY/kqKlFfoygz5Pwx0FQGFkG5KSHwVAYWwTv31B7XfkRny95c4SpusgUNX3ZZ0eaX1s8luDGm5 WhtdoOsVbbIJhGGg9CD4Bad+msMOeeMozuwQQfIxCj/IAtXOD5azwPkMTkDD6ZUP30kNn+lRQ7g0 irGecm1BjvgOIY/r6Ky4773APRbZ5XQZmiQbb2+qdlw0Wuiamsfr6cpsPe+/zFSdrTxZgdtIitJ1 Gkgqsnm+QYEWUqZ4vJ6U48P1PlLPE1hvoXOK3+vpLOD9Hb6hbiFpas2vJymzsX847xEWy/vdwqLa SIns/g2kZHULXEX382T7bqFzuqeop/Pb2XJkqe/l8GbFnpuqZan9thwi/R5CX1BYLYpXLldk4SHQ Y/wtwOV60X8TMHjcd8dNQXnTKSA+QblXCCQA+zfAXibM+PC7n8TxBMDLdBNwukXiBDhG1iFhLc8z gC8ybBl03NuBrhZuLZ/bmiJrej/oujEWS0Wfd4lgFpWjrmHvLisEAV3ZnGACurYoUuYg7uGsTHzG KAvoyiZxArq2SJyArgK6NlWGf8eBHjYOXZfKQrHNnkUlhNVVWF1Lhf2F1fVD1OsX0LVGkQroKqBr HlnYUACIpV6/iFEWVteGQ43eMXSV8ZOnVAMOjFKkRT+zq2Qv5xvLzrP0GgtHCLOrMLtWY15JYcMi YqB0ehtPQcFle77ArgK7DmoEEmZXYXZNc4k6pdKUlyKRX8e2W3w7EQMyftiUas81WTd7Fj1bG7ax lDsl2HGMXclFn7EQ1vHqWIuK/XAKLeapr6ljXQXAOL4bpXi6qNgPM9RmViTLERZiOVrxdFGxv821 TJ4hLMtnvJVOVOwHOcKAQ81KR5lFL+Pn8qgbHYqb6st+Fqq5YS+1pc1ZGn0ZwjJHxw0XxITBhe+W KlcmDKZUYQ1HzACs1Xxo/GVY/UgnN3Nrv2JN6HjPSe1lxmrDArXVFIaTOD7DBpntMFeSOAyOcVJM uA261DLU0BInSpvGqX4ATxQy0ZYdUhhQ5ELHYXCKMx3HU3p3eQl/O6VNZfwwKmOuwHmT4JQFMMNe 2/SNpLzQw9t3UdxUgFc2wzSzb3FoVYob50Rd/vywOwFeT6hEBOU6JcAr2rmnRxCRTXkCvArwWirr vYV6kpf7SrrgeAFeMYmjNcviJ04Zy/nKsPoGDorC/CLpRSS9zPIqrR8FuzKD+/dueGW2SF8qyJFc HbxiV2aD9dASxy12FUkvIunlgya94IdKmerG0iS7Z62huaYr2sY2MvNt2ccgYZUjs+DFXuXlGVLd +Cy0P3huB3W0ML0tmraM/qU+ptuwchtRIE6cwgtkl91RAtiKjBiREZPACp+mcciZaoSTYTZBcVFk c6Mz22hJQ63jREYMm+ORORKj/1aS1iiLHzllLm1Vt5Se2dwLfWFYS7UF2OqqAm/LvqEd2O7crRc4 foGV792vxYrwg3xbXP9le148fPcxL4xKqBArS3D4DPK9OeGTFz6lcf2oDyBhTUwopZcOC4UdL56c IXPGkhpHT/arYahytCQGlTSfsfe0r59QRYcjw8oTWhNPXg3mwp3znGTOqIpWHc5FPBd5hjCH+nhM p5OmqFHkVBvCrssz1GlImMVwNKZjyZwBB1ZlSJ2YDrfxjcJ0JvUM6RrLsoAFRI7HdPSZM4Z8sSx0 YjrM4Tsa09mkSWpe6QwwPXVhOhwNAI4G+YN/f94hAIm2WnAMYxI72+QLugg3M9idnv8C7eFR9FCl XZZgQ2yXKvyaZln0IrGZ3NQucxyT26UnY9a8LzPakduldruadhkeIbZrapYdpUNslqYM1bwtK2NO bGblcIQ0B1kJSWKzdF9Q87a8fA+5XWPDJmY559KQPjRPxyK+0WwYYB7sSmwHfWZAjfjCBn5p/NAG fmmSBuDdWjFqYs88E5w4wDQf/TyF2e+DGwNK/fx/AAAA//8DAFBLAwQUAAYACAAAACEAdD85esIA AAAoAQAAHgAIAWN1c3RvbVhtbC9fcmVscy9pdGVtMS54bWwucmVscyCiBAEooAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAITPwYoCMQwG4LvgO5Tcnc54EJHpeFkWvIm44LV0MjPFaVOaKPr2 Fk8rLOwxCfn+pN0/wqzumNlTNNBUNSiMjnofRwM/5+/VFhSLjb2dKaKBJzLsu+WiPeFspSzx5BOr okQ2MImkndbsJgyWK0oYy2SgHKyUMo86WXe1I+p1XW90/m1A92GqQ28gH/oG1PmZSvL/Ng2Dd/hF 7hYwyh8R2t1YKFzCfMyUuMg2jygGvGB4t5qq3Au6a/XHf90LAAD//wMAUEsDBBQABgAIAAAAIQDe icAjhgIAAHYKAAASAAAAd29yZC9mb250VGFibGUueG1s1JZdj6IwGIXvN9n/QLjfoVT8zOjEcfVy Lnbd7HWFIk1oS9qi47/ftxTFUYyS7E6yEgTfllIezznl+eWd596OKs2kmPrhE/I9KmKZMLGd+r/W q28j39OGiITkUtCpf6Daf5l9/fK8n6RSGO3B9UJP1NTPjCkmQaDjjHKin2RBBbSlUnFi4KfaBjJN WUy/y7jkVJgAIzQIFM2JgXvrjBXar0fbPzLaXqqkUDKmWsNkee7G44QJf1bPzttPBOEw658HvpF5 VS+IkJqG0LQj+dRHfdhChGEfogEc+2joB3aAOCNKU3PqiF05JZzlh2NVSU6EayiYibNjfUcUI5uc uibNttBQ6g2CG9Yf31VCgP6xgq/69D5W4mqc0dlVUIFxTiPD9AP391yBWDNOtfdG996Paua2wyUR DBQGqAckItgxnEXtRNDfIbKEieP5atUQWUBlOIrCutIQGdeVViLV84dunMeJLGSpGFWWSas+MOii h8bAwWoDA5MuNLhMqGoTSMreaXKtjpssep/B4jcYyTpft5LoHwXWHNt10eoUUhrpuv9fRqlQkNy8 QZAc3X3poiovLm3UUDqdteNqtVGDS0izViVdHwrq7nOeMwlNSZmbayHV9zzK5jweXPA0poLIr8Lp tqkQqqzYwVQkZxvFWmWE0aoykjVUBNaC7w5c9J5p3UlHS5uv+DxeIijMF6dKQ+KBeBlXMfU4iTXJ IGhvgHiFnLUIbNJGnwICL0+PDZKwOTtA/dfLbMH3QISoc87OYUFsX4ExchysINz2jwVh9dC23hzN 0kkQndcbwsEZtxRhV1ynB7sCd7NG93cRu9pcWwNFJ400JO6HRHjXGvVLiZ79AQAA//8DAFBLAwQU AAYACAAAACEAhQOMM20BAADEAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLBT8MgGMXvJv4PDfcO2s2ppO0SNTu5ZIk1Gm8Evm3EQhvA dfvvpXTtZvTgDfoeP973aLY4qCrag7Gy1jlKJgRFoHktpN7m6LVcxncoso5pwapaQ46OYNGiuL7K eEN5bWBt6gaMk2AjT9KW8iZHO+cairHlO1DMTrxDe3FTG8Wc35otbhj/ZFvAKSFzrMAxwRzDHTBu RiI6IQUfkc2XqQJAcAwVKNDO4mSS4LPXgVH2zwNBuXAq6Y6Nn+kU95IteC+O7oOVo7Ft20k7DTF8 /gS/r55fwqix1F1XHFCRCU6ddBUUGT4v/YobYK42hbJgDAvi8KnrtGLWrXz9Gwni4Ti6fiud2cBe dg9XJCTDl/uBtDZSOxBFSpI0JmmcpmWa0NmcEvIRTnTXDSYfOTTURwQR+Zlp39CgvE0fn8olGnnk tkxm9Oa+5w2uMI+/dQSq00D/IHYJU+qhIeFAHAC+TD/mz/+u+AYAAP//AwBQSwMEFAAGAAgAAAAh AKnIXKqMAAAA2gAAABMAKABjdXN0b21YbWwvaXRlbTEueG1sIKIkACigIAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAALJJsgrOLy1KTi1WCE7NSU0uSU0JLqnMSbVVinEMcNSLCPZRUgAL +CXmAgWBYkoKFbk5ecVWSbZKGSUlBVb6+sXJGam5icV6+QWpeUC5tPyi3MQSILcoXT8/LS0zOdUl P7k0NzWvRN/IwMBMPykzKSczP70osSCjEmoYVYyys9GHe8aOlwsAAAD//wMAUEsDBBQABgAIAAAA IQBs0TpLdQEAAN8IAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWzsVslugzAQvVfqPyDfG7YULBQS KYpy6qlNP8ABEyxhD7IdaPL1nUCXNO2hSK2UAyeG2XgzD/yYLV5k5TRcGwEqJf7EIw5XGeRC7VLy vFnfUeIYy1TOKlA8JQduyGJ+ezNrk5Zvn7i1mGkc7KJMolNSWlsnrmuykktmJlBzhbECtGQWb/XO haIQGV9BtpdcWTfwvMjVvGIWEZhS1Ia8dWt/060FndcaMm4MApFV308yocgcMeaiMW9Xp01EjiPS KIjDcNqFt5AfVqLBUMMqjBH3lCyZfuCFffd6H95HsSt/cG+g/p67BGtBXvgRzjLXp2fYzxqFiyWY aI4pwfWjUbMMV93ZGVSAa2V7Cz2M6gzZsMrtF0TDavX55ENK3Y6DbujevGDD96M4jEJvpGPIS/Bf dIQ0CHwaxv5IxzXQcfoyoqnvxyMd10AHpV5870V01I5BivWXh1WvIZ2kQ22FFEe+Br3U0BquUbwx fvZbMn8FAAD//wMAUEsDBBQABgAIAAAAIQBc9fHS5QEAAN4DAAAQAAgBZG9jUHJvcHMvYXBwLnht bCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxTy27bMBC8F+g/CLrHlNTESYw1 g8JBkUPbGLCSnFlqZROlSIJkjLhf36UUy3LbU32afXh2OLuCu7dOZ3v0QVmzzMtZkWdopG2U2S7z p/rLxU2ehShMI7Q1uMwPGPI7/vEDrL116KPCkBGFCct8F6NbMBbkDjsRZlQ2VGmt70Sk0G+ZbVsl 8d7K1w5NZFVRzBm+RTQNNhduJMwHxsU+/i9pY2XSF57rgyPBHGrsnBYR+fckRwMbE1DbKHStOuRX 15QfI1iLLQY+BzYAeLG+CbycX94AGzCsdsILGck+fvvp9grYJAGfndNKikjO8m9KehtsG7PH3oMs EQCbtgD5skH56lU88ALYNISvypCWa5o8IBLnxdYLtwu8qpLEMYSNFBpX9HzeCh0Q2CkBDyjSatdC kWTYx8UeZbQ+C+oXLbfKsx8iYDJtme+FV8JEMi+1DUGPtQvR81pFTdxUG+IeTtumWF3ysm8gcN6Y CAYNVDhX108Ijy29Lf5DbDkV22sYpE7kTOA44w/Wle2cMAcaPiJy+Gd4crW9Twfz7uF5crL4FxV3 Gyckracsi4qeebqBSQ02dCrY0FKPjKcEPJDhXqex9F+zxebY83chXdXz8LnyspoV9OvP6JijUxi/ I/4bAAD//wMAUEsBAi0AFAAGAAgAAAAhANrzjlm8AQAAMQgAABMAAAAAAAAAAAAAAAAAAAAAAFtD b250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAHpEat/MAAABOAgAACwAAAAAAAAAAAAAA AAD1AwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEALc//hVQBAABOBgAAHAAAAAAAAAAAAAAA AAAZBwAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQItABQABgAIAAAAIQACE310aywA AGkHAQARAAAAAAAAAAAAAAAAAK8JAAB3b3JkL2RvY3VtZW50LnhtbFBLAQItABQABgAIAAAAIQDt 0H0uiAIAAC0IAAAQAAAAAAAAAAAAAAAAAEk2AAB3b3JkL2Zvb3RlcjEueG1sUEsBAi0AFAAGAAgA AAAhAIc4Lv3qAQAAcQQAABAAAAAAAAAAAAAAAAAA/zgAAHdvcmQvaGVhZGVyMS54bWxQSwECLQAU AAYACAAAACEARK+EJeIAAABmAQAAGwAAAAAAAAAAAAAAAAAXOwAAd29yZC9fcmVscy9oZWFkZXIx LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAFXTEuGfAQAAawQAABIAAAAAAAAAAAAAAAAAMjwAAHdv cmQvZm9vdG5vdGVzLnhtbFBLAQItABQABgAIAAAAIQBSdB/ZoAEAAGUEAAARAAAAAAAAAAAAAAAA AAE+AAB3b3JkL2VuZG5vdGVzLnhtbFBLAQItABQABgAIAAAAIQCWta3ilgYAAFAbAAAVAAAAAAAA AAAAAAAAANA/AAB3b3JkL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEA3whQSL8EAAAq DgAAEQAAAAAAAAAAAAAAAACZRgAAd29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAfSCu DCcMAADQWgAADwAAAAAAAAAAAAAAAACHSwAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAh ACbd+AbiAAAAVQEAABgAAAAAAAAAAAAAAAAA21cAAGN1c3RvbVhtbC9pdGVtUHJvcHMxLnhtbFBL AQItABQABgAIAAAAIQCEXLDrDAsAAJ+2AAASAAAAAAAAAAAAAAAAABtZAAB3b3JkL251bWJlcmlu Zy54bWxQSwECLQAUAAYACAAAACEAdD85esIAAAAoAQAAHgAAAAAAAAAAAAAAAABXZAAAY3VzdG9t WG1sL19yZWxzL2l0ZW0xLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAN6JwCOGAgAAdgoAABIAAAAA AAAAAAAAAAAAXWYAAHdvcmQvZm9udFRhYmxlLnhtbFBLAQItABQABgAIAAAAIQCFA4wzbQEAAMQC AAARAAAAAAAAAAAAAAAAABNpAABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQCpyFyq jAAAANoAAAATAAAAAAAAAAAAAAAAALdrAABjdXN0b21YbWwvaXRlbTEueG1sUEsBAi0AFAAGAAgA AAAhAGzROkt1AQAA3wgAABQAAAAAAAAAAAAAAAAAnGwAAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsB Ai0AFAAGAAgAAAAhAFz18dLlAQAA3gMAABAAAAAAAAAAAAAAAAAAQ24AAGRvY1Byb3BzL2FwcC54 bWxQSwUGAAAAABQAFAAYBQAAXnEAAAAA --_004_6B92B1E73D1E7B468E5C97CAE569CBA1068A2F8B6BMBX05exg5exgh_-- From br@brianrosen.net Wed Feb 22 14:54:36 2012 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 96D6E21F85F0 for ; Wed, 22 Feb 2012 14:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.845 X-Spam-Level: X-Spam-Status: No, score=-101.845 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNAKfuEtjbyK for ; Wed, 22 Feb 2012 14:54:35 -0800 (PST) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.253]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB5321F8518 for ; Wed, 22 Feb 2012 14:54:35 -0800 (PST) X-ASG-Debug-ID: 1329951273-0491e51f0284040001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id C81aCdlvZljlhKTC; Wed, 22 Feb 2012 14:54:33 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.45]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1S0L4z-000vc0-Nc; Wed, 22 Feb 2012 14:54:34 -0800 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [Ecrit] Input on ECRIT Additional Data Draft from the NENA Add'l Data Work Group Content-Type: multipart/mixed; boundary="Apple-Mail=_98254767-7E74-4FBB-BA07-40AE61B23885" From: Brian Rosen In-Reply-To: <6B92B1E73D1E7B468E5C97CAE569CBA1068A2F8B6B@MBX05.exg5.exghost.com> Date: Wed, 22 Feb 2012 17:54:28 -0500 Message-Id: <8276E31E-1DF1-4F38-AAC9-89071B99582C@brianrosen.net> References: <6B92B1E73D1E7B468E5C97CAE569CBA1068A2F8B6B@MBX05.exg5.exghost.com> To: Matt Serra X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1329951273 X-Barracuda-URL: http://64.34.111.253:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.94 X-Barracuda-Spam-Status: No, SCORE=0.94 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332, MIME_QP_LONG_LINE, MIME_QP_LONG_LINE_2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.89236 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 0.00 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.82 MIME_QP_LONG_LINE_2 RAW: Quoted-printable line longer than 76 chars Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Input on ECRIT Additional Data Draft from the NENA Add'l Data Work Group 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, 22 Feb 2012 22:54:36 -0000 --Apple-Mail=_98254767-7E74-4FBB-BA07-40AE61B23885 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Forgive him and blame me. Attached is a text version of this file: --Apple-Mail=_98254767-7E74-4FBB-BA07-40AE61B23885 Content-Disposition: attachment; filename="nena additional data comments.txt" Content-Type: text/plain; x-mac-hide-extension=yes; x-unix-mode=0644; name="nena additional data comments.txt" Content-Transfer-Encoding: quoted-printable 3. Call-Info Specification The language in this section indicates the Device, Access Provider, and = Intermediary each MAY provide this info. To be ensure each call is = accompanied by at least one instance of Call data, we recommend noting: =E2=80=A2 Devices not utilizing a service provider to place a call = must provide it =E2=80=A2 Where part of the call, the service provider MUST = provide a basic / minimal record Data Provider ID: =20 a) The usage is =E2=80=9Cconditional=E2=80=9D yet the rules only = define a =E2=80=9Cshould=E2=80=9D. Can we provide better guidance on = when this will be populated? Otherwise, should it be =E2=80=9Coptional=E2= =80=9D? Perhaps changing the following to something like =E2=80=9CMust = provide the ID if the service provider is located within a jurisdiction = maintaining such ID=E2=80=99s.=E2=80=9D This data SHOULD be provided if the local jurisdiction maintains such an = ID list. b) This field is missing from the schema. Data Provider ID Type: =20 This field is missing from the current draft, and denotes the type of ID = provided within the Data Provider ID (e.g. NENA Company ID). Contact URI: =20 a) There is a typo in the XML element. It reads as = when it should read as b) Within the =E2=80=9CDescription=E2=80=9D we recommend the = various permutations of contact information be clarified. For example, = when the last two sentences are read together, it is may not be obvious = they are referring to two independent scenarios. The SHOULD clause = would benefit by being better defined and reconciled with the = =E2=80=9Cusage=E2=80=9D definition. c) =E2=80=9CHow Used by Calltaker=E2=80=9D may warrant = clarification. Minimally the word =E2=80=9Cstructure=E2=80=9D should be = removed from the end of the sentence: How Used by Call Taker: To = contact the supplier of entity that controls access to the provided = additional Call data provider structure. =0C Data Provider Language(s) Supported - Nits - rewrite to Reason for Need: Information needed to determine if emergency service = authority can communicate with the service provider or if a language = line will be needed. How Used by Call Taker: If call taker cannot speak language(s)supported = by the service provider, at translation service will need to be added in = to the conversation Recommended =E2=80=9CvCARD of Provided-By=E2=80=9D and =E2=80=9CvCARD = for Subscriber Data=E2=80=9D: =20 a) It is preferable to give guidance on what portions of the vCARD = data structure should be populated, even as only a recommendation. = Using the NENA Company ID field as a guide, a possible example of = minimum recommended fields is as follows: =E2=80=A2 ORG =E2=80=A2 ADR =E2=80=A2 TEL (Subscriber or Business contact for provider) (name = =E2=80=93 pref voice, fax, cell) =E2=80=A2 EMAIL =E2=80=A2 N(ame) =E2=80=A2 TITLE (Provider only) =E2=80=A2 LANGUAGE (Subscriber only) b) XML Schema Issue: Additional Data Provider Import of XML Schema = is incorrect, because of the dependency on the vCARD XML Schema. Recommended name change for =E2=80=9CvCard of Provided-By=E2=80=9D and = =E2=80=9CvCard for Subscriber Data=E2=80=9D: RFC 6351 refers to the XML = representation of =E2=80=9CvCARD=E2=80=9D as =E2=80=9CxCARD=E2=80=9D. = To minimize confusion, it may be better to refer to these fields as = =E2=80=9CxCARD . . .=E2=80=9D. We recommend this be changed throughout = the document. Service Environment: =20 a) At one point, we noted the valid values should be kept in a = registry. =46rom an operational perspective, there is interest in = expanding the valid-value list (perhaps to contain =E2=80=98Public=E2=80=99= for public network) =E2=80=93 although the feasibility of this has not = been established. b) For =E2=80=9CReason for Need=E2=80=9D, it may be valuable to = note that this field supports backwards compatibility with Legacy ALI. = This comment may become relevant if this element cannot be reliably = maintained going forward. Furthermore the Work Group notes this field = cannot be used to reliably dictate manpower or equipment dispatch, as = the field is not consistently applied, and the valid value set is not = all-encompassing. At best this field can influence such decisions. c) Similar comments for =E2=80=9CHow used by Call Taker=E2=80=9D = =E2=80=93 equipment and manpower needs are not dictated by this field. d) We ask that guidelines for how the Business versus Residential = determination is made. We believe this would assist both the providers = and consumers of this data. For example, it could be noted that Service = Environment is set based on the type of rate plan/offer or facilities = used to deliver the service. =20 Service Delivered by Provider to End User: a) Nit - rewrite to This defines the type of service the end user has subscribed to. The = implied mobility of this service can not be relied upon. A registry = will reflect the following initial valid entries: b) We recommend the value =E2=80=9CRelay Service=E2=80=9D (where = the call originator is a human intermediary providing a language or = other communications translation service) be added to the initial = registry values. c) We recommend a value such as =E2=80=9CRemote Service=E2=80=9D or = =E2=80=9COff Premise Extension=E2=80=9D be added to support backwards = compatibility with Legacy ALI. While there are a number of scenarios, = especially in IP-delivered communications, where this cannot be reliably = ascertained, it should not be lost from legacy services, and should be = available for use by service providers when it is known. d) We recommend a new field be created to describe the nature of = the service delivered as =E2=80=9CFixed=E2=80=9D =E2=80=9CMobile=E2=80=9D = or =E2=80=9CNomadic=E2=80=9D. This field would provide great value even = when set based on the typical / normal service usage; it need not = describe whether the service is =E2=80=9Cnomadic=E2=80=9D, =E2=80=9Cfixed=E2= =80=9D, or =E2=80=9Cmobile=E2=80=9D for that specific call. Device Classification =E2=80=93 Nits & proposed clarifications:=20 a) Nits / clarifications - rewrite to: Description: This data element defines the kind of device making the = emergency call. If the device provides the data structure, the device = information should be provided. If the service provider provides the = structure and it knows what the device is, the service provider should = provide the device information. Often the carrier does not know what = the device is. It is possible to receive 2 Additional Data Associated = with a Caller data structures, one created by the device and one created = by the service provider. This Information describes the about the = device, not how it is being used. This data element defines the kind of = device making the emergency call. A registry will reflect the following = valid entries: Reason for Need: The device classification describes the capability of = the calling device and assists in identifying the meaning of the 9-1-1 = location information that is being presented. For example, does the = device require human intervention to initiate a call or is this call the = result of programmed instructions?. Does the calling device have the = ability to rebid for location or condition changes? Is this device = interactive or a one-way reporting device? b) It would further help to note this information can be used by = call takers to help interpret the location of the device, or the = environment this device is being used in, device capabilities, etc. Device Identifier / Type of Device Identifier: Here we define the ID = first, and then the type, but for Device Specific information, we define = the Type, and then the Data. Is it better to be consistent, even if = only for document consistency? =20 Type of Device Identifier: We believe this should be =E2=80=9CConditional= =E2=80=9D rather than =E2=80=9COptional=E2=80=9D where it must be = provided if the Device Identifier is provided. Device/Service Specific Additional Data Structure Type: The Description includes initial values for data which may be better = represented in the =E2=80=9CAdditional Data about a Caller=E2=80=9D or = =E2=80=9CAdditional Data about a Location=E2=80=9D data structures. = Possible examples of such values are: =E2=80=A2 Hazmat International Association of Fire Chiefs =E2=80=A2 DHS/EPA E-Plan for HazMat =E2=80=A2 NFPA - National Fire Protection Association =E2=80=A2 National Alliance for Public Safety GIS (NA-PSG) =E2=80=A2 US DOT Pipeline and Hazardous Materials Safety = Administration (PHMSA) examples of additional data. =E2=80=A2 Fire Service Data Model =E2=80=A2 Smart Building (NIST) As opposed to the following values which seem to be Call or Telemetry = related, and therefore belong in the =E2=80=9CAdditional Data about a = Call=E2=80=9D structure: =E2=80=A2 NPAC=20 =E2=80=A2 VEDS =E2=80=A2 IEEE 1512 - USDOT Model for traffic incidents We recommend that only data which does not fit into Additional Location = or Additional Caller data be communicated here. For many of the = provided examples, the data provider should be able to place the data = in their respective Additional Data containers. For example, the = following seem to belong within the Device/Service specific data: a) NPAC=20 b) VEDS c) IEEE 1512 - USDOT Model for traffic incidents Device/Service Specific Additional Data Structure: =20 We recommend the last sentence be struck. It appears to be a = placeholder: Description: A URI representing additional data whose schema is = specific to the device or service which created it. An example is the = VEDs structure for a vehicle telematics device. The URI, when = dereferenced, MUST yield a data structure defined by the Device/service = Service specific additional data type value. Different data may be = created by each classification; i.e., telematics creates VEDS data set - = can be different types of data depending on device. May want to describe = type of data for each device. vCARD for Subscriber's Data:=20 a) This field is shown as =E2=80=9CRequired=E2=80=9D. We believe = it should be conditional, if not optional as there are cases where the = data provider is not aware of this information, nor reasonably able to = discover it. Examples are pre-paid phones, uninitialized phones, and = perhaps some telematics services. =20 b) The Description contradicts the opening of section 7, which = states =E2=80=9CThe contact location is not necessarily the location of = the caller or incident, but is rather the nominal contact address.=E2=80=9C= This could be rectified by striking the last sentence: Description: Information known by the service provider or device about = the subscriber; i.e., Name, Address, Calling Party Number, Main = Telephone Number and any other data. If the subscriber is an = enterprise, this is the vCARD of the enterprise and the Company Name is = used not the Name of the Caller. The telephone number is the main = telephone number at the location of the call. The address should be = where the call is originating from. c) We recommend references to =E2=80=9CvCARD=E2=80=9D be replaced = by =E2=80=9CxCARD=E2=80=9D throughout, per RFC 6351 Privacy Indicator: =20 Early versions of this specification referred to a =E2=80=9CPrivacy = Indicator=E2=80=9D field. We now understand this function is served by = fields in the PPI and PAI. We recommend an informative statement be = added to the Introduction to clarify this. For example, one might say: In regions where callers can elect to suppress certain personally = identifying information, the network or PSAP functionality can inspect = privacy flags within the identity header to drive what information is = passed, stored, or displayed to comply with local policy or law. --Apple-Mail=_98254767-7E74-4FBB-BA07-40AE61B23885 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 22, 2012, at 5:29 PM, Matt Serra wrote: > [Resubmitting due to file size restrictions] > =20 > I am submitting the attached Microsoft Word document on behalf of = NENA=92s Additional Data WG. This feedback is submitted against = http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-02, and = includes the Additional Data WG=92s findings upon reviewing V02 of the = Additional Data draft. > =20 > Should you have follow up questions, or prefer to receive this = material in a different format, please let me know. > =20 > Thank you, > =20 > Matt Serra > =20 > Matthew A. Serra, ENP > Sr. Director, Product Management=20 > Rave Mobile Safety | Smart911 > Mobile: 201.245.1557 > mserra@ravemobilesafety.com > =20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_98254767-7E74-4FBB-BA07-40AE61B23885-- From jbakker@rim.com Thu Feb 23 05:09:13 2012 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 A232A21F86CF for ; Thu, 23 Feb 2012 05:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ni7TDEoUry9Y for ; Thu, 23 Feb 2012 05:09:10 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id CB1B521F87D8 for ; Thu, 23 Feb 2012 05:09:05 -0800 (PST) X-AuditID: 0a41282f-b7f296d0000023a6-d0-4f463a7087ab Received: from XHT101CNC.rim.net (xht101cnc.rim.net [10.65.12.214]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 19.C9.09126.07A364F4; Thu, 23 Feb 2012 13:09:04 +0000 (GMT) Received: from XHT141CNC.rim.net (10.65.22.70) by XHT101CNC.rim.net (10.65.12.214) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 23 Feb 2012 08:09:03 -0500 Received: from XCT102ADS.rim.net (10.67.111.43) by XHT141CNC.rim.net (10.65.22.70) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 23 Feb 2012 08:09:04 -0500 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.01.0339.001; Thu, 23 Feb 2012 07:09:02 -0600 From: John-Luc Bakker To: "christer.holmberg@ericsson.com" , "pkyzivat@alum.mit.edu" , "ecrit@ietf.org" Thread-Topic: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning Thread-Index: AQHM78PyDHznfkKTnk62En7ZjB3JuJZHeJgAgAAYsYCAABfRgIAAALeAgAAIA4CAAASJgIAAASqAgAAjLYCAAAD8gIACnWcc Date: Thu, 23 Feb 2012 13:09:02 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA350EF737@XMB104ADS.rim.net> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D915595@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.253] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIKsWRmVeSWpSXmKPExsXC5chzTbfAys3f4O9VA4sLMw8zWjQuespq sWLDAVYHZo+/7z8wefz6epXNY8mSn0wBzFENjDaJeXn5JYklqQopqcXJtko+qemJOQoBRZll icmVCi6Zxck5iZm5qUVKCpkptkomSgoFOYnJqbmpeSW2SokFBal5KUp2XAoYwAaoLDNPITUv OT8lMy/dVskz2F/XwsLUUtdQyU4XCST848543PyXsaBTqmLH8oksDYxTRLsYOTkkBEwk2q+v ZoOwxSQu3FsPZHNxCAn0Mkm8/LeNEcJZyihx5EwfVGYZo8SbPYdYIZzNjBJzV51hBulnE1CX 2LpiOzNIQkRgLqPEt74/YAlhAQ+J92e6mboYOYASnhL9f4VAwiICeRJ3b7YwgoRZBFQlLjd6 gYR5BdwkDp07zAhicwpESDyedIsJxGYUkJXYffY6mM0sIC5x68l8JoizBSSW7DnPDGGLSrx8 /I8VwlaUWNT5nRGiXk/ixtQpbBC2tsSyha+ZIXYJSpyc+YQFxBYSkJFobdvFNoFRfBaSFbOQ tM9C0j4LSfsCRpZVjIK5GcUGZgbJecl6RZm5enmpJZsYwWlFQ38HY99erUOMAhyMSjy8FXJu /kKsiWXFlbmHGCU4mJVEeCVUgUK8KYmVValF+fFFpTmpxYcYLYCBMpFZijs5H5jy8krijQ0M UDhK4ryLV2r5CwmkA5NVdmpqQWoRTCsTB6dUA2POmzf1MTOW7Hpkk7hz1oYa45aE1Ej5LXO6 b1eHb5T9aKI6/ely1s6EDNYtNit03kYqucofV5/EeaXeUk4m5H3bk+6XbUdV7rxQ8qn/nN1/ zklLVCvpgt+MqKmX8vw0AzKV77ZcCDf5fNbtk/VzL/XDbW5VZ1YzLzwgF/5r2tGdfQzG860X +ymxFGckGmoxFxUnAgAK3bj0RAMAAA== Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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, 23 Feb 2012 13:09:13 -0000 Hi, Was the scenario considered where a UA is unaware it is making an emergency= call? For example the user reads the local emergency number (applicable in= that region) (I believe the fire brigade in France can be reached by dialin= g "18") on a sign (then observes an emergency), enters the local number, and= the request with that number is sent by the UA. Does the nonce solution recommend a UA to include the nonce in every SIP req= uest on the off change it turns out to be a request for emergency? Regards, John-Luc --- John-Luc Bakker Standards Manager Research In Motion Corporation Mobile +1 (908) 463 7321 Office +1 (972) 373-1761 Internal (820) 63761 E-mail jbakker@rim.com Sent from my BlackBerry Torch (9810) ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, February 21, 2012 09:13 AM=0A= To: Paul Kyzivat ; ecrit@ietf.org Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning Hi, > Ignoring the problem of callback from a PSTN-based psap (which I commented= on in earlier message), why isn't the following sufficient: > > - the caller uses callerprefs to indicate that it doesn't want to > talk to an automaton. > > - the original emergency caller encodes its contact for the emergency call= with something *it* understands (e.g. a nonce) that it will subsequently tr= eat as granting priority to an incoming > call carrying it. > > In this way nobody but the calling UA need know the nonce mechanism. It ne= ed not be standardized. (And it need not be used at all if the caller is wil= ling to tolerate some priority spit.) The > callerprefs will prevent the rest of the infrastructure from diverting the= call. This would then be understood to be a mechanism that anybody can use,= not just emergency calls. > > Of course this would require widespread support for callerprefs. But any s= olution here is going to require widespread support of something. It is not only the calling UA that needs to know. Intermediaries also need t= o identify a callback, in order to give special treatment. Regards, Christer On 2/21/12 8:03 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> I am NOT talking about replacing GRUU with the feature tag. GRUU is >> still the preferred way of routing to the UA. >> >> I am just saying that a "side effect" of a feature tag based >> indicator is that it CAN also be used for routing. I am not saying >> that we shall mandate support of feature tag based routing. The main >> purpose of the feature tag is still as indicator. > > But wouldn't it then be sufficient to have just a SIP header field set > by the PSAP when it sends the callback that says "callback"? > > Anything else would just be replicating existing functionality. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From br@brianrosen.net Thu Feb 23 06:06:36 2012 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 AAFB821F881A for ; Thu, 23 Feb 2012 06:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.312 X-Spam-Level: X-Spam-Status: No, score=-102.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVec4QINBjgG for ; Thu, 23 Feb 2012 06:06:35 -0800 (PST) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id C341C21F8817 for ; Thu, 23 Feb 2012 06:06:35 -0800 (PST) X-ASG-Debug-ID: 1330005978-04d0354d10a35d0001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id r9LJguhnzh81GPwq; Thu, 23 Feb 2012 06:06:18 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.45]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1S0ZJJ-000xgz-Cr; Thu, 23 Feb 2012 06:06:17 -0800 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <155970D1DA8E174F9E46039E10E2AA350EF737@XMB104ADS.rim.net> Date: Thu, 23 Feb 2012 09:06:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <155970D1DA8E174F9E46039E10E2AA350EF737@XMB104ADS.rim.net> To: John-Luc Bakker X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1330005978 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=BSF_SC1_TG070 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.89296 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_SC1_TG070 Custom Rule TG070 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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, 23 Feb 2012 14:06:36 -0000 To support emergency calls, the UA pretty much has to know it's an = emergency call unless the access network and the origination network are = the same entity, or have some kind of relationship. We have a number of = tools that make this possible. For example, LoST returns the local dial = string(s) for emergency calls in the area where the UA is located. = Phonebcp states the UA queries its access network for its own location, = then uses that to query LoST for the PSAP URI(s) and local dial = string(s). In a case where there is a lot of knowledge, a proxy server can add the = nonce and the origination network can also arrange for the Contact to be = constructed correctly. IMS actually does have the UE recognizing local = emergency dial strings. =20 Brian On Feb 23, 2012, at 8:09 AM, John-Luc Bakker wrote: > Hi, >=20 > Was the scenario considered where a UA is unaware it is making an = emergency call? For example the user reads the local emergency number = (applicable in that region) (I believe the fire brigade in France can be = reached by dialing "18") on a sign (then observes an emergency), enters = the local number, and the request with that number is sent by the UA.=20 >=20 > Does the nonce solution recommend a UA to include the nonce in every = SIP request on the off change it turns out to be a request for = emergency? >=20 > Regards, >=20 > John-Luc > ---=20 > John-Luc Bakker > Standards Manager > Research In Motion Corporation=20 > Mobile +1 (908) 463 7321 > Office +1 (972) 373-1761 > Internal (820) 63761 > E-mail jbakker@rim.com >=20 > Sent from my BlackBerry Torch (9810) >=20 > ----- Original Message ----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, February 21, 2012 09:13 AM > To: Paul Kyzivat ; ecrit@ietf.org = > Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New = Beginning >=20 >=20 > Hi,=20 >=20 >> Ignoring the problem of callback from a PSTN-based psap (which I = commented on in earlier message), why isn't the following sufficient: >>=20 >> - the caller uses callerprefs to indicate that it doesn't want to >> talk to an automaton. >>=20 >> - the original emergency caller encodes its contact for the emergency = call with something *it* understands (e.g. a nonce) that it will = subsequently treat as granting priority to an incoming=20 >> call carrying it. >>=20 >> In this way nobody but the calling UA need know the nonce mechanism. = It need not be standardized. (And it need not be used at all if the = caller is willing to tolerate some priority spit.) The=20 >> callerprefs will prevent the rest of the infrastructure from = diverting the call. This would then be understood to be a mechanism that = anybody can use, not just emergency calls. >>=20 >> Of course this would require widespread support for callerprefs. But = any solution here is going to require widespread support of something. >=20 > It is not only the calling UA that needs to know. Intermediaries also = need to identify a callback, in order to give special treatment. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > On 2/21/12 8:03 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>> I am NOT talking about replacing GRUU with the feature tag. GRUU is=20= >>> still the preferred way of routing to the UA. >>>=20 >>> I am just saying that a "side effect" of a feature tag based=20 >>> indicator is that it CAN also be used for routing. I am not saying=20= >>> that we shall mandate support of feature tag based routing. The main=20= >>> purpose of the feature tag is still as indicator. >>=20 >> But wouldn't it then be sufficient to have just a SIP header field = set=20 >> by the PSAP when it sends the callback that says "callback"? >>=20 >> Anything else would just be replicating existing functionality. >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Thu Feb 23 06:09:53 2012 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 8FE4021F864F for ; Thu, 23 Feb 2012 06:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.104 X-Spam-Level: X-Spam-Status: No, score=-10.104 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4uN4INChS4t for ; Thu, 23 Feb 2012 06:09:52 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 28D8221F85D4 for ; Thu, 23 Feb 2012 06:09:51 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-bd-4f4648ae9cce Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 92.04.01970.EA8464F4; Thu, 23 Feb 2012 15:09:50 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Thu, 23 Feb 2012 15:09:50 +0100 From: Christer Holmberg To: Brian Rosen , John-Luc Bakker Date: Thu, 23 Feb 2012 15:09:50 +0100 Thread-Topic: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning Thread-Index: AczyNFwPuZ3+uBzlR0mC5m2Xs2yD+wAAEHiQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D96128C@ESESSCMS0356.eemea.ericsson.se> References: <155970D1DA8E174F9E46039E10E2AA350EF737@XMB104ADS.rim.net> 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== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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, 23 Feb 2012 14:09:54 -0000 Hi,=20 > To support emergency calls, the UA pretty much has to know it's an emerge= ncy call unless the access network and the origination network are the same= entity, or have some kind of relationship. =20 > We have a number of tools that make this possible. For example, LoST ret= urns the local dial string(s) for emergency calls in the area where the UA = is located. Phonebcp states the UA queries=20 > its access network for its own location, then uses that to query LoST for= the PSAP URI(s) and local dial string(s). > > In a case where there is a lot of knowledge, a proxy server can add the n= once and the origination network can also arrange for the Contact to be con= structed correctly.=20 Correct. 3GPP has a requirement for that, if the proxy server (P-CSCF) dete= rmines the call to be an emergency call. Regards, Christer On Feb 23, 2012, at 8:09 AM, John-Luc Bakker wrote: > Hi, >=20 > Was the scenario considered where a UA is unaware it is making an emergen= cy call? For example the user reads the local emergency number (applicable = in that region) (I believe the fire brigade in France can be reached by dia= ling "18") on a sign (then observes an emergency), enters the local number,= and the request with that number is sent by the UA.=20 >=20 > Does the nonce solution recommend a UA to include the nonce in every SIP = request on the off change it turns out to be a request for emergency? >=20 > Regards, >=20 > John-Luc > --- > John-Luc Bakker > Standards Manager > Research In Motion Corporation > Mobile +1 (908) 463 7321 > Office +1 (972) 373-1761 > Internal (820) 63761 > E-mail jbakker@rim.com >=20 > Sent from my BlackBerry Torch (9810) >=20 > ----- Original Message ----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, February 21, 2012 09:13 AM > To: Paul Kyzivat ; ecrit@ietf.org=20 > > Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New=20 > Beginning >=20 >=20 > Hi, >=20 >> Ignoring the problem of callback from a PSTN-based psap (which I comment= ed on in earlier message), why isn't the following sufficient: >>=20 >> - the caller uses callerprefs to indicate that it doesn't want to =20 >> talk to an automaton. >>=20 >> - the original emergency caller encodes its contact for the emergency=20 >> call with something *it* understands (e.g. a nonce) that it will subsequ= ently treat as granting priority to an incoming call carrying it. >>=20 >> In this way nobody but the calling UA need know the nonce mechanism.=20 >> It need not be standardized. (And it need not be used at all if the call= er is willing to tolerate some priority spit.) The callerprefs will prevent= the rest of the infrastructure from diverting the call. This would then be= understood to be a mechanism that anybody can use, not just emergency call= s. >>=20 >> Of course this would require widespread support for callerprefs. But any= solution here is going to require widespread support of something. >=20 > It is not only the calling UA that needs to know. Intermediaries also nee= d to identify a callback, in order to give special treatment. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > On 2/21/12 8:03 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>> I am NOT talking about replacing GRUU with the feature tag. GRUU is=20 >>> still the preferred way of routing to the UA. >>>=20 >>> I am just saying that a "side effect" of a feature tag based=20 >>> indicator is that it CAN also be used for routing. I am not saying=20 >>> that we shall mandate support of feature tag based routing. The main=20 >>> purpose of the feature tag is still as indicator. >>=20 >> But wouldn't it then be sufficient to have just a SIP header field=20 >> set by the PSAP when it sends the callback that says "callback"? >>=20 >> Anything else would just be replicating existing functionality. >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From laura.liess.dt@googlemail.com Thu Feb 23 07:30:57 2012 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 9D15021F8745 for ; Thu, 23 Feb 2012 07:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ad603u8jBi5 for ; Thu, 23 Feb 2012 07:30:56 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 24A0721F873D for ; Thu, 23 Feb 2012 07:30:52 -0800 (PST) Received: by wibhm9 with SMTP id hm9so1043744wib.31 for ; Thu, 23 Feb 2012 07:30:52 -0800 (PST) Received-SPF: pass (google.com: domain of laura.liess.dt@googlemail.com designates 10.180.80.35 as permitted sender) client-ip=10.180.80.35; Authentication-Results: mr.google.com; spf=pass (google.com: domain of laura.liess.dt@googlemail.com designates 10.180.80.35 as permitted sender) smtp.mail=laura.liess.dt@googlemail.com; dkim=pass header.i=laura.liess.dt@googlemail.com Received: from mr.google.com ([10.180.80.35]) by 10.180.80.35 with SMTP id o3mr4019456wix.5.1330011052372 (num_hops = 1); Thu, 23 Feb 2012 07:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6998o3GO3ufTdBk0gJMg1BbA3P4fkauO2jmOmGUM8qk=; b=A1A1Sbaqu1OhOHqFjObrAP1Q4ZolCppnf68XQ833CUQwHKewSUI6TH/pOLQUYJNR9z qHQqu8ERtbNOHNyXkXTKxCVCeI78N9Q585/YhKgAYxPg8JiG/pinUhEZnnIFbxI7IsAO tljSLqWfCF5hlPVg3YAVaDMQxoknD+jGya1GA= MIME-Version: 1.0 Received: by 10.180.80.35 with SMTP id o3mr3280765wix.5.1330011052272; Thu, 23 Feb 2012 07:30:52 -0800 (PST) Received: by 10.227.112.206 with HTTP; Thu, 23 Feb 2012 07:30:52 -0800 (PST) In-Reply-To: <8276E31E-1DF1-4F38-AAC9-89071B99582C@brianrosen.net> References: <6B92B1E73D1E7B468E5C97CAE569CBA1068A2F8B6B@MBX05.exg5.exghost.com> <8276E31E-1DF1-4F38-AAC9-89071B99582C@brianrosen.net> Date: Thu, 23 Feb 2012 16:30:52 +0100 Message-ID: From: Laura Liess To: Brian Rosen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Input on ECRIT Additional Data Draft from the NENA Add'l Data Work Group 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, 23 Feb 2012 15:30:57 -0000 Hi Brian, Concerning the NENA comment on Data Provider ID and Data Provider ID Type: The Data Provider ID is needed also in other countries. In Germany, according to the new regulatory requirements on emergency calling, the VSP must add its Service Provider ID to the SIP INVITE. The Service Provider ID is issued by the German regulator so the Data Provider ID Type would be usefull. Thank you Laura 2012/2/22 Brian Rosen : > Forgive him and blame me. > > Attached is a text version of this file: > > > On Feb 22, 2012, at 5:29 PM, Matt Serra wrote: > >> [Resubmitting due to file size restrictions] >> >> I am submitting the attached Microsoft Word document on behalf of NENA= =E2=80=99s Additional Data WG. =C2=A0This feedback is submitted against htt= p://tools.ietf.org/html/draft-ietf-ecrit-additional-data-02, and includes t= he Additional Data WG=E2=80=99s findings upon reviewing V02 of the Addition= al Data draft. >> >> Should you have follow up questions, or prefer to receive this material = in a different format, please let me know. >> >> Thank you, >> >> Matt Serra >> >> Matthew A. Serra, ENP >> Sr. Director, Product Management >> Rave Mobile Safety | Smart911 >> Mobile: =C2=A0201.245.1557 >> mserra@ravemobilesafety.com >> >> ___________= ____________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From jbakker@rim.com Thu Feb 23 07:36:08 2012 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 D981421F87DB for ; Thu, 23 Feb 2012 07:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7psLnqFpRJm for ; Thu, 23 Feb 2012 07:36:08 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id B53F121F87D8 for ; Thu, 23 Feb 2012 07:36:07 -0800 (PST) X-AuditID: 0a41282f-b7f296d0000023a6-97-4f465ce66983 Received: from XHT109CNC.rim.net (xht109cnc.rim.net [10.65.12.218]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 0A.B4.09126.6EC564F4; Thu, 23 Feb 2012 15:36:06 +0000 (GMT) Received: from XCT105ADS.rim.net (10.67.111.46) by XHT109CNC.rim.net (10.65.12.218) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 23 Feb 2012 10:36:06 -0500 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.01.0339.001; Thu, 23 Feb 2012 09:36:04 -0600 From: John-Luc Bakker To: Christer Holmberg , Brian Rosen Thread-Topic: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning Thread-Index: AQHM78PyDHznfkKTnk62En7ZjB3JuJZHeJgAgAAYsYCAABfRgIAAALeAgAAIA4CAAASJgIAAASqAgAAjLYCAAAD8gIACnWccgAB0kICAAAECAP//spAQ Date: Thu, 23 Feb 2012 15:36:04 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA350EFC87@XMB104ADS.rim.net> References: <155970D1DA8E174F9E46039E10E2AA350EF737@XMB104ADS.rim.net> <7F2072F1E0DE894DA4B517B93C6A05852C3D96128C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D96128C@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.254] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKKsWRmVeSWpSXmKPExsXC5chzS/dZjJu/weY/uhZP709js7gw8zCj ReOip6wWKzYcYHVg8fj7/gOTx/1vf9k9fn29yuaxZMlPpgCWqAZGm8S8vPySxJJUhZTU4mRb JZ/U9MQchYCizLLE5EoFl8zi5JzEzNzUIiWFzBRbJRMlhYKcxOTU3NS8ElulxIKC1LwUJTsu BQxgA1SWmaeQmpecn5KZl26r5Bnsr2thYWqpa6hkp4sEEv5xZxye3MBesMOgoufcH/YGxo3q XYycHBICJhKXD35nhLDFJC7cW8/WxcjFISTQyyTRdXE/O4SzjFHi082fTCBVQgKbGSU2dniA 2GwC6hJbV2xnBrFFBCIlDvctA+rm4GAWiJC4t08VJCws4CFxfPsLsLCIgKdE/18hkJEiAk2M El/mrQJrZRFQlfjw/BcbiM0r4CaxreUHC8TeM4wSO/5tANvLCTTz8I1DYA2MQJd+P7UGLM4s IC5x68l8JogPBCSW7DnPDGGLSrx8/I8VZLGEgKLE69N1EOU6Egt2f2KDsLUlli18zQyxV1Di 5MwnLBAvyki0tu1im8AoMQvJhllI2mchaZ+FpH0BI8sqRsHcjGIDM4PkvGS9osxcvbzUkk2M 4PSjob+DsW+v1iFGAQ5GJR7e6HA3fyHWxLLiytxDjBIczEoivJcdgUK8KYmVValF+fFFpTmp xYcYLYAhNJFZijs5H5ga80rijQ0MUDhK4ryLV2r5CwmkAxNYdmpqQWoRTCsTB6dUA6PbH8sj DIFPNi+SzmA+vzl42QolKd2ll3rbnkjfvRzWkP9RYvcsnfwlXtcZnollfvgoVrY1ur3WVaG/ hSPonovz0u3LvgRe4E5I3deuUcyyk22vRleT7LzEDTfnZm3c6/jvgY1rnN8pneMvHM0/F1aF GnGwin3R/Np/qmfZvE/htxeFJcVxX1RiKc5INNRiLipOBACzArN3WAMAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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, 23 Feb 2012 15:36:09 -0000 Hi So, in deployments where there is a lot of knowledge (e.g. IMS), the P-CSCF= could insert the nonce. Hwoever this seems to conflict with what Hannes wro= te: > there is only one requirement for PSAP callback, namely the ability to dis= tinguish the PSAP callback > (by SIP proxies as well as the SIP UA itself) from a regular call to avoid= having the callback blocked > by user configured authorization policies, or forwarded to an answering ma= chine, etc. If the nonce is inserted by a proxy, can the UA still distinguish the PSAP c= allback from a regular call? Regards, John-Luc -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Thursday, February 23, 2012 8:10 AM To: Brian Rosen; John-Luc Bakker Cc: pkyzivat@alum.mit.edu; ecrit@ietf.org Subject: RE: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning Hi, > To support emergency calls, the UA pretty much has to know it's an emergen= cy call unless the access network and the origination network are the same e= ntity, or have some kind of relationship. > We have a number of tools that make this possible. For example, LoST retu= rns the local dial string(s) for emergency calls in the area where the UA is= located. Phonebcp states the UA queries > its access network for its own location, then uses that to query LoST for= the PSAP URI(s) and local dial string(s). > > In a case where there is a lot of knowledge, a proxy server can add the no= nce and the origination network can also arrange for the Contact to be const= ructed correctly. Correct. 3GPP has a requirement for that, if the proxy server (P-CSCF) deter= mines the call to be an emergency call. Regards, Christer On Feb 23, 2012, at 8:09 AM, John-Luc Bakker wrote: > Hi, > > Was the scenario considered where a UA is unaware it is making an emergenc= y call? For example the user reads the local emergency number (applicable in= that region) (I believe the fire brigade in France can be reached by dialin= g "18") on a sign (then observes an emergency), enters the local number, and= the request with that number is sent by the UA. > > Does the nonce solution recommend a UA to include the nonce in every SIP r= equest on the off change it turns out to be a request for emergency? > > Regards, > > John-Luc > --- > John-Luc Bakker > Standards Manager > Research In Motion Corporation > Mobile +1 (908) 463 7321 > Office +1 (972) 373-1761 > Internal (820) 63761 > E-mail jbakker@rim.com > > Sent from my BlackBerry Torch (9810) > > ----- Original Message ----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, February 21, 2012 09:13 AM > To: Paul Kyzivat ; ecrit@ietf.org > > Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New > Beginning > > > Hi, > >> Ignoring the problem of callback from a PSTN-based psap (which I commente= d on in earlier message), why isn't the following sufficient: >> >> - the caller uses callerprefs to indicate that it doesn't want to >> talk to an automaton. >> >> - the original emergency caller encodes its contact for the emergency >> call with something *it* understands (e.g. a nonce) that it will subseque= ntly treat as granting priority to an incoming call carrying it. >> >> In this way nobody but the calling UA need know the nonce mechanism. >> It need not be standardized. (And it need not be used at all if the calle= r is willing to tolerate some priority spit.) The callerprefs will prevent t= he rest of the infrastructure from diverting the call. This would then be un= derstood to be a mechanism that anybody can use, not just emergency calls. >> >> Of course this would require widespread support for callerprefs. But any= solution here is going to require widespread support of something. > > It is not only the calling UA that needs to know. Intermediaries also need= to identify a callback, in order to give special treatment. > > Regards, > > Christer > > > > > On 2/21/12 8:03 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>> I am NOT talking about replacing GRUU with the feature tag. GRUU is >>> still the preferred way of routing to the UA. >>> >>> I am just saying that a "side effect" of a feature tag based >>> indicator is that it CAN also be used for routing. I am not saying >>> that we shall mandate support of feature tag based routing. The main >>> purpose of the feature tag is still as indicator. >> >> But wouldn't it then be sufficient to have just a SIP header field >> set by the PSAP when it sends the callback that says "callback"? >> >> Anything else would just be replicating existing functionality. >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential inf= ormation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informatio= n. Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immedi= ately reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From pkyzivat@alum.mit.edu Thu Feb 23 09:22:22 2012 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 F037E21F87DD for ; Thu, 23 Feb 2012 09:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yg1f6rK1L82d for ; Thu, 23 Feb 2012 09:22:22 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id C962921F8737 for ; Thu, 23 Feb 2012 09:22:21 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta15.westchester.pa.mail.comcast.net with comcast id dUJ11i0071uE5Es5FVNJqe; Thu, 23 Feb 2012 17:22:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id dVNJ1i00e07duvL3cVNJ5X; Thu, 23 Feb 2012 17:22:18 +0000 Message-ID: <4F4675C8.8060700@alum.mit.edu> Date: Thu, 23 Feb 2012 12:22:16 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Brian Rosen References: <155970D1DA8E174F9E46039E10E2AA350EF737@XMB104ADS.rim.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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, 23 Feb 2012 17:22:23 -0000 On 2/23/12 9:06 AM, Brian Rosen wrote: > To support emergency calls, the UA pretty much has to know it's an emergency call unless the access network and the origination network are the same entity, or have some kind of relationship. We have a number of tools that make this possible. For example, LoST returns the local dial string(s) for emergency calls in the area where the UA is located. Phonebcp states the UA queries its access network for its own location, then uses that to query LoST for the PSAP URI(s) and local dial string(s). > > In a case where there is a lot of knowledge, a proxy server can add the nonce and the origination network can also arrange for the Contact to be constructed correctly. IMS actually does have the UE recognizing local emergency dial strings. It always seemed to me that the "best" way to do this would be for the local server that first recognizes this as an emergency call would do a 3xx to urn:sos... Then the calling device would know that it should treat this as an emergency call. I suppose, in order to cope with devices that wouldn't handle that gracefully, there could be an option that the caller announces support for that would indicate it is ready to do this. Thanks, Paul > Brian > > On Feb 23, 2012, at 8:09 AM, John-Luc Bakker wrote: > >> Hi, >> >> Was the scenario considered where a UA is unaware it is making an emergency call? For example the user reads the local emergency number (applicable in that region) (I believe the fire brigade in France can be reached by dialing "18") on a sign (then observes an emergency), enters the local number, and the request with that number is sent by the UA. >> >> Does the nonce solution recommend a UA to include the nonce in every SIP request on the off change it turns out to be a request for emergency? >> >> Regards, >> >> John-Luc >> --- >> John-Luc Bakker >> Standards Manager >> Research In Motion Corporation >> Mobile +1 (908) 463 7321 >> Office +1 (972) 373-1761 >> Internal (820) 63761 >> E-mail jbakker@rim.com >> >> Sent from my BlackBerry Torch (9810) >> >> ----- Original Message ----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Tuesday, February 21, 2012 09:13 AM >> To: Paul Kyzivat; ecrit@ietf.org >> Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning >> >> >> Hi, >> >>> Ignoring the problem of callback from a PSTN-based psap (which I commented on in earlier message), why isn't the following sufficient: >>> >>> - the caller uses callerprefs to indicate that it doesn't want to >>> talk to an automaton. >>> >>> - the original emergency caller encodes its contact for the emergency call with something *it* understands (e.g. a nonce) that it will subsequently treat as granting priority to an incoming >>> call carrying it. >>> >>> In this way nobody but the calling UA need know the nonce mechanism. It need not be standardized. (And it need not be used at all if the caller is willing to tolerate some priority spit.) The >>> callerprefs will prevent the rest of the infrastructure from diverting the call. This would then be understood to be a mechanism that anybody can use, not just emergency calls. >>> >>> Of course this would require widespread support for callerprefs. But any solution here is going to require widespread support of something. >> >> It is not only the calling UA that needs to know. Intermediaries also need to identify a callback, in order to give special treatment. >> >> Regards, >> >> Christer >> >> >> >> >> On 2/21/12 8:03 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>> I am NOT talking about replacing GRUU with the feature tag. GRUU is >>>> still the preferred way of routing to the UA. >>>> >>>> I am just saying that a "side effect" of a feature tag based >>>> indicator is that it CAN also be used for routing. I am not saying >>>> that we shall mandate support of feature tag based routing. The main >>>> purpose of the feature tag is still as indicator. >>> >>> But wouldn't it then be sufficient to have just a SIP header field set >>> by the PSAP when it sends the callback that says "callback"? >>> >>> Anything else would just be replicating existing functionality. >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From br@brianrosen.net Thu Feb 23 09:50:36 2012 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 9A71121F8734 for ; Thu, 23 Feb 2012 09:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.844 X-Spam-Level: X-Spam-Status: No, score=-102.844 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzacFeiMUxRA for ; Thu, 23 Feb 2012 09:50:35 -0800 (PST) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1E221F872D for ; Thu, 23 Feb 2012 09:50:35 -0800 (PST) X-ASG-Debug-ID: 1330019379-0491e51f01eb7d0001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id jjLmIWUALJqvuWkM; Thu, 23 Feb 2012 09:49:39 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.45]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1S0cnS-001UHk-JQ; Thu, 23 Feb 2012 09:49:38 -0800 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning Content-Type: text/plain; charset=iso-8859-1 From: Brian Rosen In-Reply-To: <4F4675C8.8060700@alum.mit.edu> Date: Thu, 23 Feb 2012 12:49:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <155970D1DA8E174F9E46039E10E2AA350EF737@XMB104ADS.rim.net> <4F4675C8.8060700@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1330019379 X-Barracuda-URL: http://64.34.111.253:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=BSF_SC1_TG070 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.89313 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_SC1_TG070 Custom Rule TG070 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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, 23 Feb 2012 17:50:36 -0000 That's a privacy attack: I want to know your location, so I force you to send an emergency call. = Then I observe it. I actually like it, but it has this problem. Brian On Feb 23, 2012, at 12:22 PM, Paul Kyzivat wrote: > On 2/23/12 9:06 AM, Brian Rosen wrote: >> To support emergency calls, the UA pretty much has to know it's an = emergency call unless the access network and the origination network are = the same entity, or have some kind of relationship. We have a number of = tools that make this possible. For example, LoST returns the local dial = string(s) for emergency calls in the area where the UA is located. = Phonebcp states the UA queries its access network for its own location, = then uses that to query LoST for the PSAP URI(s) and local dial = string(s). >>=20 >> In a case where there is a lot of knowledge, a proxy server can add = the nonce and the origination network can also arrange for the Contact = to be constructed correctly. IMS actually does have the UE recognizing = local emergency dial strings. >=20 > It always seemed to me that the "best" way to do this would be for the = local server that first recognizes this as an emergency call would do a = 3xx to urn:sos... Then the calling device would know that it should = treat this as an emergency call. >=20 > I suppose, in order to cope with devices that wouldn't handle that = gracefully, there could be an option that the caller announces support = for that would indicate it is ready to do this. >=20 > Thanks, > Paul >=20 >> Brian >>=20 >> On Feb 23, 2012, at 8:09 AM, John-Luc Bakker wrote: >>=20 >>> Hi, >>>=20 >>> Was the scenario considered where a UA is unaware it is making an = emergency call? For example the user reads the local emergency number = (applicable in that region) (I believe the fire brigade in France can be = reached by dialing "18") on a sign (then observes an emergency), enters = the local number, and the request with that number is sent by the UA. >>>=20 >>> Does the nonce solution recommend a UA to include the nonce in every = SIP request on the off change it turns out to be a request for = emergency? >>>=20 >>> Regards, >>>=20 >>> John-Luc >>> --- >>> John-Luc Bakker >>> Standards Manager >>> Research In Motion Corporation >>> Mobile +1 (908) 463 7321 >>> Office +1 (972) 373-1761 >>> Internal (820) 63761 >>> E-mail jbakker@rim.com >>>=20 >>> Sent from my BlackBerry Torch (9810) >>>=20 >>> ----- Original Message ----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Tuesday, February 21, 2012 09:13 AM >>> To: Paul Kyzivat; = ecrit@ietf.org >>> Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New = Beginning >>>=20 >>>=20 >>> Hi, >>>=20 >>>> Ignoring the problem of callback from a PSTN-based psap (which I = commented on in earlier message), why isn't the following sufficient: >>>>=20 >>>> - the caller uses callerprefs to indicate that it doesn't want to >>>> talk to an automaton. >>>>=20 >>>> - the original emergency caller encodes its contact for the = emergency call with something *it* understands (e.g. a nonce) that it = will subsequently treat as granting priority to an incoming >>>> call carrying it. >>>>=20 >>>> In this way nobody but the calling UA need know the nonce = mechanism. It need not be standardized. (And it need not be used at all = if the caller is willing to tolerate some priority spit.) The >>>> callerprefs will prevent the rest of the infrastructure from = diverting the call. This would then be understood to be a mechanism that = anybody can use, not just emergency calls. >>>>=20 >>>> Of course this would require widespread support for callerprefs. = But any solution here is going to require widespread support of = something. >>>=20 >>> It is not only the calling UA that needs to know. Intermediaries = also need to identify a callback, in order to give special treatment. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2/21/12 8:03 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>>> I am NOT talking about replacing GRUU with the feature tag. GRUU = is >>>>> still the preferred way of routing to the UA. >>>>>=20 >>>>> I am just saying that a "side effect" of a feature tag based >>>>> indicator is that it CAN also be used for routing. I am not saying >>>>> that we shall mandate support of feature tag based routing. The = main >>>>> purpose of the feature tag is still as indicator. >>>>=20 >>>> But wouldn't it then be sufficient to have just a SIP header field = set >>>> by the PSAP when it sends the callback that says "callback"? >>>>=20 >>>> Anything else would just be replicating existing functionality. >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>> = --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain = confidential information, privileged material (including material = protected by the solicitor-client or other applicable privileges), or = constitute non-public information. Any use of this information by anyone = other than the intended recipient is prohibited. If you have received = this transmission in error, please immediately reply to the sender and = delete this information from your system. Use, dissemination, = distribution, or reproduction of this transmission by unintended = recipients is not authorized and may be unlawful. >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 >=20 From pkyzivat@alum.mit.edu Thu Feb 23 10:07:55 2012 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 4ABB521F87EA for ; Thu, 23 Feb 2012 10:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6nw0VhQY6aB for ; Thu, 23 Feb 2012 10:07:54 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 5459221F87E4 for ; Thu, 23 Feb 2012 10:07:53 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta15.westchester.pa.mail.comcast.net with comcast id dVu71i0020SCNGk5FW7t8j; Thu, 23 Feb 2012 18:07:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta09.westchester.pa.mail.comcast.net with comcast id dW7t1i00j07duvL3VW7ti3; Thu, 23 Feb 2012 18:07:53 +0000 Message-ID: <4F468077.3060600@alum.mit.edu> Date: Thu, 23 Feb 2012 13:07:51 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Brian Rosen References: <155970D1DA8E174F9E46039E10E2AA350EF737@XMB104ADS.rim.net> <4F4675C8.8060700@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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, 23 Feb 2012 18:07:55 -0000 On 2/23/12 12:49 PM, Brian Rosen wrote: > That's a privacy attack: > > I want to know your location, so I force you to send an emergency call. Then I observe it. > > I actually like it, but it has this problem. Well, the calling UA must recognize the URN in the 3xx as an emergency call URN. And then it does call that address, so the attack is only useful to someone that can observer the subsequent call. But it is an attack to that extent. It could be mitigated by the UA querying the user before retrying the call as an emergency call. But I suppose some might consider that too much of a delay. OTOH it would only occur when calling a number the phone doesn't *know* to be an emergency number. There is also the attack of sending a fake configuration to the phone, giving it an emergency dial string that is something the user is likely to call. Thanks, Paul > Brian > > On Feb 23, 2012, at 12:22 PM, Paul Kyzivat wrote: > >> On 2/23/12 9:06 AM, Brian Rosen wrote: >>> To support emergency calls, the UA pretty much has to know it's an emergency call unless the access network and the origination network are the same entity, or have some kind of relationship. We have a number of tools that make this possible. For example, LoST returns the local dial string(s) for emergency calls in the area where the UA is located. Phonebcp states the UA queries its access network for its own location, then uses that to query LoST for the PSAP URI(s) and local dial string(s). >>> >>> In a case where there is a lot of knowledge, a proxy server can add the nonce and the origination network can also arrange for the Contact to be constructed correctly. IMS actually does have the UE recognizing local emergency dial strings. >> >> It always seemed to me that the "best" way to do this would be for the local server that first recognizes this as an emergency call would do a 3xx to urn:sos... Then the calling device would know that it should treat this as an emergency call. >> >> I suppose, in order to cope with devices that wouldn't handle that gracefully, there could be an option that the caller announces support for that would indicate it is ready to do this. >> >> Thanks, >> Paul >> >>> Brian >>> >>> On Feb 23, 2012, at 8:09 AM, John-Luc Bakker wrote: >>> >>>> Hi, >>>> >>>> Was the scenario considered where a UA is unaware it is making an emergency call? For example the user reads the local emergency number (applicable in that region) (I believe the fire brigade in France can be reached by dialing "18") on a sign (then observes an emergency), enters the local number, and the request with that number is sent by the UA. >>>> >>>> Does the nonce solution recommend a UA to include the nonce in every SIP request on the off change it turns out to be a request for emergency? >>>> >>>> Regards, >>>> >>>> John-Luc >>>> --- >>>> John-Luc Bakker >>>> Standards Manager >>>> Research In Motion Corporation >>>> Mobile +1 (908) 463 7321 >>>> Office +1 (972) 373-1761 >>>> Internal (820) 63761 >>>> E-mail jbakker@rim.com >>>> >>>> Sent from my BlackBerry Torch (9810) >>>> >>>> ----- Original Message ----- >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: Tuesday, February 21, 2012 09:13 AM >>>> To: Paul Kyzivat; ecrit@ietf.org >>>> Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning >>>> >>>> >>>> Hi, >>>> >>>>> Ignoring the problem of callback from a PSTN-based psap (which I commented on in earlier message), why isn't the following sufficient: >>>>> >>>>> - the caller uses callerprefs to indicate that it doesn't want to >>>>> talk to an automaton. >>>>> >>>>> - the original emergency caller encodes its contact for the emergency call with something *it* understands (e.g. a nonce) that it will subsequently treat as granting priority to an incoming >>>>> call carrying it. >>>>> >>>>> In this way nobody but the calling UA need know the nonce mechanism. It need not be standardized. (And it need not be used at all if the caller is willing to tolerate some priority spit.) The >>>>> callerprefs will prevent the rest of the infrastructure from diverting the call. This would then be understood to be a mechanism that anybody can use, not just emergency calls. >>>>> >>>>> Of course this would require widespread support for callerprefs. But any solution here is going to require widespread support of something. >>>> >>>> It is not only the calling UA that needs to know. Intermediaries also need to identify a callback, in order to give special treatment. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> On 2/21/12 8:03 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>>>> I am NOT talking about replacing GRUU with the feature tag. GRUU is >>>>>> still the preferred way of routing to the UA. >>>>>> >>>>>> I am just saying that a "side effect" of a feature tag based >>>>>> indicator is that it CAN also be used for routing. I am not saying >>>>>> that we shall mandate support of feature tag based routing. The main >>>>>> purpose of the feature tag is still as indicator. >>>>> >>>>> But wouldn't it then be sufficient to have just a SIP header field set >>>>> by the PSAP when it sends the callback that says "callback"? >>>>> >>>>> Anything else would just be replicating existing functionality. >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >> > > From jbakker@rim.com Wed Feb 29 15:03:21 2012 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 0453721F8631 for ; Wed, 29 Feb 2012 15:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.274 X-Spam-Level: X-Spam-Status: No, score=-4.274 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZY2fXAOr3NpE for ; Wed, 29 Feb 2012 15:03:19 -0800 (PST) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1884A21F8630 for ; Wed, 29 Feb 2012 15:03:18 -0800 (PST) X-AuditID: 0a412830-b7fdb6d00000552a-a5-4f4eacad6805 Received: from XHT105CNC.rim.net (xht105cnc.rim.net [10.65.12.216]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id B2.67.21802.DACAE4F4; Wed, 29 Feb 2012 22:55:09 +0000 (GMT) Received: from XCT103ADS.rim.net (10.67.111.44) by XHT105CNC.rim.net (10.65.12.216) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 29 Feb 2012 17:40:24 -0500 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.01.0339.001; Wed, 29 Feb 2012 16:40:22 -0600 From: John-Luc Bakker To: Paul Kyzivat , Brian Rosen Thread-Topic: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning Thread-Index: AQHM78PyDHznfkKTnk62En7ZjB3JuJZHeJgAgAAYsYCAABfRgIAAALeAgAAIA4CAAASJgIAAASqAgAAjLYCAAAD8gIACnWccgAB0kICAADbGAIAAB6CAgAAFHYCACSKhwA== Date: Wed, 29 Feb 2012 22:40:22 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA350FA4AF@XMB104ADS.rim.net> References: <155970D1DA8E174F9E46039E10E2AA350EF737@XMB104ADS.rim.net> <4F4675C8.8060700@alum.mit.edu> <4F468077.3060600@alum.mit.edu> In-Reply-To: <4F468077.3060600@alum.mit.edu> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.253] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJKsWRmVeSWpSXmKPExsXC5chzQ/fCGj9/gy2f1S2e3p/GZnFh5mFG i8ZFT1ktVmw4wOrA4vH3/Qcmj/vf/rJ7/Pp6lc1jyZKfTAEsUQ2MNol5efkliSWpCimpxcm2 Sj6p6Yk5CgFFmWWJyZUKLpnFyTmJmbmpRUoKmSm2SiZKCgU5icmpual5JbZKiQUFqXkpSnZc ChjABqgsM08hNS85PyUzL91WyTPYX9fCwtRS11DJThcJJPzjzriy5xFTwczQinU3trI3MP51 6WLk5JAQMJFoebeTFcIWk7hwbz1bFyMXh5BAL5PEwl0rmSCcZYwSb1f/hcpsZpT41HOBBaSF TUBdYuuK7cwgtoiAp0TH/xuMIEXMAt2MEpeXnQKbKyzgIXF8+wugbg6wov6/QiA1IgKTGCXW v3kD1swioCrx/sAJMJtXwE3iVus/qNW/gFa/6gTbximgI3F3aRuYzSggK7H77HUmEJtZQFzi 1pP5TBBPCEgs2XOeGcIWlXj5+B/Uc4oSizq/M0LU60gs2P2JDcLWlli28DXUYkGJkzOfgM0X EpCRaG3bxTaBUWIWkhWzkLTPQtI+C0n7AkaWVYyCuRnFBmaGyXnJekWZuXp5qSWbGMFpSMNg B+OEvVqHGAU4GJV4eHcs8fMXYk0sK67MPcQowcGsJML7sRsoxJuSWFmVWpQfX1Sak1p8iNEC GEQTmaW4k/OBKTKvJN7YwACFoyTOu2Sllr+QQDowkWWnphakFsG0MnFwSjUwlj721Pic8qqL 92vAj05joU8iel8/MnLfu7r31Pm0qyVP619LtJ/h9DN8ltVUuPXJbgU/e86UjT+utPzq2bk4 QXJX28VbMX3uDQtuPd22+ajxYZGfM76GrIs699F3/+Y804jqtCu/HPeHcniW1fDISz5bnKtQ IGVtUu6bpqfQe/3T82v8YrHsSizFGYmGWsxFxYkAfKx1BFwDAAA= Cc: Nick Russell , "ecrit@ietf.org" Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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, 29 Feb 2012 23:03:21 -0000 Hi, I have some further questions regarding the nonce approach. In this e-mail I consider two types of emergency calls: UA detected and non-= UA-detected. A succfully completed non-UA-detected emergency call is less li= kely to occur, but can happen. A call back from a PSAP needs to be identified as such in order to allow for= special handling to be applied. If we consider the nonce approach, the UA generating the nonce for a UA dete= cted emergency call can compare the nonce if it gets one back (i.e. if the P= SAP makes a call back and the nonce is included). This assumes the UE has "n= ot forgotten" about the nonce (i.e. the device fell out of the user's hand w= hile making the emergency call, dropping both a battery as well as the emerg= ency call prematurely). In case the UA notices the call back header field/pa= rameter, yet fails to match the nonce, the presence of the call back header= field/parameter will not cause the UA to handle the call different from a n= ormal call. This makes sense as in IMS multiple UAs can share the same public user ident= ity. So, assuming no GRUU was used, a UA having registered the same identity= may receive the emergency call back. This receiving UA didn't make the emer= gency call that triggered the callback so it also fails to match the nonce,= the presence of the call back header field/parameter will not cause the UA= to handle the call different from a normal call. (To prevent the wrong UA f= rom terminating the PSAP call back, a GRUU must be used by the PSAP.) In case a non-UA-detected emergency call was accepted by the PSAP and the PS= AP follows up with a PSAP call back, the PSAP need not have a nonce to inclu= de (unless the PSAP has received a nonce while the original emergency call w= as in progress). At any rate, the PSAP still includes the header/parameter t= o enable special treatment to be applied by intermediaries. Again, the UA (m= aking the non-UA-detected emergency call) may fail the match, yet the presen= ce of the call back header field/parameter will not cause the UA to handle t= he call different from a normal call. The inclusion of the header/parameter parameter already causes special handl= ing by intermediaries, nonce or not. The intermediaries are to "trust" the i= ndication given by the header/parameter. Note that the intermediaries on the= path of the PSAP call back are unlikely be the same intermediaries that wer= e on the path of the original emergency call. An intermediary may restart an= d forget about the nonces. Even if the intermediaries are the same and didn'= t restart, is it likely that intermediaries will store the nonce for compari= son reasons, and how long? This makes me wonder if we really need the nonce. Above is shown that the ab= sence or presence of the nonce may cause a UA that made an emergency call to= fail to recognize the terminating call as an emergency call back from the P= SAP. Furthermore, any intermediaries likely also modify the behavior applied= to the emergency call back without looking at the nonce. The protection against abuse of the mechanism should be at the intermediarie= s (nonce or not). Intermediaries are bound to not like it if the services th= ey provide on behalf of the user are being bypassed. Users also become unhap= py when calls that should have been diverted, aren't, due to malicious prese= nce of the header/parameter. The UA can protect itself by remembering it did make an emergency call, rece= ntly. If the UA has no knowledge of having made an emergency call, it can tr= eat the header/parameter with some skepticism? Kind regards, John-Luc -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Thursday, February 23, 2012 12:08 PM To: Brian Rosen Cc: John-Luc Bakker; christer.holmberg@ericsson.com; ecrit@ietf.org Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning On 2/23/12 12:49 PM, Brian Rosen wrote: > That's a privacy attack: > > I want to know your location, so I force you to send an emergency call. T= hen I observe it. > > I actually like it, but it has this problem. Well, the calling UA must recognize the URN in the 3xx as an emergency call URN. And then it does call that address, so the attack is only useful to someone that can observer the subsequent call. But it is an attack to that extent. It could be mitigated by the UA querying the user before retrying the call as an emergency call. But I suppose some might consider that too much of a delay. OTOH it would only occur when calling a number the phone doesn't *know* to be an emergency number. There is also the attack of sending a fake configuration to the phone, giving it an emergency dial string that is something the user is likely to call. Thanks, Paul > Brian > > On Feb 23, 2012, at 12:22 PM, Paul Kyzivat wrote: > >> On 2/23/12 9:06 AM, Brian Rosen wrote: >>> To support emergency calls, the UA pretty much has to know it's an emerg= ency call unless the access network and the origination network are the same= entity, or have some kind of relationship. We have a number of tools that= make this possible. For example, LoST returns the local dial string(s) for= emergency calls in the area where the UA is located. Phonebcp states the U= A queries its access network for its own location, then uses that to query L= oST for the PSAP URI(s) and local dial string(s). >>> >>> In a case where there is a lot of knowledge, a proxy server can add the= nonce and the origination network can also arrange for the Contact to be co= nstructed correctly. IMS actually does have the UE recognizing local emerge= ncy dial strings. >> >> It always seemed to me that the "best" way to do this would be for the lo= cal server that first recognizes this as an emergency call would do a 3xx to= urn:sos... Then the calling device would know that it should treat this as= an emergency call. >> >> I suppose, in order to cope with devices that wouldn't handle that gracef= ully, there could be an option that the caller announces support for that wo= uld indicate it is ready to do this. >> >> Thanks, >> Paul >> >>> Brian >>> >>> On Feb 23, 2012, at 8:09 AM, John-Luc Bakker wrote: >>> >>>> Hi, >>>> >>>> Was the scenario considered where a UA is unaware it is making an emerg= ency call? For example the user reads the local emergency number (applicable= in that region) (I believe the fire brigade in France can be reached by dia= ling "18") on a sign (then observes an emergency), enters the local number,= and the request with that number is sent by the UA. >>>> >>>> Does the nonce solution recommend a UA to include the nonce in every SI= P request on the off change it turns out to be a request for emergency? >>>> >>>> Regards, >>>> >>>> John-Luc >>>> --- >>>> John-Luc Bakker >>>> Standards Manager >>>> Research In Motion Corporation >>>> Mobile +1 (908) 463 7321 >>>> Office +1 (972) 373-1761 >>>> Internal (820) 63761 >>>> E-mail jbakker@rim.com >>>> >>>> Sent from my BlackBerry Torch (9810) >>>> >>>> ----- Original Message ----- >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: Tuesday, February 21, 2012 09:13 AM >>>> To: Paul Kyzivat; ecrit@ietf.org >>>> Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginnin= g >>>> >>>> >>>> Hi, >>>> >>>>> Ignoring the problem of callback from a PSTN-based psap (which I comme= nted on in earlier message), why isn't the following sufficient: >>>>> >>>>> - the caller uses callerprefs to indicate that it doesn't want to >>>>> talk to an automaton. >>>>> >>>>> - the original emergency caller encodes its contact for the emergency= call with something *it* understands (e.g. a nonce) that it will subsequent= ly treat as granting priority to an incoming >>>>> call carrying it. >>>>> >>>>> In this way nobody but the calling UA need know the nonce mechanism. I= t need not be standardized. (And it need not be used at all if the caller is= willing to tolerate some priority spit.) The >>>>> callerprefs will prevent the rest of the infrastructure from diverting= the call. This would then be understood to be a mechanism that anybody can= use, not just emergency calls. >>>>> >>>>> Of course this would require widespread support for callerprefs. But a= ny solution here is going to require widespread support of something. >>>> >>>> It is not only the calling UA that needs to know. Intermediaries also n= eed to identify a callback, in order to give special treatment. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> On 2/21/12 8:03 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>>>> I am NOT talking about replacing GRUU with the feature tag. GRUU is >>>>>> still the preferred way of routing to the UA. >>>>>> >>>>>> I am just saying that a "side effect" of a feature tag based >>>>>> indicator is that it CAN also be used for routing. I am not saying >>>>>> that we shall mandate support of feature tag based routing. The main >>>>>> purpose of the feature tag is still as indicator. >>>>> >>>>> But wouldn't it then be sufficient to have just a SIP header field set >>>>> by the PSAP when it sends the callback that says "callback"? >>>>> >>>>> Anything else would just be replicating existing functionality. >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential= information, privileged material (including material protected by the solic= itor-client or other applicable privileges), or constitute non-public inform= ation. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please im= mediately reply to the sender and delete this information from your system.= Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >> > > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful.