From fluffy@cisco.com Sun Nov 7 14:51:07 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B53953A690E for ; Sun, 7 Nov 2010 14:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.557 X-Spam-Level: X-Spam-Status: No, score=-110.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfUnq8LOVTQp for ; Sun, 7 Nov 2010 14:51:06 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B625C3A68E4 for ; Sun, 7 Nov 2010 14:51:06 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8QAF+81kyrR7Ht/2dsb2JhbAAcoWlxnjaaW4JyglYEhFiFfYMK X-IronPort-AV: E=Sophos;i="4.58,311,1286150400"; d="scan'208";a="282272885" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2010 22:51:26 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA7MnhEo023912 for ; Sun, 7 Nov 2010 22:51:26 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Nov 2010 15:51:45 -0700 Message-Id: To: ECRIT Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Ecrit] draft-ietf-ecrit-psap-callback X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 22:51:07 -0000 The part of this problem I find particularly interesting about call back = is the authorization. I can't tell if this draft is proposing PAI, = Identity, SAML Traits, or Tokens. I don't really see how any of them = work but it seems like this should be a big topic of discussion if this = draft is going to make any progress.=20 From fluffy@cisco.com Sun Nov 7 14:51:38 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6302628C11D for ; Sun, 7 Nov 2010 14:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.559 X-Spam-Level: X-Spam-Status: No, score=-110.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIpKVy-HZnhE for ; Sun, 7 Nov 2010 14:51:37 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 26BAF28C118 for ; Sun, 7 Nov 2010 14:51:37 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8QAF+81kyrR7Ht/2dsb2JhbAAcoWlxnjaaW4VIBIRYhX2DCg X-IronPort-AV: E=Sophos;i="4.58,311,1286150400"; d="scan'208";a="282272932" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2010 22:51:56 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA7MnhEp023912 for ; Sun, 7 Nov 2010 22:51:56 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Nov 2010 15:52:16 -0700 Message-Id: <33549AB2-0551-41E0-ACD3-FE0EE457A0AF@cisco.com> To: ECRIT Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Ecrit] draft-ietf-ecrit-trustworthy-location and who can sign location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 22:51:38 -0000 Enterprises could operate a LIS for wireline phones or wifi phones in = the enterprise - would they be able to get a cert rooted in VESA to sign = location? From fluffy@cisco.com Sun Nov 7 14:51:49 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C54728C118 for ; Sun, 7 Nov 2010 14:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.561 X-Spam-Level: X-Spam-Status: No, score=-110.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXn0iCBLftIQ for ; Sun, 7 Nov 2010 14:51:48 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0D05028C0D7 for ; Sun, 7 Nov 2010 14:51:48 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF+81kyrR7Ht/2dsb2JhbACiBXGeNppbhUgEhFiFfYMK X-IronPort-AV: E=Sophos;i="4.58,311,1286150400"; d="scan'208";a="213272710" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 07 Nov 2010 22:52:07 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA7MnhEq023912 for ; Sun, 7 Nov 2010 22:52:07 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Nov 2010 15:52:27 -0700 Message-Id: <8C2A715A-2F04-445E-B511-392F434F515F@cisco.com> To: ECRIT Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Ecrit] draft-ietf-ecrit-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 22:51:49 -0000 I wonder about how one would authenticate all this data - I'm less = worried about information that a human operator decide to apply = judgement to but I'm worried about data that causes automated policy to = happen. For example, if a thief knows that if my alarm system calls the = the center 10 times in a row in a bogus way, it will get blocked on = future calls, what stops the thief from impersonating however my alarm = system identifies itself, makes the calls, and thus rendering the alarm = system blocked.=20 A few small comments about some of the data inside ... Overall, it seems like a grab bag of everything we could find vs what = would be truly useful in anon trivial number of corner cases.=20 Section 3.7 - these categories seem overlapping and confused in that = they measure different things. For example. Something could be both a = prison phone and a POTS.=20 I think it would be much better to focus on what the relevant attributes = for the PSAP are and then have individual capabilities. I can see it is = useful to know if this is two way voice or not. I can see it would = useful to know if the phone has a high risk of prank calls or not based = on it's the level of public accessibility. I'm having a harder time = seeing the need to know if a phone is multiline or not. My cell phone = does two calls at once, is it multiline?=20 Similarly with table 3.8 - focus on the attributes that are important to = the PSAP. I can't even imagine which of these categories an iphone would = fall into. It's funny, the text you have in your "reason for need" look = Luke fine attributes but don't map to the table in the slightest.=20 I'm pretty skeptical that this is the right place to transfer all the = unique device identifiers. It seems like theses would better be handled = in other places.=20 3.14 - Isn't call-id on the PSTN today all the proof you need that this = is an awful design for restricting call-id. "Here is the secret data but = please don't look at it"=20 And uh, about that security section..... I have full confidence that the = authors can easily make substantial improvements to that section :-) From fluffy@cisco.com Sun Nov 7 14:51:52 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC8428C120 for ; Sun, 7 Nov 2010 14:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.563 X-Spam-Level: X-Spam-Status: No, score=-110.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAMs5irmzS6V for ; Sun, 7 Nov 2010 14:51:51 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8E41D28C11F for ; Sun, 7 Nov 2010 14:51:51 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF+81kyrR7Ht/2dsb2JhbACiBXGeNppbhUgEhFiFfYMK X-IronPort-AV: E=Sophos;i="4.58,311,1286150400"; d="scan'208";a="213272719" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 07 Nov 2010 22:52:11 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA7MnhEr023912 for ; Sun, 7 Nov 2010 22:52:11 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Nov 2010 15:52:30 -0700 Message-Id: <2D03AE89-9AA0-43D1-8B66-83061E7BA481@cisco.com> To: ECRIT Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Ecrit] draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 22:51:52 -0000 Would these CAP messages be sent to a PSAP? If not I sort of wonder how this is ECRIT and wonder if it would be = better to move this over to ATOCA.=20 From dworley@avaya.com Mon Nov 1 10:18:23 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CC1628C0E0 for ; Mon, 1 Nov 2010 10:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.787 X-Spam-Level: X-Spam-Status: No, score=-100.787 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIQEfAryx4jW for ; Mon, 1 Nov 2010 10:18:23 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 8285C28B23E for ; Mon, 1 Nov 2010 10:18:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGKTzkyHCzI1/2dsb2JhbAChWnGlDQKaAYVFBI11 X-IronPort-AV: E=Sophos;i="4.58,274,1286164800"; d="scan'208";a="247895756" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 Nov 2010 13:18:23 -0400 X-IronPort-AV: E=Sophos;i="4.58,274,1286164800"; d="scan'208";a="532297238" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 Nov 2010 13:18:23 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 1 Nov 2010 13:18:23 -0400 From: "Worley, Dale R (Dale)" To: Robert Sparks , "ecrit@ietf.org" Date: Mon, 1 Nov 2010 13:17:02 -0400 Thread-Topic: Errata reports for errata 1259, 1260, and 1263 for RFC 5012 "Requirements for Emergency Context Resolution" Thread-Index: AQHLeejJdbwlqB73rE+I8t3/tK68jg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 07 Nov 2010 15:13:36 -0800 Subject: [Ecrit] Errata reports for errata 1259, 1260, and 1263 for RFC 5012 "Requirements for Emergency Context Resolution" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 17:18:23 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC5012, "Requirements for Emergency Context Resolution with Internet Technologies" Source of RFC: ecrit (rai) Errata ID: 1259 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2008-01-13 Section 8, pg.19 says: Ma14. Resilience to mapping server failure: The mapping protocol MUST support a mechanism that enables the client to fail over to different (replica) mapping server. It should say: Ma14. Resilience to mapping server failure: The mapping protocol | MUST support a mechanism that enables the client to fail over to a different (replica) mapping server. Notes: insert missing "a" ---------------------------------------------------------------------- Recommended status: (correct) Hold for document update =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC5012, "Requirements for Emergency Context Resolution with Internet Technologies" Source of RFC: ecrit (rai) Errata ID: 1260 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2008-01-13 Report Text: double replication : ability to <-> to be able to :-) ---------------------------------------------------------------------- Erratum 1260 is a truncated version of erratum 1263. This erratum should be deleted, or set to refer to erratum 1263. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC5012, "Requirements for Emergency Context Resolution with Internet Technologies" Source of RFC: ecrit (rai) Errata ID: 1263 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2008-01-13 Section 8 (p.19) says: Ma15. Traceable resolution: The mapping protocol SHOULD support the | ability of the mapping client to be able to determine the entity or entities that provided the emergency address resolution information. It should say: Ma15. Traceable resolution: The mapping protocol SHOULD support the | ability of the mapping client to determine the entity or entities that provided the emergency address resolution information. Notes: "double replication": ability to <-> to be able to :-) Note: The previous entry of this same Errata Entry has been truncated inadvertently -- please remove it. ---------------------------------------------------------------------- Recommended status: (correct) Hold for document update =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dale From trac@tools.ietf.org Sun Nov 7 12:39:49 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CE7F3A68B2 for ; Sun, 7 Nov 2010 12:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqeNMOAv32hs for ; Sun, 7 Nov 2010 12:39:30 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AC7713A68C1 for ; Sun, 7 Nov 2010 12:39:16 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PFC0n-0004EG-UL; Sun, 07 Nov 2010 12:38:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ecrit issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: Bernard_Aboba@hotmail.com X-Trac-Project: ecrit Date: Sun, 07 Nov 2010 20:38:49 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/1 Message-ID: <065.d0d0f1d0bb2875663c42cb464986f6a8@tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: Bernard_Aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sun, 07 Nov 2010 15:13:36 -0800 Cc: ecrit@ietf.org Subject: [Ecrit] [ecrit] trustworthy-location #1 (new): Threat Analysis: Missing Context X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 20:39:49 -0000 #1: Threat Analysis: Missing Context Section 4 describes threats, but does not reference previous threat model documents created within the ECRIT and GEOPRIV WGs. The reader is therefore left without an explanation of how the threat analysis in this document differs from previous ones, or what the focus is. To provide context, addition of the following text is suggested: " IP-based emergency services face many security threats. "Security Threats and Requirements for Emergency Call Marking and Mapping" [RFC5069] describes attacks on the emergency services system, such as attempting to deny system services to all users in a given area, to gain fraudulent use of services and to divert emergency calls to non- emergency sites. [RFC5069] also describes attacks against individuals, including attempts to prevent an individual from receiving aid, or to gain information about an emergency. "Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats against geographic location privacy, including protocol threats, threats resulting from the storage of geographic location data, and threats posed by the abuse of information. This document focuses on threats deriving from the introduction of untrustworthy location information by end hosts, regardless of whether this occurs intentionally or unintentionally." -- ---------------------------------------+------------------------------------ Reporter: Bernard_Aboba@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: ecrit From trac@tools.ietf.org Sun Nov 7 12:46:41 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AEC13A68BF for ; Sun, 7 Nov 2010 12:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFYbQr9v99Fi for ; Sun, 7 Nov 2010 12:46:40 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AFE823A68B1 for ; Sun, 7 Nov 2010 12:46:40 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PFC8i-0006in-19; Sun, 07 Nov 2010 12:47:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ecrit issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: Bernard_Aboba@hotmail.com X-Trac-Project: ecrit Date: Sun, 07 Nov 2010 20:46:59 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/2 Message-ID: <065.6a5cb9a88adb7aeeff739133ff1b2a3b@tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: Bernard_Aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sun, 07 Nov 2010 15:13:36 -0800 Cc: ecrit@ietf.org Subject: [Ecrit] [ecrit] trustworthy-location #2 (new): Trustworthy Location, Identity and Accountability X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 20:46:41 -0000 #2: Trustworthy Location, Identity and Accountability In a number of places, it is asserted that "trustworthy location information is more important than identity". For example, Section 1 states: " Much of the focus in trustable networks has been on ensuring the reliability of personal identity information or verifying privileges. However, in some cases, access to trustworthy location information is more important than identity since some services are meant to be widely available, regardless of the identity of the requestor." More explanation is needed, because experience has shown that lack of accountability can lead to an increase in prank calls. It is suggested that the following text be added to Section 1: In situations where it is possible to place emergency calls without accountability, experience has shown that the frequency of nuisance calls can rise dramatically. For example, where emergency calls have been allowed from handsets lacking a SIM card, or where ownership of the SIM card cannot be determined, the frequency of nuisance calls has often been unacceptably high [TASMANIA][UK][SA]. -- ---------------------------------------+------------------------------------ Reporter: Bernard_Aboba@… | Owner: Type: defect | Status: new Priority: blocker | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: ecrit From bernard_aboba@hotmail.com Sun Nov 7 16:20:45 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34D143A67D6 for ; Sun, 7 Nov 2010 16:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.381 X-Spam-Level: X-Spam-Status: No, score=-102.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRlADyHjEC8s for ; Sun, 7 Nov 2010 16:20:44 -0800 (PST) Received: from blu0-omc4-s22.blu0.hotmail.com (blu0-omc4-s22.blu0.hotmail.com [65.55.111.161]) by core3.amsl.com (Postfix) with ESMTP id 2490F3A67B3 for ; Sun, 7 Nov 2010 16:20:44 -0800 (PST) Received: from BLU104-W24 ([65.55.111.135]) by blu0-omc4-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 7 Nov 2010 16:21:03 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_13c7c3a9-c580-433e-981d-3cf15826196c_" X-Originating-IP: [24.19.29.20] From: Bernard Aboba To: , Date: Sun, 7 Nov 2010 16:21:03 -0800 Importance: Normal In-Reply-To: <33549AB2-0551-41E0-ACD3-FE0EE457A0AF@cisco.com> References: <33549AB2-0551-41E0-ACD3-FE0EE457A0AF@cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 08 Nov 2010 00:21:03.0519 (UTC) FILETIME=[D403F2F0:01CB7EDA] Subject: Re: [Ecrit] draft-ietf-ecrit-trustworthy-location and who can sign location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 00:20:45 -0000 --_13c7c3a9-c580-433e-981d-3cf15826196c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The statements in NENA i2 would seem to imply that any LIS would be able to= obtain a certificate chaining to a VESA trust anchor=2C to enable signing = of location.=20 However=2C I am not aware of a document that provides details of the certi= ficates=2C hierarchy=2C issuance policies=2C revocation=2C etc. so as to al= low this to become operational (e.g. by sub-contracting to a vendor with ex= perience in this area).=20 > From: fluffy@cisco.com > Date: Sun=2C 7 Nov 2010 15:52:16 -0700 > To: ecrit@ietf.org > Subject: [Ecrit] draft-ietf-ecrit-trustworthy-location and who can sign l= ocation >=20 >=20 > Enterprises could operate a LIS for wireline phones or wifi phones in the= enterprise - would they be able to get a cert rooted in VESA to sign locat= ion? >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = --_13c7c3a9-c580-433e-981d-3cf15826196c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The statements in NENA i2 would seem to imply that any LIS would be able to= obtain a certificate chaining to a VESA trust anchor=2C to enable signing = of location.

However=2C =3B I am not aware of a document that p= rovides details of the certificates=2C hierarchy=2C issuance policies=2C re= vocation=2C etc. so as to allow this to become operational (e.g. by sub-con= tracting to a vendor with experience in this area).

>=3B From: fl= uffy@cisco.com
>=3B Date: Sun=2C 7 Nov 2010 15:52:16 -0700
>=3B T= o: ecrit@ietf.org
>=3B Subject: [Ecrit] draft-ietf-ecrit-trustworthy-l= ocation and who can sign location
>=3B
>=3B
>=3B Enterpris= es could operate a LIS for wireline phones or wifi phones in the enterprise= - would they be able to get a cert rooted in VESA to sign location?
>= =3B
>=3B
>=3B
>=3B ______________________________________= _________
>=3B Ecrit mailing list
>=3B Ecrit@ietf.org
>=3B h= ttps://www.ietf.org/mailman/listinfo/ecrit
= --_13c7c3a9-c580-433e-981d-3cf15826196c_-- From hannes.tschofenig@gmx.net Sun Nov 7 16:34:50 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C16B63A67A1 for ; Sun, 7 Nov 2010 16:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5fuxnA5J2JZ for ; Sun, 7 Nov 2010 16:34:50 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 6AA8A3A677C for ; Sun, 7 Nov 2010 16:34:48 -0800 (PST) Received: (qmail invoked by alias); 08 Nov 2010 00:35:07 -0000 Received: from dhcp-7730.meeting.ietf.org (EHLO dhcp-7730.meeting.ietf.org) [130.129.119.48] by mail.gmx.net (mp005) with SMTP; 08 Nov 2010 01:35:07 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+8wpkIFsm8nq+tsLlfy6sLk/jGkdzpSyoLC7aI3e aKarW0/fiOqw2j Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Mon, 8 Nov 2010 01:35:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7656EDAE-2E37-4D0C-A7AB-2071D2998458@gmx.net> References: To: Cullen Jennings X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig , ECRIT Subject: Re: [Ecrit] draft-ietf-ecrit-psap-callback X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 00:34:50 -0000 Hi Cullen,=20 sorry if the draft did not make the approach clear.=20 It decouples three elements:=20 a) marking=20 b) authentication and identity handling=20 c) authorization For (a) a scheme is described in the document. There is a bug in there = but I will fix it with a draft update today.=20 For (b) we suggest to re-use PAI and SIP Identity For (c) the draft discusses two possible approaches, namely to use the = authenticated identity for authorization or a trait. On the latter = aspect, the draft does not define a solution using SIP SAML at the = moment.=20 Ciao Hannes On Nov 7, 2010, at 11:51 PM, Cullen Jennings wrote: >=20 > The part of this problem I find particularly interesting about call = back is the authorization. I can't tell if this draft is proposing PAI, = Identity, SAML Traits, or Tokens. I don't really see how any of them = work but it seems like this should be a big topic of discussion if this = draft is going to make any progress.=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Sun Nov 7 18:11:57 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C8B3A693B for ; Sun, 7 Nov 2010 18:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+aOl7V2KdIC for ; Sun, 7 Nov 2010 18:11:52 -0800 (PST) Received: from barmail2.idig.net (barmail2.idig.net [64.34.111.252]) by core3.amsl.com (Postfix) with ESMTP id 168CA3A6940 for ; Sun, 7 Nov 2010 18:11:46 -0800 (PST) X-ASG-Debug-ID: 1289182321-2cac28020001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail2.idig.net with ESMTP id 1scjuHw4R0ACXSBo; Sun, 07 Nov 2010 18:12:01 -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.40]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PFHDC-0003H0-5O; Sun, 07 Nov 2010 18:12:02 -0800 Mime-Version: 1.0 (Apple Message framework v1081) X-ASG-Orig-Subj: Re: [Ecrit] draft-ietf-ecrit-additional-data Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <8C2A715A-2F04-445E-B511-392F434F515F@cisco.com> Date: Sun, 7 Nov 2010 21:11:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4163F28B-4861-4E94-9751-099AE3AE3DAC@brianrosen.net> References: <8C2A715A-2F04-445E-B511-392F434F515F@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1081) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1289182321 X-Barracuda-URL: http://64.34.111.252:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net 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.45993 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: ECRIT Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 02:11:58 -0000 Thanks for looking at this. See inline for some of my responses On Nov 7, 2010, at 5:52 PM, Cullen Jennings wrote: >=20 > I wonder about how one would authenticate all this data - I'm less = worried about information that a human operator decide to apply = judgement to but I'm worried about data that causes automated policy to = happen. For example, if a thief knows that if my alarm system calls the = the center 10 times in a row in a bogus way, it will get blocked on = future calls, what stops the thief from impersonating however my alarm = system identifies itself, makes the calls, and thus rendering the alarm = system blocked.=20 Generally, the more common service providers will have credentials that = would allow the PSAP to have some confidence that they know whom they = are talking to, but generally, this is considered untrustworthly = information. >=20 > A few small comments about some of the data inside ... >=20 > Overall, it seems like a grab bag of everything we could find vs what = would be truly useful in anon trivial number of corner cases.=20 Actually, nearly all of it has a direct analog in the current U.S. = system. They don't get all of it all the time, and the form of the data = is very different, but the way these items were constructed was looking = at the current system and asking "what is the equivalent in the IP = world?". That isn't entirely true (device characteristics for example). >=20 > Section 3.7 - these categories seem overlapping and confused in that = they measure different things. For example. Something could be both a = prison phone and a POTS.=20 We tried pretty hard to figure out what would be useful. We know that = there will be overlaps, and new services. It's useful to know this kind = of data, and perhaps some advice would be useful. In your example, we = would want to know it's a prison phone much more than POTS. >=20 > I think it would be much better to focus on what the relevant = attributes for the PSAP are and then have individual capabilities. I can = see it is useful to know if this is two way voice or not. I can see it = would useful to know if the phone has a high risk of prank calls or not = based on it's the level of public accessibility. I'm having a harder = time seeing the need to know if a phone is multiline or not. My cell = phone does two calls at once, is it multiline?=20 I think yes. Multiline tells us the phone could go on hold. If yours = can, then we probably want to know. Attributes may be a good idea. A list of attributes where you can send = a set. I'll work on that and see where it gets us. >=20 > Similarly with table 3.8 - focus on the attributes that are important = to the PSAP. I can't even imagine which of these categories an iphone = would fall into. It's funny, the text you have in your "reason for need" = look Luke fine attributes but don't map to the table in the slightest.=20= Yeah, the reason for need doesn't work right here. See above on = attributes. >=20 > I'm pretty skeptical that this is the right place to transfer all the = unique device identifiers. It seems like theses would better be handled = in other places.=20 Maybe, but suggest a better place. The point was that all the info a = device or service provider knows that is not in the signaling goes in = this one place. >=20 > 3.14 - Isn't call-id on the PSTN today all the proof you need that = this is an awful design for restricting call-id. "Here is the secret = data but please don't look at it"=20 We get this now. It's mostly for downstream systems; the emergency = services don't restrict anything, at least in the U.S.=20 >=20 > And uh, about that security section..... I have full confidence that = the authors can easily make substantial improvements to that section :-) Uh, yeah, we can do that. >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Internet-Drafts@ietf.org Sun Nov 7 21:00:11 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1C728C10D; Sun, 7 Nov 2010 21:00:10 -0800 (PST) X-Quarantine-ID: <2JdlKX7Rmgdv> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: unexpected end of preamble X-Spam-Flag: NO X-Spam-Score: -99.298 X-Spam-Level: X-Spam-Status: No, score=-99.298 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, MISSING_MIME_HB_SEP=2.119, SARE_BOUNDARY_LC=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JdlKX7Rmgdv; Sun, 7 Nov 2010 21:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5068828C0E4; Sun, 7 Nov 2010 21:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextpart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no Message-ID: <20101108050002.12708.28362.idtracker@localhost> Date: Sun, 07 Nov 2010 21:00:02 -0800 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-psap-callback-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 05:00:11 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Public Safety Answering Point (PSAP) Callbacks Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-ecrit-psap-callback-02.txt Pages : 19 Date : 2010-11-07 After an emergency call is completed (either prematurely terminated by the emergency caller or normally by the call-taker) it is possible that the call-taker feels the need for further communication or for a clarification. For example, the call may have been dropped by accident without the call-taker having sufficient information about the current situation of a wounded person. A call-taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, then be treated like any other call and as a consequence, it may get blocked by authorization policies or may get forwarded to an answering machine. The IETF emergency services architecture addresses callbacks in a limited fashion and thereby covers a couple of scenarios. This document discusses some shortcomings and illustrates an extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-psap-callback-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-psap-callback-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-07205225.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Nov 8 18:15:39 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0907F28C177; Mon, 8 Nov 2010 18:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.436 X-Spam-Level: X-Spam-Status: No, score=-101.436 tagged_above=-999 required=5 tests=[AWL=1.163, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47i7wEIz5BRw; Mon, 8 Nov 2010 18:15:37 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B6328C179; Mon, 8 Nov 2010 18:15:24 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no Message-ID: <20101109021524.26008.2694.idtracker@localhost> Date: Mon, 08 Nov 2010 18:15:24 -0800 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-psap-callback-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 02:15:39 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Public Safety Answering Point (PSAP) Callbacks Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-ecrit-psap-callback-02.txt Pages : 19 Date : 2010-11-07 After an emergency call is completed (either prematurely terminated by the emergency caller or normally by the call-taker) it is possible that the call-taker feels the need for further communication or for a clarification. For example, the call may have been dropped by accident without the call-taker having sufficient information about the current situation of a wounded person. A call-taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, then be treated like any other call and as a consequence, it may get blocked by authorization policies or may get forwarded to an answering machine. The IETF emergency services architecture addresses callbacks in a limited fashion and thereby covers a couple of scenarios. This document discusses some shortcomings and illustrates an extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-psap-callback-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-psap-callback-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-07205225.I-D@ietf.org> --NextPart-- From fluffy@cisco.com Tue Nov 9 01:22:31 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3250E3A68FB for ; Tue, 9 Nov 2010 01:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.572 X-Spam-Level: X-Spam-Status: No, score=-110.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvtiWuNvQ3+8 for ; Tue, 9 Nov 2010 01:22:28 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 548793A68F3 for ; Tue, 9 Nov 2010 01:22:28 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIeh2EyrRN+J/2dsb2JhbACiHnGiA5tnhUoEhFiFfYMM X-IronPort-AV: E=Sophos;i="4.59,174,1288569600"; d="scan'208";a="283057985" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 09 Nov 2010 09:22:43 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id oA99MgbY023128; Tue, 9 Nov 2010 09:22:43 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Tue, 9 Nov 2010 02:23:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4DB6C5B1-73E5-4507-97D6-9CCC7CD06279@cisco.com> References: <33549AB2-0551-41E0-ACD3-FE0EE457A0AF@cisco.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1081) Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-trustworthy-location and who can sign location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 09:22:31 -0000 The reason I asked is because it seem like if the CA will give certs to = pretty much anyone, then this security approach does not work, and if = the certs are not easy for an enterprise to get then the approach also = won't work because it won't be used. I understand this is a bit outside = of ECRIT work but seems like a tricky line to thread.=20 On Nov 7, 2010, at 5:21 PM, Bernard Aboba wrote: > The statements in NENA i2 would seem to imply that any LIS would be = able to obtain a certificate chaining to a VESA trust anchor, to enable = signing of location.=20 >=20 > However, I am not aware of a document that provides details of the = certificates, hierarchy, issuance policies, revocation, etc. so as to = allow this to become operational (e.g. by sub-contracting to a vendor = with experience in this area).=20 >=20 > > From: fluffy@cisco.com > > Date: Sun, 7 Nov 2010 15:52:16 -0700 > > To: ecrit@ietf.org > > Subject: [Ecrit] draft-ietf-ecrit-trustworthy-location and who can = sign location > >=20 > >=20 > > Enterprises could operate a LIS for wireline phones or wifi phones = in the enterprise - would they be able to get a cert rooted in VESA to = sign location? > >=20 > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Tue Nov 9 06:51:10 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821FA3A69BE for ; Tue, 9 Nov 2010 06:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sxm8cYmbH0A for ; Tue, 9 Nov 2010 06:51:09 -0800 (PST) Received: from barmail2.idig.net (barmail2.idig.net [64.34.111.252]) by core3.amsl.com (Postfix) with ESMTP id 0B3993A681F for ; Tue, 9 Nov 2010 06:51:09 -0800 (PST) X-ASG-Debug-ID: 1289314291-2cc6f3870001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail2.idig.net with ESMTP id 9U5oQrWe0UrOsrGA; Tue, 09 Nov 2010 06:51:31 -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.40]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PFpXl-0007ca-Ju; Tue, 09 Nov 2010 06:51:31 -0800 Mime-Version: 1.0 (Apple Message framework v1081) X-ASG-Orig-Subj: Re: [Ecrit] draft-ietf-ecrit-trustworthy-location and who can sign location Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <4DB6C5B1-73E5-4507-97D6-9CCC7CD06279@cisco.com> Date: Tue, 9 Nov 2010 09:51:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <86555FCC-212D-4574-A343-B9957B114EE8@brianrosen.net> References: <33549AB2-0551-41E0-ACD3-FE0EE457A0AF@cisco.com> <4DB6C5B1-73E5-4507-97D6-9CCC7CD06279@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1081) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1289314291 X-Barracuda-URL: http://64.34.111.252:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net 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.46139 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-trustworthy-location and who can sign location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 14:51:10 -0000 It's conceivable that this could be made to work, only because it's = possible that the local PSAP would have knowledge of local enterprises = and could vouch for the authenticity of the enterprise. Mechanizing = this might be difficult however. I've long thought that we should have more extensive testing mechanisms. = At least in the U.S., every substantial enterprise is visited regularly = by a fire marshal. If the fire marshal could easily place a test call = that verified all the bits were working, that would help a lot. We do = have a big part of that in the -phonebcp spec. The test call could = validate the credential of the enterprise if we could reasonably = validate that it was the fire marshal placing the test call. Brian On Nov 9, 2010, at 4:23 AM, Cullen Jennings wrote: >=20 > The reason I asked is because it seem like if the CA will give certs = to pretty much anyone, then this security approach does not work, and if = the certs are not easy for an enterprise to get then the approach also = won't work because it won't be used. I understand this is a bit outside = of ECRIT work but seems like a tricky line to thread.=20 >=20 >=20 >=20 > On Nov 7, 2010, at 5:21 PM, Bernard Aboba wrote: >=20 >> The statements in NENA i2 would seem to imply that any LIS would be = able to obtain a certificate chaining to a VESA trust anchor, to enable = signing of location.=20 >>=20 >> However, I am not aware of a document that provides details of the = certificates, hierarchy, issuance policies, revocation, etc. so as to = allow this to become operational (e.g. by sub-contracting to a vendor = with experience in this area).=20 >>=20 >>> From: fluffy@cisco.com >>> Date: Sun, 7 Nov 2010 15:52:16 -0700 >>> To: ecrit@ietf.org >>> Subject: [Ecrit] draft-ietf-ecrit-trustworthy-location and who can = sign location >>>=20 >>>=20 >>> Enterprises could operate a LIS for wireline phones or wifi phones = in the enterprise - would they be able to get a cert rooted in VESA to = sign location? >>>=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 bernard_aboba@hotmail.com Tue Nov 9 12:29:34 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F853A68AB for ; Tue, 9 Nov 2010 12:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.151 X-Spam-Level: X-Spam-Status: No, score=-102.151 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZhWbmeuZ3Ah for ; Tue, 9 Nov 2010 12:29:33 -0800 (PST) Received: from blu0-omc2-s7.blu0.hotmail.com (blu0-omc2-s7.blu0.hotmail.com [65.55.111.82]) by core3.amsl.com (Postfix) with ESMTP id 508453A6879 for ; Tue, 9 Nov 2010 12:29:33 -0800 (PST) Received: from BLU104-W26 ([65.55.111.73]) by blu0-omc2-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Nov 2010 12:29:57 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_7ae8d3fa-bf2d-4e1a-b1ad-38a9e24abc7e_" X-Originating-IP: [24.19.29.20] From: Bernard Aboba To: , Date: Tue, 9 Nov 2010 12:29:57 -0800 Importance: Normal In-Reply-To: <86555FCC-212D-4574-A343-B9957B114EE8@brianrosen.net> References: <33549AB2-0551-41E0-ACD3-FE0EE457A0AF@cisco.com> <4DB6C5B1-73E5-4507-97D6-9CCC7CD06279@cisco.com>, <86555FCC-212D-4574-A343-B9957B114EE8@brianrosen.net> MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2010 20:29:57.0827 (UTC) FILETIME=[E03EC130:01CB804C] Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-trustworthy-location and who can sign location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 20:29:35 -0000 --_7ae8d3fa-bf2d-4e1a-b1ad-38a9e24abc7e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The issuance policy for the LIS certificate would need to be ironed out to = understand how this could work. this would be part of a suite of documents = describing the operation of the Certificate Authority. As Brian notes=2C l= everaging the fire marshall visit or related building documents could decre= ase or perhaps eliminate the need for an in-person visit. However=2C typic= al verification operations of a public CA would be likely to apply here=2C = in addition to any special requirements for LIS certificate issuance=2C so = that the operation is likely to be non-trivial in terms of cost.=20 In practice=2C this policy is part of a document set that defines the ope= ration of the Certificate Authority. =20 > Subject: Re: [Ecrit] draft-ietf-ecrit-trustworthy-location and who can si= gn location > From: br@brianrosen.net > Date: Tue=2C 9 Nov 2010 09:51:24 -0500 > CC: bernard_aboba@hotmail.com=3B ecrit@ietf.org > To: fluffy@cisco.com >=20 > It's conceivable that this could be made to work=2C only because it's pos= sible that the local PSAP would have knowledge of local enterprises and cou= ld vouch for the authenticity of the enterprise. Mechanizing this might be= difficult however. >=20 > I've long thought that we should have more extensive testing mechanisms. = At least in the U.S.=2C every substantial enterprise is visited regularly = by a fire marshal. If the fire marshal could easily place a test call that= verified all the bits were working=2C that would help a lot. We do have a= big part of that in the -phonebcp spec. The test call could validate the = credential of the enterprise if we could reasonably validate that it was th= e fire marshal placing the test call. >=20 > Brian >=20 >=20 >=20 >=20 > On Nov 9=2C 2010=2C at 4:23 AM=2C Cullen Jennings wrote: >=20 > >=20 > > The reason I asked is because it seem like if the CA will give certs to= pretty much anyone=2C then this security approach does not work=2C and if = the certs are not easy for an enterprise to get then the approach also won'= t work because it won't be used. I understand this is a bit outside of ECRI= T work but seems like a tricky line to thread.=20 > >=20 > >=20 > >=20 > > On Nov 7=2C 2010=2C at 5:21 PM=2C Bernard Aboba wrote: > >=20 > >> The statements in NENA i2 would seem to imply that any LIS would be ab= le to obtain a certificate chaining to a VESA trust anchor=2C to enable sig= ning of location.=20 > >>=20 > >> However=2C I am not aware of a document that provides details of the = certificates=2C hierarchy=2C issuance policies=2C revocation=2C etc. so as = to allow this to become operational (e.g. by sub-contracting to a vendor wi= th experience in this area).=20 > >>=20 > >>> From: fluffy@cisco.com > >>> Date: Sun=2C 7 Nov 2010 15:52:16 -0700 > >>> To: ecrit@ietf.org > >>> Subject: [Ecrit] draft-ietf-ecrit-trustworthy-location and who can si= gn location > >>>=20 > >>>=20 > >>> Enterprises could operate a LIS for wireline phones or wifi phones in= the enterprise - would they be able to get a cert rooted in VESA to sign l= ocation? > >>>=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 >=20 = --_7ae8d3fa-bf2d-4e1a-b1ad-38a9e24abc7e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The issuance policy for the LIS certificate would need to be ironed out to = understand how this could work. this would be part of a suite of documents = describing the operation of the Certificate Authority. As Brian notes=2C l= everaging the fire marshall visit or related building documents could decre= ase or perhaps eliminate the need for an in-person visit. =3B However= =2C typical verification operations of a public CA would be likely to apply= here=2C in addition to any special requirements for LIS certificate issuan= ce=2C so that the operation is likely to be non-trivial in terms of cost. <= br>

 =3B In practice=2C this policy is part of a document set th= at defines the operation of the Certificate Authority. =3B

>= =3B Subject: Re: [Ecrit] draft-ietf-ecrit-trustworthy-location and who can = sign location
>=3B From: br@brianrosen.net
>=3B Date: Tue=2C 9 No= v 2010 09:51:24 -0500
>=3B CC: bernard_aboba@hotmail.com=3B ecrit@ietf= .org
>=3B To: fluffy@cisco.com
>=3B
>=3B It's conceivable t= hat this could be made to work=2C only because it's possible that the local= PSAP would have knowledge of local enterprises and could vouch for the aut= henticity of the enterprise. Mechanizing this might be difficult however.<= br>>=3B
>=3B I've long thought that we should have more extensive t= esting mechanisms. At least in the U.S.=2C every substantial enterprise is= visited regularly by a fire marshal. If the fire marshal could easily pla= ce a test call that verified all the bits were working=2C that would help a= lot. We do have a big part of that in the -phonebcp spec. The test call = could validate the credential of the enterprise if we could reasonably vali= date that it was the fire marshal placing the test call.
>=3B
>= =3B Brian
>=3B
>=3B
>=3B
>=3B
>=3B On Nov 9=2C= 2010=2C at 4:23 AM=2C Cullen Jennings wrote:
>=3B
>=3B >=3B <= br>>=3B >=3B The reason I asked is because it seem like if the CA will = give certs to pretty much anyone=2C then this security approach does not wo= rk=2C and if the certs are not easy for an enterprise to get then the appro= ach also won't work because it won't be used. I understand this is a bit ou= tside of ECRIT work but seems like a tricky line to thread.
>=3B >= =3B
>=3B >=3B
>=3B >=3B
>=3B >=3B On Nov 7=2C 2010= =2C at 5:21 PM=2C Bernard Aboba wrote:
>=3B >=3B
>=3B >=3B&g= t=3B The statements in NENA i2 would seem to imply that any LIS would be ab= le to obtain a certificate chaining to a VESA trust anchor=2C to enable sig= ning of location.
>=3B >=3B>=3B
>=3B >=3B>=3B However= =2C I am not aware of a document that provides details of the certificates= =2C hierarchy=2C issuance policies=2C revocation=2C etc. so as to allow thi= s to become operational (e.g. by sub-contracting to a vendor with experienc= e in this area).
>=3B >=3B>=3B
>=3B >=3B>=3B>=3B From= : fluffy@cisco.com
>=3B >=3B>=3B>=3B Date: Sun=2C 7 Nov 2010 15:= 52:16 -0700
>=3B >=3B>=3B>=3B To: ecrit@ietf.org
>=3B >= =3B>=3B>=3B Subject: [Ecrit] draft-ietf-ecrit-trustworthy-location and = who can sign location
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B&= gt=3B
>=3B >=3B>=3B>=3B Enterprises could operate a LIS for wir= eline phones or wifi phones in the enterprise - would they be able to get a= cert rooted in VESA to sign location?
>=3B >=3B>=3B>=3B
>= =3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B
>=3B >=3B>= =3B>=3B _______________________________________________
>=3B >=3B&= gt=3B>=3B Ecrit mailing list
>=3B >=3B>=3B>=3B Ecrit@ietf.org<= br>>=3B >=3B>=3B>=3B https://www.ietf.org/mailman/listinfo/ecrit>=3B >=3B
>=3B >=3B __________________________________________= _____
>=3B >=3B Ecrit mailing list
>=3B >=3B Ecrit@ietf.org>=3B >=3B https://www.ietf.org/mailman/listinfo/ecrit
>=3B
= = --_7ae8d3fa-bf2d-4e1a-b1ad-38a9e24abc7e_-- From dworley@avaya.com Mon Nov 8 22:36:00 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A02C428C0EB for ; Mon, 8 Nov 2010 22:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.146 X-Spam-Level: X-Spam-Status: No, score=-102.146 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-Au-Jg3Wm9R for ; Mon, 8 Nov 2010 22:35:49 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 212633A6802 for ; Mon, 8 Nov 2010 22:35:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ562EyHCzI1/2dsb2JhbACiHnGiZgKZWIJxglcEhFiJIA X-IronPort-AV: E=Sophos;i="4.59,173,1288584000"; d="scan'208";a="217672261" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Nov 2010 01:35:31 -0500 X-IronPort-AV: E=Sophos;i="4.59,173,1288584000"; d="scan'208";a="535676832" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Nov 2010 01:35:31 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 9 Nov 2010 01:35:30 -0500 From: "Worley, Dale R (Dale)" To: "ecrit@ietf.org" , Robert Sparks Date: Tue, 9 Nov 2010 01:34:13 -0500 Thread-Topic: Errata report for errata 1261 and 1262 to RFC 5031, "A URN for Emergency and Other Well-Known Services" Thread-Index: AQHLf9hN3rsZltJ5VkW88BpsnTzXew== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 15 Nov 2010 00:10:23 -0800 Subject: [Ecrit] Errata report for errata 1261 and 1262 to RFC 5031, "A URN for Emergency and Other Well-Known Services" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 06:36:00 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC5031, "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services" Source of RFC: ecrit (rai) Errata ID: 1261 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2008-01-13 Section 7.2 (p.11) says: [LOST] Hardie, T., "LoST: A Location-to-Service Translation | Protocol", Work in Progress, March 2007. It should say: [LOST] Hardie, T., "LoST: A Location-to-Service Translation | Protocol", Work in Progress, August 2007. Notes: Outdated reference. The publication of RFC 5012 and this RFC (5031) apparently has been coordinated. Hence, both RFCs should refer to the same version of this particular work in progress. ---------------------------------------------------------------------- Recommended status: (correct) Hold for document update The erratum is probably correct, but seems to result in no loss of information. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC5031, "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services" Source of RFC: ecrit (rai) Errata ID: 1262 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2008-01-13 Section App.A (p.13) says: tel:sos This solution avoids name conflicts, but requires extending | the "tel" URI "tel" [RFC3966]. It also only works if every outbound proxy knows how to route requests to a proxy that can reach emergency services since tel URIs do not identify the destination server. It should say: tel:sos This solution avoids name conflicts, but requires extending | the "tel" URI [RFC3966]. It also only works if every outbound proxy knows how to route requests to a proxy that can reach emergency services since tel URIs do not identify the destination server. Notes: Spurious word replication of "tel" . For conformance with the display enhancement style used throughout the document, it might also have been preferable to use single quotes: 'tel' . ---------------------------------------------------------------------- Recommended status: (correct) Hold for document update =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dale From hannes.tschofenig@nsn.com Mon Nov 15 23:34:53 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4C23A6C92 for ; Mon, 15 Nov 2010 23:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.477 X-Spam-Level: X-Spam-Status: No, score=-100.477 tagged_above=-999 required=5 tests=[AWL=1.522, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bAIAF0bwZNS for ; Mon, 15 Nov 2010 23:34:53 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 9D79C3A6AA1 for ; Mon, 15 Nov 2010 23:34:52 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id oAG7ZW9b028138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Nov 2010 08:35:32 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id oAG7ZR2V025095; Tue, 16 Nov 2010 08:35:32 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Nov 2010 08:35:31 +0100 Received: from 10.144.234.239 ([10.144.234.239]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.35]) with Microsoft Exchange Server HTTP-DAV ; Tue, 16 Nov 2010 07:35:30 +0000 User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Tue, 16 Nov 2010 09:35:23 +0200 From: Hannes Tschofenig To: "ext Worley, Dale R (Dale)" , "ecrit@ietf.org" , Robert Sparks Message-ID: Thread-Topic: [Ecrit] Errata report for errata 1261 and 1262 to RFC 5031, "A URN for Emergency and Other Well-Known Services" Thread-Index: AQHLf9hN3rsZltJ5VkW88BpsnTzXe5NzwfeL In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Nov 2010 07:35:31.0616 (UTC) FILETIME=[D91DE200:01CB8560] Subject: Re: [Ecrit] Errata report for errata 1261 and 1262 to RFC 5031, "A URN for Emergency and Other Well-Known Services" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 07:34:53 -0000 These two corrections are fine for me. On 11/9/10 8:34 AM, "ext Worley, Dale R (Dale)" wrote: > ====================================================================== > RFC5031, "A Uniform Resource Name (URN) for Emergency and Other > Well-Known Services" > Source of RFC: ecrit (rai) > > Errata ID: 1261 > > Status: Reported > Type: Editorial > > Reported By: Alfred Hoenes > Date Reported: 2008-01-13 > > Section 7.2 (p.11) says: > > [LOST] Hardie, T., "LoST: A Location-to-Service Translation > | Protocol", Work in Progress, March 2007. > > > It should say: > > [LOST] Hardie, T., "LoST: A Location-to-Service Translation > | Protocol", Work in Progress, August 2007. > > > Notes: > > Outdated reference. > > The publication of RFC 5012 and this RFC (5031) apparently has been > coordinated. Hence, both RFCs should refer to the same version of > this particular work in progress. > ---------------------------------------------------------------------- > Recommended status: (correct) Hold for document update > > The erratum is probably correct, but seems to result in no loss of > information. > ====================================================================== > RFC5031, "A Uniform Resource Name (URN) for Emergency and Other > Well-Known Services" > Source of RFC: ecrit (rai) > > Errata ID: 1262 > > Status: Reported > Type: Editorial > > Reported By: Alfred Hoenes > Date Reported: 2008-01-13 > > Section App.A (p.13) says: > > tel:sos This solution avoids name conflicts, but requires extending > | the "tel" URI "tel" [RFC3966]. It also only works if every > outbound proxy knows how to route requests to a proxy that can > reach emergency services since tel URIs do not identify the > destination server. > > > It should say: > > tel:sos This solution avoids name conflicts, but requires extending > | the "tel" URI [RFC3966]. It also only works if every outbound > proxy knows how to route requests to a proxy that can reach > emergency services since tel URIs do not identify the destination > server. > > > Notes: > > Spurious word replication of "tel" . > > For conformance with the display enhancement style used throughout the > document, it might also have been preferable to use single quotes: > 'tel' . > ---------------------------------------------------------------------- > Recommended status: (correct) Hold for document update > ====================================================================== > > Dale > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Wed Nov 17 06:56:52 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840453A6918 for ; Wed, 17 Nov 2010 06:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.03 X-Spam-Level: X-Spam-Status: No, score=-103.03 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bu9CuQPM14co for ; Wed, 17 Nov 2010 06:56:49 -0800 (PST) Received: from barmail3.idig.net (barmail3.idig.net [64.34.111.253]) by core3.amsl.com (Postfix) with ESMTP id BF2313A6904 for ; Wed, 17 Nov 2010 06:56:48 -0800 (PST) X-ASG-Debug-ID: 1290005853-5b4ff0160001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail3.idig.net with ESMTP id 2UnGGykpq79c8Li9 for ; Wed, 17 Nov 2010 06:57: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.54]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PIjRv-0002le-HF for ecrit@ietf.org; Wed, 17 Nov 2010 06:57:33 -0800 From: Brian Rosen Content-Type: multipart/alternative; boundary=Apple-Mail-35-313513334 Date: Wed, 17 Nov 2010 09:57:22 -0500 X-ASG-Orig-Subj: Validation for Dispatch in LoST Message-Id: <66485071-F496-4D33-A133-CA751A80B4A4@brianrosen.net> To: ECRIT Org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1290005853 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.61 X-Barracuda-Spam-Status: No, SCORE=0.61 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=HTML_FONT_FACE_BAD, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.46893 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.61 HTML_FONT_FACE_BAD BODY: HTML font face is not a word Subject: [Ecrit] Validation for Dispatch in LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 14:56:52 -0000 --Apple-Mail-35-313513334 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii James Winterbottom pointed out to me this text in RFC5102: A caller location is considered valid if the civic or geographic location is recognizable within an acceptable location reference system (e.g., United States Postal Address or the WGS-84 datum) and can be mapped to one or more PSAPs.=20 =20 In -framework it says: 6.10. Location validation Validation in this context means both that there is a mapping from the address to a PSAP and that the PSAP understands how to direct responders to the location. It is recommended that location be validated prior to a device placing an actual emergency call; some jurisdictions require that this be done. Notice that the second part ("and can be mapped...") in 5012 is = referring to validation for routing, where the text in -framework = includes validation for dispatch. =20 James claims this is a conflict, which will lead to confusion. My = response is that "recognizable within an acceptable location reference = system" is the location reference system in the LoST server, which will = be whatever the local emergency authority's deem is needed. In most = cases, that would be valid for dispatch. I gave James the following examples: a) There is a building with 2 floor served by one PSAP, and the rest = served by another. This happens. The 2 floors could be part of a = university which has it's own PSAP and responders, or it could be part = of a secure government facility which has a similar situation. In this = case, for a civic address, FLOOR must be present, and valid, in order to = route (and to dispatch). b) There is a building with a large number of floors in a jurisdiction = where there is a requirement that location be reported with FLOOR (and = often UNIT) if the building is over a certain size limit. Again, FLOOR = would have to be present and valid, even though FLOOR is not needed to = route. c) The LoST server may have FLOOR information, but it may not be a = required element. If the location sent in the LoST request contained = FLOOR, but the value was not in the right range, the LoST server should = respond with FLOOR in the list. On the other hand, if FLOOR = was not present, it wouldn't be an error. Recall that validation is best done when inserting location information = into a LIS; well before an emergency call. A location suitable for = dispatch is also suitable for routing, but a location suitable for = routing is not necessarily suitable for dispatch.=20 I don't see a problem here. I think that the "acceptable location = system" is determined by the jurisdiction providing the LoST server, and = if it requires validation to a dispatchable location, it can reasonably = require the LoST server to do that (by suitable provisioning). = -framework says exactly the right thing. Over in NENA, we are requiring location be valid for dispatch, and we = are equipping the LoST server with the information needed to determine = that. Brian --Apple-Mail-35-313513334 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii James Winterbottom pointed out to me this text in = RFC5102:
      = civic or geographic location is recognizable within an = acceptable
      =
location reference system (e.g., United States Postal Address =
or
      =
the WGS-84 datum) and can be mapped to one or more PSAPs. =
In -framework it = says:

.  Location = validation

   Validation in this =
context means both that there is a mapping =
from
   the address to a =
PSAP and that the PSAP understands how to =
direct
   responders to the =
location.  It is recommended that location =
be
   validated prior to a =
device placing an actual emergency call; =
some
   jurisdictions =
require that this be done.

I gave James the following examples:
a) There is a = building with 2 floor served by one PSAP, and the rest served by = another.  This happens.  The 2 floors could be part of a = university which has it's own PSAP and responders,  or it could be = part of a secure government facility which has a similar situation. =  In this case, for a civic address, FLOOR must be present, and = valid, in order to route (and to dispatch).
b) There is a building = with a large number of floors in a jurisdiction where there is a = requirement that location be reported with FLOOR (and often UNIT) if the = building is over a certain size limit.  Again, FLOOR would have to = be present and valid, even though FLOOR is not needed to route.
c) = The LoST server may have FLOOR information, but it may not be a required = element.  If the location sent in the LoST request contained FLOOR, = but the value was not in the right range, the LoST server should respond = with FLOOR in the <invalid> list.  On the other hand, if = FLOOR was not present, it wouldn't be an error.


Over in = NENA, we are requiring location be valid for dispatch, and we are = equipping the LoST server with the information needed to determine = that.
Brian

= --Apple-Mail-35-313513334-- From fluffy@cisco.com Fri Nov 19 08:30:39 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DDD3A680B for ; Fri, 19 Nov 2010 08:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.572 X-Spam-Level: X-Spam-Status: No, score=-110.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJmJqhWBeIeO for ; Fri, 19 Nov 2010 08:30:37 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A8B103A6872 for ; Fri, 19 Nov 2010 08:30:37 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANc05kyrR7H+/2dsb2JhbACUKY4zcaIAm0OFSwSEWoYBgw6Cbw X-IronPort-AV: E=Sophos;i="4.59,223,1288569600"; d="scan'208";a="382861297" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 19 Nov 2010 16:31:27 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAJGVQGb022170; Fri, 19 Nov 2010 16:31:26 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 19 Nov 2010 09:32:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7BF71941-030E-4DD5-8FDC-77668B222C22@cisco.com> References: <33549AB2-0551-41E0-ACD3-FE0EE457A0AF@cisco.com> <4DB6C5B1-73E5-4507-97D6-9CCC7CD06279@cisco.com>, <86555FCC-212D-4574-A343-B9957B114EE8@brianrosen.net> To: Bernard Aboba X-Mailer: Apple Mail (2.1082) Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-trustworthy-location and who can sign location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 16:30:39 -0000 Brian & Bernard - thanks. Makes sense.=20 On Nov 9, 2010, at 1:29 PM, Bernard Aboba wrote: > The issuance policy for the LIS certificate would need to be ironed = out to understand how this could work. this would be part of a suite of = documents describing the operation of the Certificate Authority. As = Brian notes, leveraging the fire marshall visit or related building = documents could decrease or perhaps eliminate the need for an in-person = visit. However, typical verification operations of a public CA would be = likely to apply here, in addition to any special requirements for LIS = certificate issuance, so that the operation is likely to be non-trivial = in terms of cost.=20 >=20 >=20 > In practice, this policy is part of a document set that defines the = operation of the Certificate Authority. =20 >=20 > > Subject: Re: [Ecrit] draft-ietf-ecrit-trustworthy-location and who = can sign location > > From: br@brianrosen.net > > Date: Tue, 9 Nov 2010 09:51:24 -0500 > > CC: bernard_aboba@hotmail.com; ecrit@ietf.org > > To: fluffy@cisco.com > >=20 > > It's conceivable that this could be made to work, only because it's = possible that the local PSAP would have knowledge of local enterprises = and could vouch for the authenticity of the enterprise. Mechanizing this = might be difficult however. > >=20 > > I've long thought that we should have more extensive testing = mechanisms. At least in the U.S., every substantial enterprise is = visited regularly by a fire marshal. If the fire marshal could easily = place a test call that verified all the bits were working, that would = help a lot. We do have a big part of that in the -phonebcp spec. The = test call could validate the credential of the enterprise if we could = reasonably validate that it was the fire marshal placing the test call. > >=20 > > Brian > >=20 > >=20 > >=20 > >=20 > > On Nov 9, 2010, at 4:23 AM, Cullen Jennings wrote: > >=20 > > >=20 > > > The reason I asked is because it seem like if the CA will give = certs to pretty much anyone, then this security approach does not work, = and if the certs are not easy for an enterprise to get then the approach = also won't work because it won't be used. I understand this is a bit = outside of ECRIT work but seems like a tricky line to thread.=20 > > >=20 > > >=20 > > >=20 > > > On Nov 7, 2010, at 5:21 PM, Bernard Aboba wrote: > > >=20 > > >> The statements in NENA i2 would seem to imply that any LIS would = be able to obtain a certificate chaining to a VESA trust anchor, to = enable signing of location.=20 > > >>=20 > > >> However, I am not aware of a document that provides details of = the certificates, hierarchy, issuance policies, revocation, etc. so as = to allow this to become operational (e.g. by sub-contracting to a vendor = with experience in this area).=20 > > >>=20 > > >>> From: fluffy@cisco.com > > >>> Date: Sun, 7 Nov 2010 15:52:16 -0700 > > >>> To: ecrit@ietf.org > > >>> Subject: [Ecrit] draft-ietf-ecrit-trustworthy-location and who = can sign location > > >>>=20 > > >>>=20 > > >>> Enterprises could operate a LIS for wireline phones or wifi = phones in the enterprise - would they be able to get a cert rooted in = VESA to sign location? > > >>>=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 > >=20 From hannes.tschofenig@gmx.net Mon Nov 22 04:30:21 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E01903A6A4A for ; Mon, 22 Nov 2010 04:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.323 X-Spam-Level: X-Spam-Status: No, score=-102.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzODl+kHH72J for ; Mon, 22 Nov 2010 04:30:21 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 9FE283A69B1 for ; Mon, 22 Nov 2010 04:30:20 -0800 (PST) Received: (qmail invoked by alias); 22 Nov 2010 12:31:15 -0000 Received: from unknown (EHLO [10.255.128.169]) [192.100.123.77] by mail.gmx.net (mp060) with SMTP; 22 Nov 2010 13:31:15 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/mQmkozs3myo02wyphcl82POE8TDckmq2esNe0vG oCOgUWJGlSU5IX From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Nov 2010 14:31:13 +0200 Message-Id: <8B68D4BB-4565-4A78-8AC7-4B044D6BC966@gmx.net> To: ECRIT Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig Subject: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 12:30:22 -0000 Hi all,=20 we had a fairly good discussion at the last meeting on the PSAP callback = topic triggered by a review from Cullen. As a summary the question came = up whether we couldn't fall back to a "token-based solution approach". This token-based approach roughly works as follows: When the emergency = call is initially made then the calling device attaches some blob = (called the token here) that is then stored at intermediate devices = along the path (for a limited period of time; such as 2 hours). Then, = when a callback is made the same blob is attached. When checking for the = callback the received blob is compared with the stored one and if they = match better treatment is provided to the callback (otherwise the call = would be treated as any other call that has no marking attached at all).=20= The implication of this design is the following: Section 1 of = http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 lists a = couple of cases where the currently described solution from the PhoneBCP = document does not work. With the token based approach the following = assumptions have to be made regarding the synchronization of the token = between different entities:=20 _ Section 1.1: Route Asymmetry The token has to be shared between the inbound and the outbound = proxy. =20 - Section 1.2: Multi-Stage Resolution No additional considerations=20 - Section 1.3: Call Forwarding In a call forwarding scenario the token needs to be forwarded as = well.=20 - Section 1.4: PSTN Interworking In this scenario the token would not be forwarded to the PSTN device = and hence may not be available for the callback. As such, the token has = to be shared between the two PSTN-VoIP gateways.=20 - Section 1.5: Network-based Service URN Resolution No additional considerations=20 =20 If there are no objections with the suggested approach (nor with the = potential requirement for state synchronization) then I will make the = changes with the next draft update.=20 Please respond by the end of the week if you have objections! Ciao Hannes From br@brianrosen.net Mon Nov 22 06:48:56 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAA0F3A6A98 for ; Mon, 22 Nov 2010 06:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.428 X-Spam-Level: X-Spam-Status: No, score=-103.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUiWKOaqOwYm for ; Mon, 22 Nov 2010 06:48:55 -0800 (PST) Received: from barmail3.idig.net (barmail3.idig.net [64.34.111.253]) by core3.amsl.com (Postfix) with ESMTP id D33F23A6A97 for ; Mon, 22 Nov 2010 06:48:55 -0800 (PST) X-ASG-Debug-ID: 1290437390-357c55b80001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail3.idig.net with ESMTP id 3Jua7PersaWI2SWa; Mon, 22 Nov 2010 06:49:50 -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.54]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PKXiF-0002HX-RF; Mon, 22 Nov 2010 06:49:49 -0800 Mime-Version: 1.0 (Apple Message framework v1081) X-ASG-Orig-Subj: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <8B68D4BB-4565-4A78-8AC7-4B044D6BC966@gmx.net> Date: Mon, 22 Nov 2010 09:49:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B68D4BB-4565-4A78-8AC7-4B044D6BC966@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1081) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1290437390 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.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.47370 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: ECRIT Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 14:48:56 -0000 ISTM that a token could be inserted by any element in the path, and = there could be more than one of them. Trying to make the device fabricate the token may or may not make sense, = depending on the circumstances. I think that the only implications are at the PSAP: the PSAP has to = include the token(s) in call forwarding or call back situations. Brian On Nov 22, 2010, at 7:31 AM, Hannes Tschofenig wrote: > Hi all,=20 >=20 > we had a fairly good discussion at the last meeting on the PSAP = callback topic triggered by a review from Cullen. As a summary the = question came up whether we couldn't fall back to a "token-based = solution approach". >=20 > This token-based approach roughly works as follows: When the emergency = call is initially made then the calling device attaches some blob = (called the token here) that is then stored at intermediate devices = along the path (for a limited period of time; such as 2 hours). Then, = when a callback is made the same blob is attached. When checking for the = callback the received blob is compared with the stored one and if they = match better treatment is provided to the callback (otherwise the call = would be treated as any other call that has no marking attached at all).=20= >=20 > The implication of this design is the following: Section 1 of = http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 lists a = couple of cases where the currently described solution from the PhoneBCP = document does not work. With the token based approach the following = assumptions have to be made regarding the synchronization of the token = between different entities:=20 >=20 > _ Section 1.1: Route Asymmetry >=20 > The token has to be shared between the inbound and the outbound = proxy. =20 >=20 > - Section 1.2: Multi-Stage Resolution >=20 > No additional considerations=20 >=20 > - Section 1.3: Call Forwarding >=20 > In a call forwarding scenario the token needs to be forwarded as = well.=20 >=20 > - Section 1.4: PSTN Interworking >=20 > In this scenario the token would not be forwarded to the PSTN device = and hence may not be available for the callback. As such, the token has = to be shared between the two PSTN-VoIP gateways.=20 >=20 > - Section 1.5: Network-based Service URN Resolution >=20 > No additional considerations=20 >=20 > If there are no objections with the suggested approach (nor with the = potential requirement for state synchronization) then I will make the = changes with the next draft update.=20 >=20 > Please respond by the end of the week if you have objections! >=20 > Ciao > Hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@nsn.com Mon Nov 22 09:29:02 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B0203A6A61 for ; Mon, 22 Nov 2010 09:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24rb+sDVZg02 for ; Mon, 22 Nov 2010 09:29:01 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id C993E3A69ED for ; Mon, 22 Nov 2010 09:29:00 -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 oAMHTbMN017810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Nov 2010 18:29:37 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id oAMHTZfH000665; Mon, 22 Nov 2010 18:29:36 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Nov 2010 18:29:26 +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, 22 Nov 2010 19:29:24 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450365CA0E@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! Thread-Index: AcuKVIfXb1xfb3MeR5OPd/DjqxeuqAAFfTcg References: <8B68D4BB-4565-4A78-8AC7-4B044D6BC966@gmx.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Brian Rosen" , "Hannes Tschofenig" X-OriginalArrivalTime: 22 Nov 2010 17:29:26.0792 (UTC) FILETIME=[CFD0B880:01CB8A6A] Cc: ECRIT Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 17:29:02 -0000 It is theoretically possible to let an intermediary insert the token. Note: When the device does not insert the token then it will not be able to check it when it receives it. Providing special call treatment on the end device is very likely going to be necessary.=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of ext Brian Rosen > Sent: Monday, November 22, 2010 4:50 PM > To: Hannes Tschofenig > Cc: ECRIT > Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update -=20 > Feedback needed! >=20 > ISTM that a token could be inserted by any element in the=20 > path, and there could be more than one of them. >=20 > Trying to make the device fabricate the token may or may not=20 > make sense, depending on the circumstances. >=20 > I think that the only implications are at the PSAP: the PSAP=20 > has to include the token(s) in call forwarding or call back=20 > situations. >=20 > Brian >=20 > On Nov 22, 2010, at 7:31 AM, Hannes Tschofenig wrote: >=20 > > Hi all,=20 > >=20 > > we had a fairly good discussion at the last meeting on the=20 > PSAP callback topic triggered by a review from Cullen. As a=20 > summary the question came up whether we couldn't fall back to=20 > a "token-based solution approach". > >=20 > > This token-based approach roughly works as follows: When=20 > the emergency call is initially made then the calling device=20 > attaches some blob (called the token here) that is then=20 > stored at intermediate devices along the path (for a limited=20 > period of time; such as 2 hours). Then, when a callback is=20 > made the same blob is attached. When checking for the=20 > callback the received blob is compared with the stored one=20 > and if they match better treatment is provided to the=20 > callback (otherwise the call would be treated as any other=20 > call that has no marking attached at all).=20 > >=20 > > The implication of this design is the following: Section 1=20 > of=20 > http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02=20 > lists a couple of cases where the currently described=20 > solution from the PhoneBCP document does not work. With the=20 > token based approach the following assumptions have to be=20 > made regarding the synchronization of the token between=20 > different entities:=20 > >=20 > > _ Section 1.1: Route Asymmetry > >=20 > > The token has to be shared between the inbound and the=20 > outbound proxy. =20 > >=20 > > - Section 1.2: Multi-Stage Resolution > >=20 > > No additional considerations=20 > >=20 > > - Section 1.3: Call Forwarding > >=20 > > In a call forwarding scenario the token needs to be=20 > forwarded as well.=20 > >=20 > > - Section 1.4: PSTN Interworking > >=20 > > In this scenario the token would not be forwarded to the=20 > PSTN device and hence may not be available for the callback.=20 > As such, the token has to be shared between the two PSTN-VoIP=20 > gateways.=20 > >=20 > > - Section 1.5: Network-based Service URN Resolution > >=20 > > No additional considerations=20 > >=20 > > If there are no objections with the suggested approach (nor=20 > with the potential requirement for state synchronization)=20 > then I will make the changes with the next draft update.=20 > >=20 > > Please respond by the end of the week if you have objections! > >=20 > > Ciao > > Hannes > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From James.Winterbottom@andrew.com Mon Nov 22 15:12:54 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E702B28C142 for ; Mon, 22 Nov 2010 15:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+D5CBAxcI9l for ; Mon, 22 Nov 2010 15:12:48 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 5F96F28C119 for ; Mon, 22 Nov 2010 15:12:48 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:31659 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S38841248Ab0KVXNo (ORCPT ); Mon, 22 Nov 2010 17:13:44 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 22 Nov 2010 17:13:43 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 23 Nov 2010 07:13:39 +0800 From: "Winterbottom, James" To: Brian Rosen , ECRIT Org Date: Tue, 23 Nov 2010 07:13:37 +0800 Thread-Topic: [Ecrit] Validation for Dispatch in LoST Thread-Index: AcuGZ8tmR1BIVtsBSvezifb4z6bJFQEMg+PQ Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120F234D209@SISPE7MB1.commscope.com> References: <66485071-F496-4D33-A133-CA751A80B4A4@brianrosen.net> In-Reply-To: <66485071-F496-4D33-A133-CA751A80B4A4@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC81880120F234D209SISPE7MB1co_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Ecrit] Validation for Dispatch in LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 23:12:55 -0000 --_000_5A55A45AE77F5941B18E5457ECAC81880120F234D209SISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, I am sorry that it has taken so long to respond to this, I have been busy w= ith a few other things. I still have concerns with your proposal here. I think it likely that there= will be LoST servers both on the public Internet and in the ESInets. Both = of these will be required to do location validation. Location validation in= ECRIT has a primary function of ensuring that the location will route to a= PSAP. If we take your approach, that LVF must provide a dispatch capable l= ocation then things get very murky. PhoneBCP says: "ED-44 Endpoints SHOULD validate civic locations when they r= eceive them from their LCP. Validation SHOULD be performed in conjunction with the LoST route query to minimize load on the LoST server." If this guidance is followed, and a coarse location provided as is proposed= in http://tools.ietf.org/id/-ecrit-rough-loc then the end-point will get a= n error saying that the location is invalid. Clearly this wrong! Cheers James ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of B= rian Rosen Sent: Thursday, 18 November 2010 1:57 AM To: ECRIT Org Subject: [Ecrit] Validation for Dispatch in LoST James Winterbottom pointed out to me this text in RFC5102: A caller location is considered valid if the civic or geographic location is recognizable within an acceptable location reference system (e.g., United States Postal Address or the WGS-84 datum) and can be mapped to one or more PSAPs. In -framework it says: 6.10. Location validation Validation in this context means both that there is a mapping from the address to a PSAP and that the PSAP understands how to direct responders to the location. It is recommended that location be validated prior to a device placing an actual emergency call; some jurisdictions require that this be done. Notice that the second part ("and can be mapped...") in 5012 is referring t= o validation for routing, where the text in -framework includes validation = for dispatch. James claims this is a conflict, which will lead to confusion. My response= is that "recognizable within an acceptable location reference system" is t= he location reference system in the LoST server, which will be whatever the= local emergency authority's deem is needed. In most cases, that would be = valid for dispatch. I gave James the following examples: a) There is a building with 2 floor served by one PSAP, and the rest served= by another. This happens. The 2 floors could be part of a university whi= ch has it's own PSAP and responders, or it could be part of a secure gover= nment facility which has a similar situation. In this case, for a civic ad= dress, FLOOR must be present, and valid, in order to route (and to dispatch= ). b) There is a building with a large number of floors in a jurisdiction wher= e there is a requirement that location be reported with FLOOR (and often UN= IT) if the building is over a certain size limit. Again, FLOOR would have = to be present and valid, even though FLOOR is not needed to route. c) The LoST server may have FLOOR information, but it may not be a required= element. If the location sent in the LoST request contained FLOOR, but th= e value was not in the right range, the LoST server should respond with FLO= OR in the list. On the other hand, if FLOOR was not present, it = wouldn't be an error. Recall that validation is best done when inserting location information int= o a LIS; well before an emergency call. A location suitable for dispatch i= s also suitable for routing, but a location suitable for routing is not nec= essarily suitable for dispatch. I don't see a problem here. I think that the "acceptable location system" = is determined by the jurisdiction providing the LoST server, and if it requ= ires validation to a dispatchable location, it can reasonably require the L= oST server to do that (by suitable provisioning). -framework says exactly= the right thing. Over in NENA, we are requiring location be valid for dispatch, and we are e= quipping the LoST server with the information needed to determine that. Brian --_000_5A55A45AE77F5941B18E5457ECAC81880120F234D209SISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Brian,

 

I am sorry that it has taken so long t= o respond to this, I have been busy with a few other things.

 

I still have concerns with your propos= al here. I think it likely that there will be LoST servers both on the public Internet and in the ESInets. Both of these will be required to do location validation. Location validation in ECRIT has a primary function of ensuring that the location will route to a PSAP. If we take your approach, that LVF = must provide a dispatch capable location then things get very murky.<= /span>

 

PhoneBCP says: “ED-44 End=
points SHOULD validate civic locations when they receive
  = them from their LCP.  Validation SHOULD be performed in conjunction
  =
 with the LoST route query to minimize load on the LoST server.”=

 

If this guidance is followed, and a co= arse location provided as is proposed in http://tools.ietf.org/id= /-ecrit-rough-loc then the end-point will get an error saying that the location is invalid. C= learly this wrong!

 

Cheers

James

 

 

<= span style=3D'font-size:12.0pt;color:navy'> 

From:= ecrit-bounces@ietf.org [mailto= :ecrit-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Thursday, 18 November = 2010 1:57 AM
To: ECRIT Org
Subject: [Ecrit] Validation = for Dispatch in LoST

 

James Winterbotto= m pointed out to me this text in RFC5102:

   &nbs= p;  A caller location is considered valid if the

      civic or geographic location is recogniz=
able within an acceptable
<=
font
size=3D2 face=3D"Courier New">  =
    location reference system (e.g., United States Postal Ad=
dress or
  =
    the WGS-84 datum) and can be mapped to one or more PSAPs=
.

 

In -framework it says:

6.10= .  Loca= tion validation

&=
nbsp;  Validation in this context means both that there is a mapping f=
rom
  =
 the address to a PSAP and that the PSAP understands how to direct
  =
 responders to the location.  It is recommended that location be=

  =
 validated prior to a device placing an actual emergency call; some
  =
 jurisdictions require that this be done.

Notice that the second part ("and can be mapped...") in 5= 012 is referring to validation for routing, where the text in -framework includes validation for dispatch.  


James claims this is a conflict, which will = lead to confusion.  My response is that "recognizable within an accept= able location reference system" is the location reference system in the LoST server, which will be whatever the local emergency authority's deem is needed. &nbs= p;In most cases, that would be valid for dispatch.

I gave James the following examples:<= br> a) There is a building with 2 floor served b= y one PSAP, and the rest served by another.  This happens.  The 2 floor= s could be part of a university which has it's own PSAP and responders,  = ;or it could be part of a secure government facility which has a similar situat= ion.  In this case, for a civic address, FLOOR must be present, and valid, = in order to route (and to dispatch).
b) There is a building with a large number o= f floors in a jurisdiction where there is a requirement that location be repo= rted with FLOOR (and often UNIT) if the building is over a certain size limit. &= nbsp;Again, FLOOR would have to be present and valid, even though FLOOR is not needed t= o route.
c) The LoST server may have FLOOR informatio= n, but it may not be a required element.  If the location sent in the LoST request contained FLOOR, but the value was not in the right range, the LoST server should respond with FLOOR in the <invalid> list.  On the other hand, if FLOOR was not present, it wouldn't be an error.

Recall that validation is best done when inserting location information into a LIS= ; well before an emergency call.  A location suitable for dispatch is al= so suitable for routing, but a location suitable for routing is not necessaril= y suitable for dispatch. <= /p>

 

I don't see a problem here.  I think that the "acceptable location system" is determined by the jurisdiction providing the LoST server, a= nd if it requires validation to a dispatchable location, it can reasonably req= uire the LoST server to do that (by suitable provisioning).  =  -framework says exactly the right thing.

 

Over in NENA, we = are requiring location be valid for dispatch, and we are equipping the LoST ser= ver with the information needed to determine that.

 

Brian

 

 

--_000_5A55A45AE77F5941B18E5457ECAC81880120F234D209SISPE7MB1co_-- From Martin.Thomson@andrew.com Mon Nov 22 15:29:06 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0EB3A6AFA for ; Mon, 22 Nov 2010 15:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIKrXTvX5zAZ for ; Mon, 22 Nov 2010 15:28:59 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 36E933A6A08 for ; Mon, 22 Nov 2010 15:28:58 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:39875 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S500991Ab0KVX3y (ORCPT ); Mon, 22 Nov 2010 17:29:54 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 22 Nov 2010 17:29:53 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 23 Nov 2010 07:29:49 +0800 From: "Thomson, Martin" To: "Winterbottom, James" , Brian Rosen , ECRIT Org Date: Tue, 23 Nov 2010 07:29:45 +0800 Thread-Topic: [Ecrit] Validation for Dispatch in LoST Thread-Index: AcuGZ8tmR1BIVtsBSvezifb4z6bJFQEMg+PQAABt/9A= Message-ID: <8B0A9FCBB9832F43971E38010638454F03F33EA91F@SISPE7MB1.commscope.com> References: <66485071-F496-4D33-A133-CA751A80B4A4@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC81880120F234D209@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120F234D209@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F03F33EA91FSISPE7MB1comm_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Ecrit] Validation for Dispatch in LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 23:29:06 -0000 --_000_8B0A9FCBB9832F43971E38010638454F03F33EA91FSISPE7MB1comm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IGl0IG1pZ2h0IGJlIHJlYXNvbmFibGUgdG8gaGF2ZSB0aGUgZGV2aWNlL2Vu ZHBvaW50IGRldGVybWluZSB3aGV0aGVyIHRoZXJlIGlzIGEgcm91dGUgb3Igbm90IGFzIHRoZSBw cmltYXJ5IGdvYWwgb2YgRUQtNDQgdmFsaWRhdGlvbi4gIEFzIGxvbmcgYXMgdGhpcyBpcyBub3Qg YSBkZWZhdWx0IHJvdXRlLCB0aGVuIHRoZXJlIGlzIG5vIGNhdXNlIGZvciBwYW5pYy4NCg0KTG9T VCB2YWxpZGF0aW9uIGlzIGNvbnN0cmFpbmVkIGluIHdoYXQgaXQgY2FuIHJlcG9ydCAtIGl04oCZ cyB1bmNsZWFyIGhvdyBhIExvU1Qgc2VydmVyIHJlcG9ydHMgdGhhdCBhIGNpdmljIGFkZHJlc3Mg aXMgaW52YWxpZCBkdWUgdG8gbWlzc2luZyBlbGVtZW50cy4gIEluIGFjdHVhbCBmYWN0LCB0aGUg dGV4dCBpcyB3cml0dGVuIGluIGEgd2F5IHRoYXQgd291bGQgc2VlbSB0byBleGNsdWRlIHRoaXMg cG9zc2liaWxpdHkuICBJZiB0aGlzIHdlcmUgcG9zc2libGUsIGEgcm91Z2ggbG9jYXRpb24gbWln aHQgYmUgcmVwb3J0ZWQgYnkgdGhlIExvU1Qgc2VydmVyIGFzIGhhdmluZyBpbnZhbGlkIGVsZW1l bnRzICh0aG9zZSB0aGF0IG1pZ2h0IGJlIG5lZWRlZCBmb3IgZGlzcGF0Y2gpLCB0aG91Z2ggYSB2 YWx1ZSByb3V0ZSBtaWdodCBzdGlsbCBiZSBwcm92aWRlZC4NCg0KVGhhdOKAmXMgc29tZSBwcmV0 dHkgZnV6enkgc3BlY2lmaWNhdGlvbi4gIEkgZG9u4oCZdCB0aGluayB0aGF0IEkgY291bGQgcmVs aWFibHkgaW1wbGVtZW50IHRoYXQgZ2l2ZW4gd2hhdCBJIGtub3cgYWJvdXQgY2l2aWMgYWRkcmVz c2VzLCBidXQgaXTigJlzIHRoZSBiZXN0IHRoYXQgSSBjb3VsZCBjb21lIHVwIHdpdGggYWZ0ZXIg dGhpbmtpbmcgbW9yZSBhYm91dCBpdC4gIEkgc3VzcGVjdCB0aGF0IHRoaXMgaXMgd2h5IFNlY3Rp b24gOC40LjIgb2YgUkZDIDUyMjIgaXMgd3JpdHRlbiBhcyBpdCBpcyAtIHN1Y2ggZnV6emluZXNz IGlzbuKAmXQgY29uZHVjaXZlIHRvIGdldHRpbmcgaW50ZXJvcGVyYWJpbGl0eS4NCg0KKEEgY29u Y2VybiB0aGF0IEkgaGF2ZSBoZXJlIGlzIHRoYXQgYSBkZXZpY2UgZG9lc27igJl0IGhhdmUgYW55 IG9wdGlvbiB0byByZW1lZHkgcHJvYmxlbXMgd2l0aCBsb2NhdGlvbiB1bmxlc3MgdGhleSBoYXZl IGFsdGVybmF0aXZlIHNvdXJjZXMgb2YgbG9jYXRpb24uICAtcGhvbmUtYmNwIGRvZXNu4oCZdCBz cGVjaWZ5IHdoYXQgYSBkZXZpY2UgZG9lcyBpZiBpdCBkaXNjb3ZlcnMgdGhhdCB0aGUgbG9jYXRp b24gaXQgaGFzIGlzIG5vIGdvb2QuKQ0KDQotLU1hcnRpbg0KDQpGcm9tOiBlY3JpdC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFdp bnRlcmJvdHRvbSwgSmFtZXMNClNlbnQ6IFR1ZXNkYXksIDIzIE5vdmVtYmVyIDIwMTAgMTA6MTQg QU0NClRvOiBCcmlhbiBSb3NlbjsgRUNSSVQgT3JnDQpTdWJqZWN0OiBSZTogW0Vjcml0XSBWYWxp ZGF0aW9uIGZvciBEaXNwYXRjaCBpbiBMb1NUDQoNCkhpIEJyaWFuLA0KDQpJIGFtIHNvcnJ5IHRo YXQgaXQgaGFzIHRha2VuIHNvIGxvbmcgdG8gcmVzcG9uZCB0byB0aGlzLCBJIGhhdmUgYmVlbiBi dXN5IHdpdGggYSBmZXcgb3RoZXIgdGhpbmdzLg0KDQpJIHN0aWxsIGhhdmUgY29uY2VybnMgd2l0 aCB5b3VyIHByb3Bvc2FsIGhlcmUuIEkgdGhpbmsgaXQgbGlrZWx5IHRoYXQgdGhlcmUgd2lsbCBi ZSBMb1NUIHNlcnZlcnMgYm90aCBvbiB0aGUgcHVibGljIEludGVybmV0IGFuZCBpbiB0aGUgRVNJ bmV0cy4gQm90aCBvZiB0aGVzZSB3aWxsIGJlIHJlcXVpcmVkIHRvIGRvIGxvY2F0aW9uIHZhbGlk YXRpb24uIExvY2F0aW9uIHZhbGlkYXRpb24gaW4gRUNSSVQgaGFzIGEgcHJpbWFyeSBmdW5jdGlv biBvZiBlbnN1cmluZyB0aGF0IHRoZSBsb2NhdGlvbiB3aWxsIHJvdXRlIHRvIGEgUFNBUC4gSWYg d2UgdGFrZSB5b3VyIGFwcHJvYWNoLCB0aGF0IExWRiBtdXN0IHByb3ZpZGUgYSBkaXNwYXRjaCBj YXBhYmxlIGxvY2F0aW9uIHRoZW4gdGhpbmdzIGdldCB2ZXJ5IG11cmt5Lg0KDQoNClBob25lQkNQ IHNheXM6IOKAnEVELTQ0IEVuZHBvaW50cyBTSE9VTEQgdmFsaWRhdGUgY2l2aWMgbG9jYXRpb25z IHdoZW4gdGhleSByZWNlaXZlDQoNCiAgIHRoZW0gZnJvbSB0aGVpciBMQ1AuICBWYWxpZGF0aW9u IFNIT1VMRCBiZSBwZXJmb3JtZWQgaW4gY29uanVuY3Rpb24NCg0KICAgd2l0aCB0aGUgTG9TVCBy b3V0ZSBxdWVyeSB0byBtaW5pbWl6ZSBsb2FkIG9uIHRoZSBMb1NUIHNlcnZlci7igJ0NCg0KSWYg dGhpcyBndWlkYW5jZSBpcyBmb2xsb3dlZCwgYW5kIGEgY29hcnNlIGxvY2F0aW9uIHByb3ZpZGVk IGFzIGlzIHByb3Bvc2VkIGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC8tZWNyaXQtcm91Z2gt bG9jIHRoZW4gdGhlIGVuZC1wb2ludCB3aWxsIGdldCBhbiBlcnJvciBzYXlpbmcgdGhhdCB0aGUg bG9jYXRpb24gaXMgaW52YWxpZC4gQ2xlYXJseSB0aGlzIHdyb25nIQ0KDQpDaGVlcnMNCkphbWVz DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogZWNyaXQtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBCcmlhbiBSb3Nlbg0KU2VudDogVGh1cnNkYXksIDE4IE5vdmVtYmVyIDIwMTAgMTo1NyBBTQ0K VG86IEVDUklUIE9yZw0KU3ViamVjdDogW0Vjcml0XSBWYWxpZGF0aW9uIGZvciBEaXNwYXRjaCBp biBMb1NUDQoNCkphbWVzIFdpbnRlcmJvdHRvbSBwb2ludGVkIG91dCB0byBtZSB0aGlzIHRleHQg aW4gUkZDNTEwMjoNCiAgICAgIEEgY2FsbGVyIGxvY2F0aW9uIGlzIGNvbnNpZGVyZWQgdmFsaWQg aWYgdGhlDQoNCiAgICAgIGNpdmljIG9yIGdlb2dyYXBoaWMgbG9jYXRpb24gaXMgcmVjb2duaXph YmxlIHdpdGhpbiBhbiBhY2NlcHRhYmxlDQoNCiAgICAgIGxvY2F0aW9uIHJlZmVyZW5jZSBzeXN0 ZW0gKGUuZy4sIFVuaXRlZCBTdGF0ZXMgUG9zdGFsIEFkZHJlc3Mgb3INCg0KICAgICAgdGhlIFdH Uy04NCBkYXR1bSkgYW5kIGNhbiBiZSBtYXBwZWQgdG8gb25lIG9yIG1vcmUgUFNBUHMuDQoNCklu IC1mcmFtZXdvcmsgaXQgc2F5czoNCjYuMTAuICBMb2NhdGlvbiB2YWxpZGF0aW9uDQoNCiAgIFZh bGlkYXRpb24gaW4gdGhpcyBjb250ZXh0IG1lYW5zIGJvdGggdGhhdCB0aGVyZSBpcyBhIG1hcHBp bmcgZnJvbQ0KDQogICB0aGUgYWRkcmVzcyB0byBhIFBTQVAgYW5kIHRoYXQgdGhlIFBTQVAgdW5k ZXJzdGFuZHMgaG93IHRvIGRpcmVjdA0KDQogICByZXNwb25kZXJzIHRvIHRoZSBsb2NhdGlvbi4g IEl0IGlzIHJlY29tbWVuZGVkIHRoYXQgbG9jYXRpb24gYmUNCg0KICAgdmFsaWRhdGVkIHByaW9y IHRvIGEgZGV2aWNlIHBsYWNpbmcgYW4gYWN0dWFsIGVtZXJnZW5jeSBjYWxsOyBzb21lDQoNCiAg IGp1cmlzZGljdGlvbnMgcmVxdWlyZSB0aGF0IHRoaXMgYmUgZG9uZS4NCk5vdGljZSB0aGF0IHRo ZSBzZWNvbmQgcGFydCAoImFuZCBjYW4gYmUgbWFwcGVkLi4uIikgaW4gNTAxMiBpcyByZWZlcnJp bmcgdG8gdmFsaWRhdGlvbiBmb3Igcm91dGluZywgd2hlcmUgdGhlIHRleHQgaW4gLWZyYW1ld29y ayBpbmNsdWRlcyB2YWxpZGF0aW9uIGZvciBkaXNwYXRjaC4NCg0KSmFtZXMgY2xhaW1zIHRoaXMg aXMgYSBjb25mbGljdCwgd2hpY2ggd2lsbCBsZWFkIHRvIGNvbmZ1c2lvbi4gIE15IHJlc3BvbnNl IGlzIHRoYXQgInJlY29nbml6YWJsZSB3aXRoaW4gYW4gYWNjZXB0YWJsZSBsb2NhdGlvbiByZWZl cmVuY2Ugc3lzdGVtIiBpcyB0aGUgbG9jYXRpb24gcmVmZXJlbmNlIHN5c3RlbSBpbiB0aGUgTG9T VCBzZXJ2ZXIsIHdoaWNoIHdpbGwgYmUgd2hhdGV2ZXIgdGhlIGxvY2FsIGVtZXJnZW5jeSBhdXRo b3JpdHkncyBkZWVtIGlzIG5lZWRlZC4gIEluIG1vc3QgY2FzZXMsIHRoYXQgd291bGQgYmUgdmFs aWQgZm9yIGRpc3BhdGNoLg0KDQpJIGdhdmUgSmFtZXMgdGhlIGZvbGxvd2luZyBleGFtcGxlczoN CmEpIFRoZXJlIGlzIGEgYnVpbGRpbmcgd2l0aCAyIGZsb29yIHNlcnZlZCBieSBvbmUgUFNBUCwg YW5kIHRoZSByZXN0IHNlcnZlZCBieSBhbm90aGVyLiAgVGhpcyBoYXBwZW5zLiAgVGhlIDIgZmxv b3JzIGNvdWxkIGJlIHBhcnQgb2YgYSB1bml2ZXJzaXR5IHdoaWNoIGhhcyBpdCdzIG93biBQU0FQ IGFuZCByZXNwb25kZXJzLCAgb3IgaXQgY291bGQgYmUgcGFydCBvZiBhIHNlY3VyZSBnb3Zlcm5t ZW50IGZhY2lsaXR5IHdoaWNoIGhhcyBhIHNpbWlsYXIgc2l0dWF0aW9uLiAgSW4gdGhpcyBjYXNl LCBmb3IgYSBjaXZpYyBhZGRyZXNzLCBGTE9PUiBtdXN0IGJlIHByZXNlbnQsIGFuZCB2YWxpZCwg aW4gb3JkZXIgdG8gcm91dGUgKGFuZCB0byBkaXNwYXRjaCkuDQpiKSBUaGVyZSBpcyBhIGJ1aWxk aW5nIHdpdGggYSBsYXJnZSBudW1iZXIgb2YgZmxvb3JzIGluIGEganVyaXNkaWN0aW9uIHdoZXJl IHRoZXJlIGlzIGEgcmVxdWlyZW1lbnQgdGhhdCBsb2NhdGlvbiBiZSByZXBvcnRlZCB3aXRoIEZM T09SIChhbmQgb2Z0ZW4gVU5JVCkgaWYgdGhlIGJ1aWxkaW5nIGlzIG92ZXIgYSBjZXJ0YWluIHNp emUgbGltaXQuICBBZ2FpbiwgRkxPT1Igd291bGQgaGF2ZSB0byBiZSBwcmVzZW50IGFuZCB2YWxp ZCwgZXZlbiB0aG91Z2ggRkxPT1IgaXMgbm90IG5lZWRlZCB0byByb3V0ZS4NCmMpIFRoZSBMb1NU IHNlcnZlciBtYXkgaGF2ZSBGTE9PUiBpbmZvcm1hdGlvbiwgYnV0IGl0IG1heSBub3QgYmUgYSBy ZXF1aXJlZCBlbGVtZW50LiAgSWYgdGhlIGxvY2F0aW9uIHNlbnQgaW4gdGhlIExvU1QgcmVxdWVz dCBjb250YWluZWQgRkxPT1IsIGJ1dCB0aGUgdmFsdWUgd2FzIG5vdCBpbiB0aGUgcmlnaHQgcmFu Z2UsIHRoZSBMb1NUIHNlcnZlciBzaG91bGQgcmVzcG9uZCB3aXRoIEZMT09SIGluIHRoZSA8aW52 YWxpZD4gbGlzdC4gIE9uIHRoZSBvdGhlciBoYW5kLCBpZiBGTE9PUiB3YXMgbm90IHByZXNlbnQs IGl0IHdvdWxkbid0IGJlIGFuIGVycm9yLg0KUmVjYWxsIHRoYXQgdmFsaWRhdGlvbiBpcyBiZXN0 IGRvbmUgd2hlbiBpbnNlcnRpbmcgbG9jYXRpb24gaW5mb3JtYXRpb24gaW50byBhIExJUzsgd2Vs bCBiZWZvcmUgYW4gZW1lcmdlbmN5IGNhbGwuICBBIGxvY2F0aW9uIHN1aXRhYmxlIGZvciBkaXNw YXRjaCBpcyBhbHNvIHN1aXRhYmxlIGZvciByb3V0aW5nLCBidXQgYSBsb2NhdGlvbiBzdWl0YWJs ZSBmb3Igcm91dGluZyBpcyBub3QgbmVjZXNzYXJpbHkgc3VpdGFibGUgZm9yIGRpc3BhdGNoLg0K DQpJIGRvbid0IHNlZSBhIHByb2JsZW0gaGVyZS4gIEkgdGhpbmsgdGhhdCB0aGUgImFjY2VwdGFi bGUgbG9jYXRpb24gc3lzdGVtIiBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBqdXJpc2RpY3Rpb24gcHJv dmlkaW5nIHRoZSBMb1NUIHNlcnZlciwgYW5kIGlmIGl0IHJlcXVpcmVzIHZhbGlkYXRpb24gdG8g YSBkaXNwYXRjaGFibGUgbG9jYXRpb24sIGl0IGNhbiByZWFzb25hYmx5IHJlcXVpcmUgdGhlIExv U1Qgc2VydmVyIHRvIGRvIHRoYXQgKGJ5IHN1aXRhYmxlIHByb3Zpc2lvbmluZykuICAgLWZyYW1l d29yayBzYXlzIGV4YWN0bHkgdGhlIHJpZ2h0IHRoaW5nLg0KDQpPdmVyIGluIE5FTkEsIHdlIGFy ZSByZXF1aXJpbmcgbG9jYXRpb24gYmUgdmFsaWQgZm9yIGRpc3BhdGNoLCBhbmQgd2UgYXJlIGVx dWlwcGluZyB0aGUgTG9TVCBzZXJ2ZXIgd2l0aCB0aGUgaW5mb3JtYXRpb24gbmVlZGVkIHRvIGRl dGVybWluZSB0aGF0Lg0KDQpCcmlhbg0KDQoNCg== --_000_8B0A9FCBB9832F43971E38010638454F03F33EA91FSISPE7MB1comm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj48IS0tW2lmICFt c29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhh dmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1M KTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5k aWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjAgMTEgNSAwIDAgMCAwIDAgMCAwO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcMDAyN1RpbWVzIE5ldyBSb21hblwwMDI3Ijt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MG1tOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K aDMNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyBD aGFyIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MG1tOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBtbTsNCglmb250LXNpemU6 MTMuNXB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5Nc29M aXN0LCBsaS5Nc29MaXN0LCBkaXYuTXNvTGlzdA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bWFyZ2luLXRvcDowbW07DQoJbWFyZ2luLXJpZ2h0OjBtbTsNCgltYXJnaW4tYm90dG9tOjBtbTsN CgltYXJnaW4tbGVmdDoxNC4xNXB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWlu ZGVudDotMTQuMTVwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBtbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSGVh ZGluZzNDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDMgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyI7DQoJZm9udC1mYW1pbHk6 IkNhbWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6IzRGODFCRDsNCglmb250LXdlaWdodDpib2xkO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAucmVmZXJlbmNl LCBsaS5yZWZlcmVuY2UsIGRpdi5yZWZlcmVuY2UNCgl7bXNvLXN0eWxlLW5hbWU6cmVmZXJlbmNl Ow0KCW1hcmdpbi10b3A6Ni4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBtbTsNCgltYXJnaW4tYm90dG9t OjYuMHB0Ow0KCW1hcmdpbi1sZWZ0OjE0LjE1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE0LjE1cHQ7DQoJ bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzI7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOm5hdnk7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFw cGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NTk1LjNw dCA4NDEuOXB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo4OTE1MDAwMjM7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE3Mjc3MDI4MCAxMzkyNTU1NTYwIDIwMTkxNjQ0 MSAyMDE5MTY0NDMgMjAxOTE2NDMxIDIwMTkxNjQ0MSAyMDE5MTY0NDMgMjAxOTE2NDMxIDIwMTkx NjQ0MSAyMDE5MTY0NDM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdHlsZS1saW5r OnJlZmVyZW5jZTsNCgltc28tbGV2ZWwtdGV4dDoiXFslMVxdIjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MzYuODVwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6MzYuODVwdDsNCgl0ZXh0LWluZGVudDotMTkuMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt dGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBtbTt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBtbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tQVUgbGluaz1i bHVlIHZsaW5rPXB1cnBsZSBzdHlsZT0nd29yZC13cmFwOiBicmVhay13b3JkOy13ZWJraXQtbmJz cC1tb2RlOiBzcGFjZTstd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlJz48ZGl2 IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5JIHRoaW5rIHRoYXQgaXQgbWlnaHQgYmUgcmVhc29uYWJsZSB0byBoYXZlIHRoZSBkZXZp Y2UvZW5kcG9pbnQgZGV0ZXJtaW5lIHdoZXRoZXIgdGhlcmUgaXMgYSByb3V0ZSBvciBub3QgYXMg dGhlIHByaW1hcnkgZ29hbCBvZiBFRC00NCB2YWxpZGF0aW9uLsKgIEFzIGxvbmcgYXMgdGhpcyBp cyBub3QgYSBkZWZhdWx0IHJvdXRlLCB0aGVuIHRoZXJlIGlzIG5vIGNhdXNlIGZvciBwYW5pYy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPkxvU1QgdmFsaWRhdGlvbiBpcyBjb25zdHJhaW5lZCBpbiB3aGF0 IGl0IGNhbiByZXBvcnQgLSBpdOKAmXMgdW5jbGVhciBob3cgYSBMb1NUIHNlcnZlciByZXBvcnRz IHRoYXQgYSBjaXZpYyBhZGRyZXNzIGlzIGludmFsaWQgZHVlIHRvIG1pc3NpbmcgZWxlbWVudHMu wqAgSW4gYWN0dWFsIGZhY3QsIHRoZSB0ZXh0IGlzIHdyaXR0ZW4gaW4gYSB3YXkgdGhhdCB3b3Vs ZCBzZWVtIHRvIGV4Y2x1ZGUgdGhpcyBwb3NzaWJpbGl0eS7CoCBJZiB0aGlzIHdlcmUgcG9zc2li bGUsIGEgcm91Z2ggbG9jYXRpb24gbWlnaHQgYmUgcmVwb3J0ZWQgYnkgdGhlIExvU1Qgc2VydmVy IGFzIGhhdmluZyBpbnZhbGlkIGVsZW1lbnRzICh0aG9zZSB0aGF0IG1pZ2h0IGJlIG5lZWRlZCBm b3IgZGlzcGF0Y2gpLCB0aG91Z2ggYSB2YWx1ZSByb3V0ZSBtaWdodCBzdGlsbCBiZSBwcm92aWRl ZC4gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGF04oCZcyBzb21lIHByZXR0eSBmdXp6eSBzcGVjaWZp Y2F0aW9uLsKgIEkgZG9u4oCZdCB0aGluayB0aGF0IEkgY291bGQgcmVsaWFibHkgaW1wbGVtZW50 IHRoYXQgZ2l2ZW4gd2hhdCBJIGtub3cgYWJvdXQgY2l2aWMgYWRkcmVzc2VzLCBidXQgaXTigJlz IHRoZSBiZXN0IHRoYXQgSSBjb3VsZCBjb21lIHVwIHdpdGggYWZ0ZXIgdGhpbmtpbmcgbW9yZSBh Ym91dCBpdC7CoCBJIHN1c3BlY3QgdGhhdCB0aGlzIGlzIHdoeSBTZWN0aW9uIDguNC4yIG9mIFJG QyA1MjIyIGlzIHdyaXR0ZW4gYXMgaXQgaXMgLSBzdWNoIGZ1enppbmVzcyBpc27igJl0IGNvbmR1 Y2l2ZSB0byBnZXR0aW5nIGludGVyb3BlcmFiaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4oQSBj b25jZXJuIHRoYXQgSSBoYXZlIGhlcmUgaXMgdGhhdCBhIGRldmljZSBkb2VzbuKAmXQgaGF2ZSBh bnkgb3B0aW9uIHRvIHJlbWVkeSBwcm9ibGVtcyB3aXRoIGxvY2F0aW9uIHVubGVzcyB0aGV5IGhh dmUgYWx0ZXJuYXRpdmUgc291cmNlcyBvZiBsb2NhdGlvbi7CoCAtcGhvbmUtYmNwIGRvZXNu4oCZ dCBzcGVjaWZ5IHdoYXQgYSBkZXZpY2UgZG9lcyBpZiBpdCBkaXNjb3ZlcnMgdGhhdCB0aGUgbG9j YXRpb24gaXQgaGFzIGlzIG5vIGdvb2QuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS1NYXJ0aW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMG1tIDBtbSAw bW0nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmVj cml0LWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+V2ludGVyYm90dG9tLCBK YW1lczxicj48Yj5TZW50OjwvYj4gVHVlc2RheSwgMjMgTm92ZW1iZXIgMjAxMCAxMDoxNCBBTTxi cj48Yj5Ubzo8L2I+IEJyaWFuIFJvc2VuOyBFQ1JJVCBPcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJl OiBbRWNyaXRdIFZhbGlkYXRpb24gZm9yIERpc3BhdGNoIGluIExvU1Q8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz5IaSBCcmlhbiw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOm5hdnknPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6bmF2eSc+ SSBhbSBzb3JyeSB0aGF0IGl0IGhhcyB0YWtlbiBzbyBsb25nIHRvIHJlc3BvbmQgdG8gdGhpcywg SSBoYXZlIGJlZW4gYnVzeSB3aXRoIGEgZmV3IG90aGVyIHRoaW5ncy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6bmF2eSc+SSBzdGls bCBoYXZlIGNvbmNlcm5zIHdpdGggeW91ciBwcm9wb3NhbCBoZXJlLiBJIHRoaW5rIGl0IGxpa2Vs eSB0aGF0IHRoZXJlIHdpbGwgYmUgTG9TVCBzZXJ2ZXJzIGJvdGggb24gdGhlIHB1YmxpYyBJbnRl cm5ldCBhbmQgaW4gdGhlIEVTSW5ldHMuIEJvdGggb2YgdGhlc2Ugd2lsbCBiZSByZXF1aXJlZCB0 byBkbyBsb2NhdGlvbiB2YWxpZGF0aW9uLiBMb2NhdGlvbiB2YWxpZGF0aW9uIGluIEVDUklUIGhh cyBhIHByaW1hcnkgZnVuY3Rpb24gb2YgZW5zdXJpbmcgdGhhdCB0aGUgbG9jYXRpb24gd2lsbCBy b3V0ZSB0byBhIFBTQVAuIElmIHdlIHRha2UgeW91ciBhcHByb2FjaCwgdGhhdCBMVkYgbXVzdCBw cm92aWRlIGEgZGlzcGF0Y2ggY2FwYWJsZSBsb2NhdGlvbiB0aGVuIHRoaW5ncyBnZXQgdmVyeSBt dXJreS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y Om5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cHJlPjxzcGFuIHN0eWxlPSdmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz5QaG9uZUJDUCBzYXlzOiDi gJw8L3NwYW4+RUQtNDQgRW5kcG9pbnRzIFNIT1VMRCB2YWxpZGF0ZSBjaXZpYyBsb2NhdGlvbnMg d2hlbiB0aGV5IHJlY2VpdmU8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7Jm5ic3A7IHRoZW0g ZnJvbSB0aGVpciBMQ1AuJm5ic3A7IFZhbGlkYXRpb24gU0hPVUxEIGJlIHBlcmZvcm1lZCBpbiBj b25qdW5jdGlvbjxvOnA+PC9vOnA+PC9wcmU+PHByZT4mbmJzcDsmbmJzcDsgd2l0aCB0aGUgTG9T VCByb3V0ZSBxdWVyeSB0byBtaW5pbWl6ZSBsb2FkIG9uIHRoZSBMb1NUIHNlcnZlci7igJ08bzpw PjwvbzpwPjwvcHJlPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOm5hdnkn PklmIHRoaXMgZ3VpZGFuY2UgaXMgZm9sbG93ZWQsIGFuZCBhIGNvYXJzZSBsb2NhdGlvbiBwcm92 aWRlZCBhcyBpcyBwcm9wb3NlZCBpbiA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQv LWVjcml0LXJvdWdoLWxvYyI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkLy1lY3JpdC1yb3VnaC1s b2M8L2E+IHRoZW4gdGhlIGVuZC1wb2ludCB3aWxsIGdldCBhbiBlcnJvciBzYXlpbmcgdGhhdCB0 aGUgbG9jYXRpb24gaXMgaW52YWxpZC4gQ2xlYXJseSB0aGlzIHdyb25nISA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6bmF2eSc+Q2hl ZXJzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpu YXZ5Jz5KYW1lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6bmF2eSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjpuYXZ5Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOm5hdnknPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MG1tIDBtbSAwbW0gNC4wcHQnPjxkaXY+PGRpdiBjbGFzcz1N c29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4gbGFu Zz1FTi1VUz48aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXI+PC9zcGFuPjwvZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiJz4gZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0 LWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+QnJpYW4gUm9zZW48YnI+PGI+ U2VudDo8L2I+IFRodXJzZGF5LCAxOCBOb3ZlbWJlciAyMDEwIDE6NTcgQU08YnI+PGI+VG86PC9i PiBFQ1JJVCBPcmc8YnI+PGI+U3ViamVjdDo8L2I+IFtFY3JpdF0gVmFsaWRhdGlvbiBmb3IgRGlz cGF0Y2ggaW4gTG9TVDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+SmFtZXMgV2ludGVyYm90dG9t IHBvaW50ZWQgb3V0IHRvIG1lIHRoaXMgdGV4dCBpbiBSRkM1MTAyOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9YXBwbGUt c3R5bGUtc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQSBjYWxsZXIgbG9jYXRp b24gaXMgY29uc2lkZXJlZCB2YWxpZCBpZiB0aGU8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9w PjwvZGl2PjwvZGl2PjxkaXY+PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2l2 aWMgb3IgZ2VvZ3JhcGhpYyBsb2NhdGlvbiBpcyByZWNvZ25pemFibGUgd2l0aGluIGFuIGFjY2Vw dGFibGU8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGxvY2F0aW9uIHJlZmVyZW5jZSBzeXN0ZW0gKGUuZy4sIFVuaXRlZCBTdGF0ZXMgUG9zdGFsIEFk ZHJlc3Mgb3I8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRoZSBXR1MtODQgZGF0dW0pIGFuZCBjYW4gYmUgbWFwcGVkIHRvIG9uZSBvciBtb3JlIFBT QVBzLiA8bzpwPjwvbzpwPjwvcHJlPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7 PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5JbiAtZnJhbWV3b3JrIGl0IHNheXM6PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRp dj48aDM+PGEgbmFtZT1zZWN0aW9uLTYuMTA+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPjYuMTA8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmll ciBOZXciJz4uJm5ic3A7IExvY2F0aW9uIHZhbGlkYXRpb248L3NwYW4+PG86cD48L286cD48L2gz PjxwcmU+Jm5ic3A7Jm5ic3A7IFZhbGlkYXRpb24gaW4gdGhpcyBjb250ZXh0IG1lYW5zIGJvdGgg dGhhdCB0aGVyZSBpcyBhIG1hcHBpbmcgZnJvbTxvOnA+PC9vOnA+PC9wcmU+PHByZT4mbmJzcDsm bmJzcDsgdGhlIGFkZHJlc3MgdG8gYSBQU0FQIGFuZCB0aGF0IHRoZSBQU0FQIHVuZGVyc3RhbmRz IGhvdyB0byBkaXJlY3Q8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7Jm5ic3A7IHJlc3BvbmRl cnMgdG8gdGhlIGxvY2F0aW9uLiZuYnNwOyBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGxvY2F0aW9u IGJlPG86cD48L286cD48L3ByZT48cHJlPiZuYnNwOyZuYnNwOyB2YWxpZGF0ZWQgcHJpb3IgdG8g YSBkZXZpY2UgcGxhY2luZyBhbiBhY3R1YWwgZW1lcmdlbmN5IGNhbGw7IHNvbWU8bzpwPjwvbzpw PjwvcHJlPjxwcmU+Jm5ic3A7Jm5ic3A7IGp1cmlzZGljdGlvbnMgcmVxdWlyZSB0aGF0IHRoaXMg YmUgZG9uZS48bzpwPjwvbzpwPjwvcHJlPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Tm90 aWNlIHRoYXQgdGhlIHNlY29uZCBwYXJ0ICgmcXVvdDthbmQgY2FuIGJlIG1hcHBlZC4uLiZxdW90 OykgaW4gNTAxMiBpcyByZWZlcnJpbmcgdG8gdmFsaWRhdGlvbiBmb3Igcm91dGluZywgd2hlcmUm bmJzcDt0aGUgdGV4dCBpbiAtZnJhbWV3b3JrIGluY2x1ZGVzIHZhbGlkYXRpb24gZm9yIGRpc3Bh dGNoLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlwwMDI3VGlt ZXMgTmV3IFJvbWFuXDAwMjciJz48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj5KYW1l cyBjbGFpbXMgdGhpcyBpcyBhIGNvbmZsaWN0LCB3aGljaCB3aWxsIGxlYWQgdG8gY29uZnVzaW9u LiAmbmJzcDtNeSByZXNwb25zZSBpcyB0aGF0ICZxdW90O3JlY29nbml6YWJsZSB3aXRoaW4gYW4g YWNjZXB0YWJsZSZuYnNwO2xvY2F0aW9uIHJlZmVyZW5jZSBzeXN0ZW0mcXVvdDsgaXMgdGhlIGxv Y2F0aW9uIHJlZmVyZW5jZSBzeXN0ZW0gaW4gdGhlIExvU1Qgc2VydmVyLCB3aGljaCB3aWxsIGJl IHdoYXRldmVyIHRoZSBsb2NhbCBlbWVyZ2VuY3kgYXV0aG9yaXR5J3MgZGVlbSBpcyBuZWVkZWQu ICZuYnNwO0luIG1vc3QgY2FzZXMsIHRoYXQgd291bGQgYmUgdmFsaWQgZm9yIGRpc3BhdGNoLjwv c3Bhbj48YnI+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+SSBnYXZlIEphbWVzIHRo ZSBmb2xsb3dpbmcgZXhhbXBsZXM6PC9zcGFuPjxicj48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1z cGFuPmEpIFRoZXJlIGlzIGEgYnVpbGRpbmcgd2l0aCAyIGZsb29yIHNlcnZlZCBieSBvbmUgUFNB UCwgYW5kIHRoZSByZXN0IHNlcnZlZCBieSBhbm90aGVyLiAmbmJzcDtUaGlzIGhhcHBlbnMuICZu YnNwO1RoZSAyIGZsb29ycyBjb3VsZCBiZSBwYXJ0IG9mIGEgdW5pdmVyc2l0eSB3aGljaCBoYXMg aXQncyBvd24gUFNBUCBhbmQgcmVzcG9uZGVycywgJm5ic3A7b3IgaXQgY291bGQgYmUgcGFydCBv ZiBhIHNlY3VyZSBnb3Zlcm5tZW50IGZhY2lsaXR5IHdoaWNoIGhhcyBhIHNpbWlsYXIgc2l0dWF0 aW9uLiAmbmJzcDtJbiB0aGlzIGNhc2UsIGZvciBhIGNpdmljIGFkZHJlc3MsIEZMT09SIG11c3Qg YmUgcHJlc2VudCwgYW5kIHZhbGlkLCBpbiBvcmRlciB0byByb3V0ZSAoYW5kIHRvIGRpc3BhdGNo KS48L3NwYW4+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+YikgVGhlcmUgaXMgYSBi dWlsZGluZyB3aXRoIGEgbGFyZ2UgbnVtYmVyIG9mIGZsb29ycyBpbiBhIGp1cmlzZGljdGlvbiB3 aGVyZSB0aGVyZSBpcyBhIHJlcXVpcmVtZW50IHRoYXQgbG9jYXRpb24gYmUgcmVwb3J0ZWQgd2l0 aCBGTE9PUiAoYW5kIG9mdGVuIFVOSVQpIGlmIHRoZSBidWlsZGluZyBpcyBvdmVyIGEgY2VydGFp biBzaXplIGxpbWl0LiAmbmJzcDtBZ2FpbiwgRkxPT1Igd291bGQgaGF2ZSB0byBiZSBwcmVzZW50 IGFuZCB2YWxpZCwgZXZlbiB0aG91Z2ggRkxPT1IgaXMgbm90IG5lZWRlZCB0byByb3V0ZS48L3Nw YW4+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+YykgVGhlIExvU1Qgc2VydmVyIG1h eSBoYXZlIEZMT09SIGluZm9ybWF0aW9uLCBidXQgaXQgbWF5IG5vdCBiZSBhIHJlcXVpcmVkIGVs ZW1lbnQuICZuYnNwO0lmIHRoZSBsb2NhdGlvbiBzZW50IGluIHRoZSBMb1NUIHJlcXVlc3QgY29u dGFpbmVkIEZMT09SLCBidXQgdGhlIHZhbHVlIHdhcyBub3QgaW4gdGhlIHJpZ2h0IHJhbmdlLCB0 aGUgTG9TVCBzZXJ2ZXIgc2hvdWxkIHJlc3BvbmQgd2l0aCBGTE9PUiBpbiB0aGUgJmx0O2ludmFs aWQmZ3Q7IGxpc3QuICZuYnNwO09uIHRoZSBvdGhlciBoYW5kLCBpZiBGTE9PUiB3YXMgbm90IHBy ZXNlbnQsIGl0IHdvdWxkbid0IGJlIGFuIGVycm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48 L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlwwMDI3VGltZXMgTmV3IFJvbWFuXDAwMjciJz5SZWNh bGwgdGhhdCB2YWxpZGF0aW9uIGlzIGJlc3QgZG9uZSB3aGVuIGluc2VydGluZyBsb2NhdGlvbiBp bmZvcm1hdGlvbiBpbnRvIGEgTElTOyB3ZWxsIGJlZm9yZSBhbiBlbWVyZ2VuY3kgY2FsbC4gJm5i c3A7QSBsb2NhdGlvbiBzdWl0YWJsZSBmb3IgZGlzcGF0Y2ggaXMgYWxzbyBzdWl0YWJsZSBmb3Ig cm91dGluZywgYnV0IGEgbG9jYXRpb24gc3VpdGFibGUgZm9yIHJvdXRpbmcgaXMgbm90IG5lY2Vz c2FyaWx5IHN1aXRhYmxlIGZvciBkaXNwYXRjaC4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlm Iic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5z LXNlcmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWls eToiXDAwMjdUaW1lcyBOZXcgUm9tYW5cMDAyNyInPkkgZG9uJ3Qgc2VlIGEgcHJvYmxlbSBoZXJl LiAmbmJzcDtJIHRoaW5rIHRoYXQgdGhlICZxdW90O2FjY2VwdGFibGUgbG9jYXRpb24gc3lzdGVt JnF1b3Q7IGlzIGRldGVybWluZWQgYnkgdGhlIGp1cmlzZGljdGlvbiBwcm92aWRpbmcgdGhlIExv U1Qgc2VydmVyLCBhbmQgaWYgaXQgcmVxdWlyZXMgdmFsaWRhdGlvbiB0byBhIGRpc3BhdGNoYWJs ZSBsb2NhdGlvbiwgaXQgY2FuIHJlYXNvbmFibHkgcmVxdWlyZSB0aGUgTG9TVCBzZXJ2ZXIgdG8g ZG8gdGhhdCAoYnkgc3VpdGFibGUgcHJvdmlzaW9uaW5nKS4gJm5ic3A7PC9zcGFuPiZuYnNwOy1m cmFtZXdvcmsgc2F5cyBleGFjdGx5IHRoZSByaWdodCB0aGluZy48L3NwYW4+PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj5P dmVyIGluIE5FTkEsIHdlIGFyZSByZXF1aXJpbmcgbG9jYXRpb24gYmUgdmFsaWQgZm9yIGRpc3Bh dGNoLCBhbmQgd2UgYXJlIGVxdWlwcGluZyB0aGUgTG9TVCBzZXJ2ZXIgd2l0aCB0aGUgaW5mb3Jt YXRpb24gbmVlZGVkIHRvIGRldGVybWluZSB0aGF0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiXDAwMjdUaW1lcyBOZXcgUm9tYW5cMDAyNyInPkJyaWFuPC9zcGFu Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_8B0A9FCBB9832F43971E38010638454F03F33EA91FSISPE7MB1comm_-- From br@brianrosen.net Mon Nov 22 16:34:57 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E91D93A6B02 for ; Mon, 22 Nov 2010 16:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.99 X-Spam-Level: X-Spam-Status: No, score=-102.99 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhAlJUsX0vvg for ; Mon, 22 Nov 2010 16:34:51 -0800 (PST) Received: from barmail2.idig.net (barmail2.idig.net [64.34.111.252]) by core3.amsl.com (Postfix) with ESMTP id 4FC653A6AB6 for ; Mon, 22 Nov 2010 16:34:50 -0800 (PST) X-ASG-Debug-ID: 1290472545-1a1fc7290001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail2.idig.net with ESMTP id gs9soqYdj5BD3kAu; Mon, 22 Nov 2010 16:35:45 -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.54]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PKgrB-0003Cj-Bh; Mon, 22 Nov 2010 16:35:45 -0800 Mime-Version: 1.0 (Apple Message framework v1081) X-ASG-Orig-Subj: Re: [Ecrit] Validation for Dispatch in LoST Content-Type: multipart/alternative; boundary=Apple-Mail-72-780199100 From: Brian Rosen In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120F234D209@SISPE7MB1.commscope.com> Date: Mon, 22 Nov 2010 19:35:27 -0500 Message-Id: <4DC5B8DD-6011-4EDD-B4E9-4F038A1B3202@brianrosen.net> References: <66485071-F496-4D33-A133-CA751A80B4A4@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC81880120F234D209@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1081) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1290472545 X-Barracuda-URL: http://64.34.111.252:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.73 X-Barracuda-Spam-Status: No, SCORE=0.73 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332, HTML_FONT_FACE_BAD, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.47407 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 0.00 HTML_MESSAGE BODY: HTML included in message 0.61 HTML_FONT_FACE_BAD BODY: HTML font face is not a word Cc: ECRIT Org Subject: Re: [Ecrit] Validation for Dispatch in LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 00:34:57 -0000 --Apple-Mail-72-780199100 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think we are likely to need this in NENA. It is essential that the = North American 9-1-1 system have a location valid for dispatch. That is = the function of the current "MSAG" validation. This validation has to = happen on the public servers. I believe any system needs this. You = must be able to dispatch a responder with the address that is supplied. = Having some entirely separate validation for dispatch is silly, in my = opinion. The validation that we really need is when a location is entered into = the LIS. This won't be rough - the entity that operates the LIS has the = actual location. The phonebcp validation for rough may indeed fail. It depends on how = it's implemented. It certainly could be something that is valid, but it = doesn't have to be. I don't think that is a problem. Brian On Nov 22, 2010, at 6:13 PM, Winterbottom, James wrote: > Hi Brian, > =20 > I am sorry that it has taken so long to respond to this, I have been = busy with a few other things. > =20 > I still have concerns with your proposal here. I think it likely that = there will be LoST servers both on the public Internet and in the = ESInets. Both of these will be required to do location validation. = Location validation in ECRIT has a primary function of ensuring that the = location will route to a PSAP. If we take your approach, that LVF must = provide a dispatch capable location then things get very murky. > =20 > PhoneBCP says: =93ED-44 Endpoints SHOULD validate civic locations when = they receive > them from their LCP. Validation SHOULD be performed in conjunction > with the LoST route query to minimize load on the LoST server.=94 > =20 > If this guidance is followed, and a coarse location provided as is = proposed in http://tools.ietf.org/id/-ecrit-rough-loc then the end-point = will get an error saying that the location is invalid. Clearly this = wrong! > =20 > Cheers > James > =20 > =20 > =20 > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Brian Rosen > Sent: Thursday, 18 November 2010 1:57 AM > To: ECRIT Org > Subject: [Ecrit] Validation for Dispatch in LoST > =20 > James Winterbottom pointed out to me this text in RFC5102: > A caller location is considered valid if the > civic or geographic location is recognizable within an = acceptable > location reference system (e.g., United States Postal Address or > the WGS-84 datum) and can be mapped to one or more PSAPs.=20 > =20 > In -framework it says: > 6.10. Location validation >=20 > Validation in this context means both that there is a mapping from > the address to a PSAP and that the PSAP understands how to direct > responders to the location. It is recommended that location be > validated prior to a device placing an actual emergency call; some > jurisdictions require that this be done. > Notice that the second part ("and can be mapped...") in 5012 is = referring to validation for routing, where the text in -framework = includes validation for dispatch. =20 >=20 > James claims this is a conflict, which will lead to confusion. My = response is that "recognizable within an acceptable location reference = system" is the location reference system in the LoST server, which will = be whatever the local emergency authority's deem is needed. In most = cases, that would be valid for dispatch. >=20 > I gave James the following examples: > a) There is a building with 2 floor served by one PSAP, and the rest = served by another. This happens. The 2 floors could be part of a = university which has it's own PSAP and responders, or it could be part = of a secure government facility which has a similar situation. In this = case, for a civic address, FLOOR must be present, and valid, in order to = route (and to dispatch). > b) There is a building with a large number of floors in a jurisdiction = where there is a requirement that location be reported with FLOOR (and = often UNIT) if the building is over a certain size limit. Again, FLOOR = would have to be present and valid, even though FLOOR is not needed to = route. > c) The LoST server may have FLOOR information, but it may not be a = required element. If the location sent in the LoST request contained = FLOOR, but the value was not in the right range, the LoST server should = respond with FLOOR in the list. On the other hand, if FLOOR = was not present, it wouldn't be an error. >=20 > Recall that validation is best done when inserting location = information into a LIS; well before an emergency call. A location = suitable for dispatch is also suitable for routing, but a location = suitable for routing is not necessarily suitable for dispatch.=20 > =20 > I don't see a problem here. I think that the "acceptable location = system" is determined by the jurisdiction providing the LoST server, and = if it requires validation to a dispatchable location, it can reasonably = require the LoST server to do that (by suitable provisioning). = -framework says exactly the right thing. > =20 > Over in NENA, we are requiring location be valid for dispatch, and we = are equipping the LoST server with the information needed to determine = that. > =20 > Brian > =20 > =20 --Apple-Mail-72-780199100 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = think we are likely to need this in NENA.  It is essential that the = North American 9-1-1 system have a location valid for dispatch. =  That is the function of the current "MSAG" validation.  This = validation has to happen on the public servers.  I believe any = system needs this.  You must be able to dispatch a responder with = the address that is supplied.  Having some entirely separate = validation for dispatch is silly, in my opinion.

The = validation that we really need is when a location is entered into the = LIS.  This won't be rough - the entity that operates the LIS has = the actual location.

The phonebcp validation = for rough may indeed fail.   It depends on how it's implemented. =  It certainly could be something that is valid, but it doesn't have = to be.  I don't think that is a = problem.

Brian

On Nov 22, 2010, at 6:13 PM, Winterbottom, James wrote:

Hi = Brian,

 

I am sorry that it has taken so = long to respond to this, I have been busy with a few other = things.

 

I still have concerns with your = proposal here. I think it likely that there will be LoST servers both on the = public Internet and in the ESInets. Both of these will be required to do = location validation. Location validation in ECRIT has a primary function of = ensuring that the location will route to a PSAP. If we take your approach, that = LVF must provide a dispatch capable location then things get very = murky.

 

PhoneBCP says: =93ED-44 =
Endpoints SHOULD validate civic locations when they =
receive
   them from their LCP.  =
Validation SHOULD be performed in =
conjunction
   with =
the LoST route query to minimize load on the LoST =
server.=94

 

If this guidance is followed, and a = coarse location provided as is proposed in http://tools.ietf.org/i= d/-ecrit-rough-loc then the end-point will get an error saying that the location is = invalid. Clearly this wrong!

 

Cheers

James

 

 

 

From: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Thursday, 18 = November 2010 1:57 AM
To: ECRIT Org
Subject: [Ecrit] = Validation for Dispatch in LoST

 

James Winterbottom pointed out to me this text in = RFC5102:

      A caller location is considered valid if = the

      civic or =
geographic location is recognizable within an =
acceptable
      location =
reference system (e.g., United States Postal Address =
or
      the WGS-84 =
datum) and can be mapped to one or more PSAPs. =

 

In -framework it says:

6.10.  Location validation

   Validation in this context means =
both that there is a mapping =
from
   the =
address to a PSAP and that the PSAP understands how to =
direct
   =
responders to the location.  It is recommended that location =
be
   =
validated prior to a device placing an actual emergency call; =
some
   =
jurisdictions require that this be =
done.

Notice that the second part ("and can be mapped...") in 5012 is referring to validation for routing, where the text in = -framework includes validation for dispatch.  


James claims this is a conflict, which = will lead to confusion.  My response is that "recognizable within an = acceptable location reference system" is the location reference system in the LoST server, which will be whatever the local emergency authority's deem is needed. =  In most cases, that would be valid for dispatch.

I gave James the following = examples:
a) There is a building with 2 floor = served by one PSAP, and the rest served by another.  This happens.  The 2 = floors could be part of a university which has it's own PSAP and responders, =  or it could be part of a secure government facility which has a similar = situation.  In this case, for a civic address, FLOOR must be present, and = valid, in order to route (and to dispatch).
b) There is a building with a large = number of floors in a jurisdiction where there is a requirement that location be = reported with FLOOR (and often UNIT) if the building is over a certain size = limit.  Again, FLOOR would have to be present and valid, even though FLOOR is not = needed to route.
c) The LoST server may have FLOOR = information, but it may not be a required element.  If the location sent in the LoST request contained FLOOR, but the value was not in the right range, the = LoST server should respond with FLOOR in the <invalid> list.  On = the other hand, if FLOOR was not present, it wouldn't be an = error.

Recall that validation is best done when inserting location information into a = LIS; well before an emergency call.  A location suitable for dispatch is = also suitable for routing, but a location suitable for routing is not = necessarily suitable for dispatch. =

 

I don't see a problem here.  I think that the "acceptable location system" is determined by the jurisdiction providing the LoST server, and if it requires validation to a dispatchable location, it can reasonably = require the LoST server to do that (by suitable provisioning). =   -framework says exactly the right thing.

 

Over = in NENA, we are requiring location be valid for dispatch, and we are equipping the LoST = server with the information needed to determine = that.

 

Brian

 

 


= --Apple-Mail-72-780199100-- From br@brianrosen.net Mon Nov 22 16:40:17 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 842463A6AB6 for ; Mon, 22 Nov 2010 16:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.404 X-Spam-Level: X-Spam-Status: No, score=-103.404 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nagfEgnDhm7R for ; Mon, 22 Nov 2010 16:40:15 -0800 (PST) Received: from barmail2.idig.net (barmail2.idig.net [64.34.111.252]) by core3.amsl.com (Postfix) with ESMTP id D451428C17C for ; Mon, 22 Nov 2010 16:40:08 -0800 (PST) X-ASG-Debug-ID: 1290472864-1a22c7060001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail2.idig.net with ESMTP id lMZofQ8BjJrZWgey; Mon, 22 Nov 2010 16:41:04 -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.54]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PKgwI-0006Sb-23; Mon, 22 Nov 2010 16:41:02 -0800 Mime-Version: 1.0 (Apple Message framework v1081) X-ASG-Orig-Subj: Re: [Ecrit] Validation for Dispatch in LoST Content-Type: multipart/alternative; boundary=Apple-Mail-73-780516863 From: Brian Rosen In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F33EA91F@SISPE7MB1.commscope.com> Date: Mon, 22 Nov 2010 19:40:45 -0500 Message-Id: References: <66485071-F496-4D33-A133-CA751A80B4A4@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC81880120F234D209@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03F33EA91F@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1081) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1290472864 X-Barracuda-URL: http://64.34.111.252:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net 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, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.47409 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 0.00 HTML_MESSAGE BODY: HTML included in message Cc: ECRIT Org Subject: Re: [Ecrit] Validation for Dispatch in LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 00:40:17 -0000 --Apple-Mail-73-780516863 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have asked on this list if the list can contain an element = not in the original input. The conclusion of that discussion was that = it could. Brian On Nov 22, 2010, at 6:29 PM, Thomson, Martin wrote: > I think that it might be reasonable to have the device/endpoint = determine whether there is a route or not as the primary goal of ED-44 = validation. As long as this is not a default route, then there is no = cause for panic. > =20 > LoST validation is constrained in what it can report - it=92s unclear = how a LoST server reports that a civic address is invalid due to missing = elements. In actual fact, the text is written in a way that would seem = to exclude this possibility. If this were possible, a rough location = might be reported by the LoST server as having invalid elements (those = that might be needed for dispatch), though a value route might still be = provided. > =20 > That=92s some pretty fuzzy specification. I don=92t think that I = could reliably implement that given what I know about civic addresses, = but it=92s the best that I could come up with after thinking more about = it. I suspect that this is why Section 8.4.2 of RFC 5222 is written as = it is - such fuzziness isn=92t conducive to getting interoperability. > =20 > (A concern that I have here is that a device doesn=92t have any option = to remedy problems with location unless they have alternative sources of = location. -phone-bcp doesn=92t specify what a device does if it = discovers that the location it has is no good.) > =20 > --Martin > =20 > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Winterbottom, James > Sent: Tuesday, 23 November 2010 10:14 AM > To: Brian Rosen; ECRIT Org > Subject: Re: [Ecrit] Validation for Dispatch in LoST > =20 > Hi Brian, > =20 > I am sorry that it has taken so long to respond to this, I have been = busy with a few other things. > =20 > I still have concerns with your proposal here. I think it likely that = there will be LoST servers both on the public Internet and in the = ESInets. Both of these will be required to do location validation. = Location validation in ECRIT has a primary function of ensuring that the = location will route to a PSAP. If we take your approach, that LVF must = provide a dispatch capable location then things get very murky. > =20 > PhoneBCP says: =93ED-44 Endpoints SHOULD validate civic locations when = they receive > them from their LCP. Validation SHOULD be performed in conjunction > with the LoST route query to minimize load on the LoST server.=94 > =20 > If this guidance is followed, and a coarse location provided as is = proposed in http://tools.ietf.org/id/-ecrit-rough-loc then the end-point = will get an error saying that the location is invalid. Clearly this = wrong! > =20 > Cheers > James > =20 > =20 > =20 > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Brian Rosen > Sent: Thursday, 18 November 2010 1:57 AM > To: ECRIT Org > Subject: [Ecrit] Validation for Dispatch in LoST > =20 > James Winterbottom pointed out to me this text in RFC5102: > A caller location is considered valid if the > civic or geographic location is recognizable within an = acceptable > location reference system (e.g., United States Postal Address or > the WGS-84 datum) and can be mapped to one or more PSAPs.=20 > =20 > In -framework it says: > 6.10. Location validation >=20 > Validation in this context means both that there is a mapping from > the address to a PSAP and that the PSAP understands how to direct > responders to the location. It is recommended that location be > validated prior to a device placing an actual emergency call; some > jurisdictions require that this be done. > Notice that the second part ("and can be mapped...") in 5012 is = referring to validation for routing, where the text in -framework = includes validation for dispatch. =20 >=20 > James claims this is a conflict, which will lead to confusion. My = response is that "recognizable within an acceptable location reference = system" is the location reference system in the LoST server, which will = be whatever the local emergency authority's deem is needed. In most = cases, that would be valid for dispatch. >=20 > I gave James the following examples: > a) There is a building with 2 floor served by one PSAP, and the rest = served by another. This happens. The 2 floors could be part of a = university which has it's own PSAP and responders, or it could be part = of a secure government facility which has a similar situation. In this = case, for a civic address, FLOOR must be present, and valid, in order to = route (and to dispatch). > b) There is a building with a large number of floors in a jurisdiction = where there is a requirement that location be reported with FLOOR (and = often UNIT) if the building is over a certain size limit. Again, FLOOR = would have to be present and valid, even though FLOOR is not needed to = route. > c) The LoST server may have FLOOR information, but it may not be a = required element. If the location sent in the LoST request contained = FLOOR, but the value was not in the right range, the LoST server should = respond with FLOOR in the list. On the other hand, if FLOOR = was not present, it wouldn't be an error. >=20 > Recall that validation is best done when inserting location = information into a LIS; well before an emergency call. A location = suitable for dispatch is also suitable for routing, but a location = suitable for routing is not necessarily suitable for dispatch.=20 > =20 > I don't see a problem here. I think that the "acceptable location = system" is determined by the jurisdiction providing the LoST server, and = if it requires validation to a dispatchable location, it can reasonably = require the LoST server to do that (by suitable provisioning). = -framework says exactly the right thing. > =20 > Over in NENA, we are requiring location be valid for dispatch, and we = are equipping the LoST server with the information needed to determine = that. > =20 > Brian > =20 > =20 --Apple-Mail-73-780516863 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I have asked on this list if the <invalid> = list can contain an element not in the original input.  The = conclusion of that discussion was that it = could.

Brian

On Nov 22, 2010, = at 6:29 PM, Thomson, Martin wrote:

I think that it might be = reasonable to have the device/endpoint determine whether there is a = route or not as the primary goal of ED-44 validation.  As long as = this is not a default route, then there is no cause for = panic.
LoST = validation is constrained in what it can report - it=92s unclear how a = LoST server reports that a civic address is invalid due to missing = elements.  In actual fact, the text is written in a way that would = seem to exclude this possibility.  If this were possible, a rough = location might be reported by the LoST server as having invalid elements = (those that might be needed for dispatch), though a value route might = still be provided.
(A = concern that I have here is that a device doesn=92t have any option to = remedy problems with location unless they have alternative sources of = location.  -phone-bcp doesn=92t specify what a device does if it = discovers that the location it has is no = good.)
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.or= g] On Behalf = Of Winterbottom, = James
Sent: Tuesday, 23 November 2010 = 10:14 AM
To: Brian Rosen; ECRIT = Org
Subject: Re: [Ecrit] Validation for = Dispatch in LoST
 
Hi = Brian,
I am sorry that it = has taken so long to respond to this, I have been busy with a few other = things.
I still have = concerns with your proposal here. I think it likely that there will be = LoST servers both on the public Internet and in the ESInets. Both of = these will be required to do location validation. Location validation in = ECRIT has a primary function of ensuring that the location will route to = a PSAP. If we take your approach, that LVF must provide a dispatch = capable location then things get very murky.
 
PhoneBCP says: =93ED-44 =
Endpoints SHOULD validate civic locations when they =
receive
   them from their LCP.  =
Validation SHOULD be performed in conjunction
If this guidance is =
followed, and a coarse location provided as is proposed in  then the end-point will get =
an error saying that the location is invalid. Clearly this =
wrong!
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.or= g] On Behalf = Of Brian = Rosen
Sent: Thursday, 18 November 2010 = 1:57 AM
To: ECRIT = Org
Subject: [Ecrit] Validation for = Dispatch in LoST
James Winterbottom pointed out to me this = text in RFC5102:
      A = caller location is considered valid if = the
      the =
WGS-84 datum) and can be mapped to one or more PSAPs. =
In -framework it says:

6.10.  Location = validation

   Validation in this =
context means both that there is a mapping from
   responders to the =
location.  It is recommended that location be
   jurisdictions require that =
this be done.
Notice that the second = part ("and can be mapped...") in 5012 is referring to validation for = routing, where the text in -framework includes validation for = dispatch.  


James claims this is a conflict, which will = lead to confusion.  My response is that "recognizable within an = acceptable location reference system" is the location reference = system in the LoST server, which will be whatever the local emergency = authority's deem is needed.  In most cases, that would be valid for = dispatch.

I gave James = the following examples:
a) = There is a building with 2 floor served by one PSAP, and the rest served = by another.  This happens.  The 2 floors could be part of a = university which has it's own PSAP and responders,  or it could be = part of a secure government facility which has a similar situation. =  In this case, for a civic address, FLOOR must be present, and = valid, in order to route (and to dispatch).
b) There is a building with a large number of = floors in a jurisdiction where there is a requirement that location be = reported with FLOOR (and often UNIT) if the building is over a certain = size limit.  Again, FLOOR would have to be present and valid, even = though FLOOR is not needed to route.
c) The LoST server may have FLOOR = information, but it may not be a required element.  If the location = sent in the LoST request contained FLOOR, but the value was not in the = right range, the LoST server should respond with FLOOR in the = <invalid> list.  On the other hand, if FLOOR was not present, = it wouldn't be an error.

Recall that validation is best done when = inserting location information into a LIS; well before an emergency = call.  A location suitable for dispatch is also suitable for = routing, but a location suitable for routing is not necessarily suitable = for dispatch. I don't see a problem here.  I think that the = "acceptable location system" is determined by the jurisdiction providing = the LoST server, and if it requires validation to a dispatchable = location, it can reasonably require the LoST server to do that (by = suitable provisioning).   -framework says exactly the = right thing.
Over in NENA, we are requiring location be = valid for dispatch, and we are equipping the LoST server with the = information needed to determine = that.
Brian
 
); Mon, 22 Nov 2010 18:41:42 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 22 Nov 2010 18:41:42 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 23 Nov 2010 08:41:38 +0800 From: "Winterbottom, James" To: Brian Rosen Date: Tue, 23 Nov 2010 08:41:36 +0800 Thread-Topic: [Ecrit] Validation for Dispatch in LoST Thread-Index: AcuKpmE0+CsWYv9/R7yCIPZRE6G7RwAAJd6w Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120F234D232@SISPE7MB1.commscope.com> References: <66485071-F496-4D33-A133-CA751A80B4A4@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC81880120F234D209@SISPE7MB1.commscope.com> <4DC5B8DD-6011-4EDD-B4E9-4F038A1B3202@brianrosen.net> In-Reply-To: <4DC5B8DD-6011-4EDD-B4E9-4F038A1B3202@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC81880120F234D232SISPE7MB1co_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: ECRIT Org Subject: Re: [Ecrit] Validation for Dispatch in LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 00:40:55 -0000 --_000_5A55A45AE77F5941B18E5457ECAC81880120F234D232SISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think this essentially leads to don't do location hiding in the US and Ca= nada because if you do you can't follow the guidance in phoneBCP. Personally I think that this is a problem, and simply saying let it fail is= n't a good option. ________________________________ From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, 23 November 2010 11:35 AM To: Winterbottom, James Cc: ECRIT Org Subject: Re: [Ecrit] Validation for Dispatch in LoST I think we are likely to need this in NENA. It is essential that the North= American 9-1-1 system have a location valid for dispatch. That is the fun= ction of the current "MSAG" validation. This validation has to happen on t= he public servers. I believe any system needs this. You must be able to d= ispatch a responder with the address that is supplied. Having some entirel= y separate validation for dispatch is silly, in my opinion. The validation that we really need is when a location is entered into the L= IS. This won't be rough - the entity that operates the LIS has the actual = location. The phonebcp validation for rough may indeed fail. It depends on how it's= implemented. It certainly could be something that is valid, but it doesn'= t have to be. I don't think that is a problem. Brian On Nov 22, 2010, at 6:13 PM, Winterbottom, James wrote: Hi Brian, I am sorry that it has taken so long to respond to this, I have been busy w= ith a few other things. I still have concerns with your proposal here. I think it likely that there= will be LoST servers both on the public Internet and in the ESInets. Both = of these will be required to do location validation. Location validation in= ECRIT has a primary function of ensuring that the location will route to a= PSAP. If we take your approach, that LVF must provide a dispatch capable l= ocation then things get very murky. PhoneBCP says: "ED-44 Endpoints SHOULD validate civic locations when they r= eceive them from their LCP. Validation SHOULD be performed in conjunction with the LoST route query to minimize load on the LoST server." If this guidance is followed, and a coarse location provided as is proposed= in http://tools.ietf.org/id/-ecrit-rough-loc then the end-point will get a= n error saying that the location is invalid. Clearly this wrong! Cheers James ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounce= s@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, 18 November 2010 1:57 AM To: ECRIT Org Subject: [Ecrit] Validation for Dispatch in LoST James Winterbottom pointed out to me this text in RFC5102: A caller location is considered valid if the civic or geographic location is recognizable within an acceptable location reference system (e.g., United States Postal Address or the WGS-84 datum) and can be mapped to one or more PSAPs. In -framework it says: 6.10. Location validation Validation in this context means both that there is a mapping from the address to a PSAP and that the PSAP understands how to direct responders to the location. It is recommended that location be validated prior to a device placing an actual emergency call; some jurisdictions require that this be done. Notice that the second part ("and can be mapped...") in 5012 is referring t= o validation for routing, where the text in -framework includes validation = for dispatch. James claims this is a conflict, which will lead to confusion. My response= is that "recognizable within an acceptable location reference system" is t= he location reference system in the LoST server, which will be whatever the= local emergency authority's deem is needed. In most cases, that would be = valid for dispatch. I gave James the following examples: a) There is a building with 2 floor served by one PSAP, and the rest served= by another. This happens. The 2 floors could be part of a university whi= ch has it's own PSAP and responders, or it could be part of a secure gover= nment facility which has a similar situation. In this case, for a civic ad= dress, FLOOR must be present, and valid, in order to route (and to dispatch= ). b) There is a building with a large number of floors in a jurisdiction wher= e there is a requirement that location be reported with FLOOR (and often UN= IT) if the building is over a certain size limit. Again, FLOOR would have = to be present and valid, even though FLOOR is not needed to route. c) The LoST server may have FLOOR information, but it may not be a required= element. If the location sent in the LoST request contained FLOOR, but th= e value was not in the right range, the LoST server should respond with FLO= OR in the list. On the other hand, if FLOOR was not present, it = wouldn't be an error. Recall that validation is best done when inserting location information int= o a LIS; well before an emergency call. A location suitable for dispatch i= s also suitable for routing, but a location suitable for routing is not nec= essarily suitable for dispatch. I don't see a problem here. I think that the "acceptable location system" = is determined by the jurisdiction providing the LoST server, and if it requ= ires validation to a dispatchable location, it can reasonably require the L= oST server to do that (by suitable provisioning). -framework says exactly= the right thing. Over in NENA, we are requiring location be valid for dispatch, and we are e= quipping the LoST server with the information needed to determine that. Brian --_000_5A55A45AE77F5941B18E5457ECAC81880120F234D232SISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think this essentially leads to don&= #8217;t do location hiding in the US and Canada because if you do you can’t follow the guidance in phoneBCP.

Personally I think that this is a prob= lem, and simply saying let it fail isn’t a good option.<= /font>

 

 

<= span style=3D'font-size:12.0pt;color:navy'> 

From:= Brian Rosen [mailto:br@brianrosen.net]
Sent: Tuesday, 23 November 2= 010 11:35 AM
To: Winterbottom, James
Cc: ECRIT Org
Subject: Re: [Ecrit] Validat= ion for Dispatch in LoST

 

I think we are likely to need this in NENA.  It is essential t= hat the North American 9-1-1 system have a location valid for dispatch.  T= hat is the function of the current "MSAG" validation.  This validation has to happen on the public servers.  I believe any system needs this.  You must be able to dispatch a responder with the address that is supplied.  Having some entirely separate validation for dispat= ch is silly, in my opinion.

 

The validation that we really need is when a location is entered in= to the LIS.  This won't be rough - the entity that operates the LIS has t= he actual location.

 

The phonebcp validation for rough may indeed fail.   It depend= s on how it's implemented.  It certainly could be something that is valid, = but it doesn't have to be.  I don't think that is a problem.

 

Brian

 

On Nov 22, 2010, at 6:13 PM, Winterbott= om, James wrote:



Hi Brian,

 =

I am sorry that it has taken so long t= o respond to this, I have been busy with a few other things.

 =

I still have concerns with your propos= al here. I think it likely that there will be LoST servers both on the public Internet and in the ESInets. Both of these will be required to do location validation. Location validation in ECRIT has a primary function of ensuring that the location will route to a PSAP. If we take your approach, that LVF = must provide a dispatch capable location then things get very murky.

 = 

PhoneBCP says: “ED-44 End=
points SHOULD validate civic locations when they receive<=
/o:p>
  =
 them from their LCP.  Validation SHOULD be performed in conjunction
  =
 with the LoST route query to minimize load on the LoST server.”

 =

If this guidance is followed, and a co= arse location provided as is proposed in http://tools.ietf.org/id= /-ecrit-rough-loc then the end-point will get an error saying that the location is invalid. Clearly this wrong!

 =

Cheers=

James<= /o:p>

 =

 =

<= span style=3D'font-size:12.0pt;color:navy'> 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Thursday, 18 November = 2010 1:57 AM
To: ECRIT Org
Subject: [Ecrit] Validation = for Dispatch in LoST

 

James Winterbotto= m pointed out to me this text in RFC5102:

   &nbs= p;  A caller location is considered valid if the

      civic or geographic location is recogniz=
able within an acceptable
  =
    location reference system (e.g., United States Postal Ad=
dress or
  =
    the WGS-84 datum) and can be mapped to one or more PSAPs=
.

 

In -framework it says:

6.10= .  Loca= tion validation

&=
nbsp;  Validation in this context means both that there is a mapping f=
rom
  =
 the address to a PSAP and that the PSAP understands how to direct
  =
 responders to the location.  It is recommended that location be=

  =
 validated prior to a device placing an actual emergency call; some
  =
 jurisdictions require that this be done.

Notice that the second part ("and can be mapped...") in 5= 012 is referring to validation for routing, where the text in -framework includes validation for dispatch.  


James claims this is a conflict, which will = lead to confusion.  My response is that "recognizable within an accept= able location reference system" is the location reference system in the LoST server, which will be whatever the local emergency authority's deem is needed. &nbs= p;In most cases, that would be valid for dispatch.

I gave James the following examples:<= br> a) There is a building with 2 floor served b= y one PSAP, and the rest served by another.  This happens.  The 2 floor= s could be part of a university which has it's own PSAP and responders,  = ;or it could be part of a secure government facility which has a similar situat= ion.  In this case, for a civic address, FLOOR must be present, and valid, = in order to route (and to dispatch).
b) There is a building with a large number o= f floors in a jurisdiction where there is a requirement that location be repo= rted with FLOOR (and often UNIT) if the building is over a certain size limit. &= nbsp;Again, FLOOR would have to be present and valid, even though FLOOR is not needed t= o route.
c) The LoST server may have FLOOR informatio= n, but it may not be a required element.  If the location sent in the LoST request contained FLOOR, but the value was not in the right range, the LoST server should respond with FLOOR in the <invalid> list.  On the other hand, if FLOOR was not present, it wouldn't be an error.=

Recall that validation is best done when inserting location information into a LIS= ; well before an emergency call.  A location suitable for dispatch is al= so suitable for routing, but a location suitable for routing is not necessaril= y suitable for dispatch. 

 

I don't see a problem here.  I think that the "acceptable location system" is determined by the jurisdiction providing the LoST server, a= nd if it requires validation to a dispatchable location, it can reasonably req= uire the LoST server to do that (by suitable provisioning).  =  -framework says exactly the right thing.

 

Over in NENA, we = are requiring location be valid for dispatch, and we are equipping the LoST ser= ver with the information needed to determine that.

 

Brian=

 

 

 

--_000_5A55A45AE77F5941B18E5457ECAC81880120F234D232SISPE7MB1co_-- From br@brianrosen.net Mon Nov 22 16:43:35 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965DD3A6B05 for ; Mon, 22 Nov 2010 16:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.98 X-Spam-Level: X-Spam-Status: No, score=-102.98 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCN-65q1BNcd for ; Mon, 22 Nov 2010 16:43:33 -0800 (PST) Received: from barmail2.idig.net (barmail2.idig.net [64.34.111.252]) by core3.amsl.com (Postfix) with ESMTP id B203B3A6B02 for ; Mon, 22 Nov 2010 16:43:33 -0800 (PST) X-ASG-Debug-ID: 1290473069-1a23c8180001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail2.idig.net with ESMTP id A51h9rtupJ4YUArw; Mon, 22 Nov 2010 16:44:29 -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.54]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PKgzc-00087q-3G; Mon, 22 Nov 2010 16:44:28 -0800 Mime-Version: 1.0 (Apple Message framework v1081) X-ASG-Orig-Subj: Re: [Ecrit] Validation for Dispatch in LoST Content-Type: multipart/alternative; boundary=Apple-Mail-74-780721990 From: Brian Rosen In-Reply-To: <4DC5B8DD-6011-4EDD-B4E9-4F038A1B3202@brianrosen.net> Date: Mon, 22 Nov 2010 19:44:10 -0500 Message-Id: <8A57560B-B453-47A0-BFD0-59D1C93FA0B4@brianrosen.net> References: <66485071-F496-4D33-A133-CA751A80B4A4@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC81880120F234D209@SISPE7MB1.commscope.com> <4DC5B8DD-6011-4EDD-B4E9-4F038A1B3202@brianrosen.net> To: James Winterbottom X-Mailer: Apple Mail (2.1081) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1290473069 X-Barracuda-URL: http://64.34.111.252:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.73 X-Barracuda-Spam-Status: No, SCORE=0.73 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332, HTML_FONT_FACE_BAD, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.47409 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 0.00 HTML_MESSAGE BODY: HTML included in message 0.61 HTML_FONT_FACE_BAD BODY: HTML font face is not a word Cc: ECRIT Org Subject: Re: [Ecrit] Validation for Dispatch in LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 00:43:36 -0000 --Apple-Mail-74-780721990 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Also note that the LoST sever could use the "area-representative" method = as a hint that dispatch level validation couldn't be done. I'm still = not sure it should say the location is valid; it's not. Specifically, = it does not represent a known location in the local addressing = authority's domain. A way out would be to have a way to say that the location was route = valid, but not dispatch valid. That would add something to LoST. Brian On Nov 22, 2010, at 7:35 PM, Brian Rosen wrote: > I think we are likely to need this in NENA. It is essential that the = North American 9-1-1 system have a location valid for dispatch. That is = the function of the current "MSAG" validation. This validation has to = happen on the public servers. I believe any system needs this. You = must be able to dispatch a responder with the address that is supplied. = Having some entirely separate validation for dispatch is silly, in my = opinion. >=20 > The validation that we really need is when a location is entered into = the LIS. This won't be rough - the entity that operates the LIS has the = actual location. >=20 > The phonebcp validation for rough may indeed fail. It depends on how = it's implemented. It certainly could be something that is valid, but it = doesn't have to be. I don't think that is a problem. >=20 > Brian >=20 > On Nov 22, 2010, at 6:13 PM, Winterbottom, James wrote: >=20 >> Hi Brian, >> =20 >> I am sorry that it has taken so long to respond to this, I have been = busy with a few other things. >> =20 >> I still have concerns with your proposal here. I think it likely that = there will be LoST servers both on the public Internet and in the = ESInets. Both of these will be required to do location validation. = Location validation in ECRIT has a primary function of ensuring that the = location will route to a PSAP. If we take your approach, that LVF must = provide a dispatch capable location then things get very murky. >> =20 >> PhoneBCP says: =93ED-44 Endpoints SHOULD validate civic locations = when they receive >> them from their LCP. Validation SHOULD be performed in = conjunction >> with the LoST route query to minimize load on the LoST server.=94 >> =20 >> If this guidance is followed, and a coarse location provided as is = proposed in http://tools.ietf.org/id/-ecrit-rough-loc then the end-point = will get an error saying that the location is invalid. Clearly this = wrong! >> =20 >> Cheers >> James >> =20 >> =20 >> =20 >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of Brian Rosen >> Sent: Thursday, 18 November 2010 1:57 AM >> To: ECRIT Org >> Subject: [Ecrit] Validation for Dispatch in LoST >> =20 >> James Winterbottom pointed out to me this text in RFC5102: >> A caller location is considered valid if the >> civic or geographic location is recognizable within an = acceptable >> location reference system (e.g., United States Postal Address = or >> the WGS-84 datum) and can be mapped to one or more PSAPs.=20 >> =20 >> In -framework it says: >> 6.10. Location validation >>=20 >> Validation in this context means both that there is a mapping from >> the address to a PSAP and that the PSAP understands how to direct >> responders to the location. It is recommended that location be >> validated prior to a device placing an actual emergency call; some >> jurisdictions require that this be done. >> Notice that the second part ("and can be mapped...") in 5012 is = referring to validation for routing, where the text in -framework = includes validation for dispatch. =20 >>=20 >> James claims this is a conflict, which will lead to confusion. My = response is that "recognizable within an acceptable location reference = system" is the location reference system in the LoST server, which will = be whatever the local emergency authority's deem is needed. In most = cases, that would be valid for dispatch. >>=20 >> I gave James the following examples: >> a) There is a building with 2 floor served by one PSAP, and the rest = served by another. This happens. The 2 floors could be part of a = university which has it's own PSAP and responders, or it could be part = of a secure government facility which has a similar situation. In this = case, for a civic address, FLOOR must be present, and valid, in order to = route (and to dispatch). >> b) There is a building with a large number of floors in a = jurisdiction where there is a requirement that location be reported with = FLOOR (and often UNIT) if the building is over a certain size limit. = Again, FLOOR would have to be present and valid, even though FLOOR is = not needed to route. >> c) The LoST server may have FLOOR information, but it may not be a = required element. If the location sent in the LoST request contained = FLOOR, but the value was not in the right range, the LoST server should = respond with FLOOR in the list. On the other hand, if FLOOR = was not present, it wouldn't be an error. >>=20 >> Recall that validation is best done when inserting location = information into a LIS; well before an emergency call. A location = suitable for dispatch is also suitable for routing, but a location = suitable for routing is not necessarily suitable for dispatch.=20 >> =20 >> I don't see a problem here. I think that the "acceptable location = system" is determined by the jurisdiction providing the LoST server, and = if it requires validation to a dispatchable location, it can reasonably = require the LoST server to do that (by suitable provisioning). = -framework says exactly the right thing. >> =20 >> Over in NENA, we are requiring location be valid for dispatch, and we = are equipping the LoST server with the information needed to determine = that. >> =20 >> Brian >> =20 >> =20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail-74-780721990 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Also = note that the LoST sever could use the "area-representative" method as a = hint that dispatch level validation couldn't be done.  I'm still = not sure it should say the location is valid; it's not.   = Specifically, it does not represent a known location in the local = addressing authority's domain.

A way out would be to = have a way to say that the location was route valid, but not dispatch = valid.  That would add something to = LoST.

Brian

On Nov 22, = 2010, at 7:35 PM, Brian Rosen wrote:

I think we are likely to need = this in NENA.  It is essential that the North American 9-1-1 system = have a location valid for dispatch.  That is the function of the = current "MSAG" validation.  This validation has to happen on the = public servers.  I believe any system needs this.  You must be = able to dispatch a responder with the address that is supplied. =  Having some entirely separate validation for dispatch is silly, in = my opinion.

The validation that we really need is = when a location is entered into the LIS.  This won't be rough - the = entity that operates the LIS has the actual = location.

The phonebcp validation for rough may = indeed fail.   It depends on how it's implemented.  It = certainly could be something that is valid, but it doesn't have to be. =  I don't think that is a = problem.

Brian

On Nov 22, 2010, at 6:13 PM, Winterbottom, James wrote:

Hi = Brian,

 

I am sorry that it has taken so = long to respond to this, I have been busy with a few other = things.

 

I still have concerns with your = proposal here. I think it likely that there will be LoST servers both on the = public Internet and in the ESInets. Both of these will be required to do = location validation. Location validation in ECRIT has a primary function of = ensuring that the location will route to a PSAP. If we take your approach, that = LVF must provide a dispatch capable location then things get very = murky.

 

PhoneBCP says: =93ED-44 =
Endpoints SHOULD validate civic locations when they =
receive
   them from their LCP.  =
Validation SHOULD be performed in =
conjunction
   with =
the LoST route query to minimize load on the LoST =
server.=94

 

If this guidance is followed, and a = coarse location provided as is proposed in http://tools.ietf.org/i= d/-ecrit-rough-loc then the end-point will get an error saying that the location is = invalid. Clearly this wrong!

 

Cheers

James

 

 

 

From: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Thursday, 18 = November 2010 1:57 AM
To: ECRIT Org
Subject: [Ecrit] = Validation for Dispatch in LoST

 

James Winterbottom pointed out to me this text in = RFC5102:

      A caller location is considered valid if = the

      civic or =
geographic location is recognizable within an =
acceptable
      location =
reference system (e.g., United States Postal Address =
or
      the WGS-84 =
datum) and can be mapped to one or more PSAPs. =

 

In -framework it says:

6.10.  Location validation

   Validation in this context means =
both that there is a mapping =
from
   the =
address to a PSAP and that the PSAP understands how to =
direct
   =
responders to the location.  It is recommended that location =
be
   =
validated prior to a device placing an actual emergency call; =
some
   =
jurisdictions require that this be =
done.

Notice that the second part ("and can be mapped...") in 5012 is referring to validation for routing, where the text in = -framework includes validation for dispatch.  


James claims this is a conflict, which = will lead to confusion.  My response is that "recognizable within an = acceptable location reference system" is the location reference system in the LoST server, which will be whatever the local emergency authority's deem is needed. =  In most cases, that would be valid for dispatch.

I gave James the following = examples:
a) There is a building with 2 floor = served by one PSAP, and the rest served by another.  This happens.  The 2 = floors could be part of a university which has it's own PSAP and responders, =  or it could be part of a secure government facility which has a similar = situation.  In this case, for a civic address, FLOOR must be present, and = valid, in order to route (and to dispatch).
b) There is a building with a large = number of floors in a jurisdiction where there is a requirement that location be = reported with FLOOR (and often UNIT) if the building is over a certain size = limit.  Again, FLOOR would have to be present and valid, even though FLOOR is not = needed to route.
c) The LoST server may have FLOOR = information, but it may not be a required element.  If the location sent in the LoST request contained FLOOR, but the value was not in the right range, the = LoST server should respond with FLOOR in the <invalid> list.  On = the other hand, if FLOOR was not present, it wouldn't be an = error.

Recall that validation is best done when inserting location information into a = LIS; well before an emergency call.  A location suitable for dispatch is = also suitable for routing, but a location suitable for routing is not = necessarily suitable for dispatch. =

 

I don't see a problem here.  I think that the "acceptable location system" is determined by the jurisdiction providing the LoST server, and if it requires validation to a dispatchable location, it can reasonably = require the LoST server to do that (by suitable provisioning). =   -framework says exactly the right thing.

 

Over = in NENA, we are requiring location be valid for dispatch, and we are equipping the LoST = server with the information needed to determine = that.

 

Brian

 

 

=

________________= _______________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/= mailman/listinfo/ecrit

= = --Apple-Mail-74-780721990-- From br@brianrosen.net Mon Nov 22 16:45:00 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F22AB28C17C for ; Mon, 22 Nov 2010 16:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.958 X-Spam-Level: X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qlxamE5kyQx for ; Mon, 22 Nov 2010 16:44:56 -0800 (PST) Received: from barmail2.idig.net (barmail2.idig.net [64.34.111.252]) by core3.amsl.com (Postfix) with ESMTP id 8E41E3A6AB6 for ; Mon, 22 Nov 2010 16:44:56 -0800 (PST) X-ASG-Debug-ID: 1290473152-1a1fc7ea0001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail2.idig.net with ESMTP id mq9jqc67DI1xoJMq; Mon, 22 Nov 2010 16:45:52 -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.54]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PKh0v-0000bF-Li; Mon, 22 Nov 2010 16:45:51 -0800 Mime-Version: 1.0 (Apple Message framework v1081) X-ASG-Orig-Subj: Re: [Ecrit] Validation for Dispatch in LoST Content-Type: multipart/alternative; boundary=Apple-Mail-75-780806345 From: Brian Rosen In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120F234D232@SISPE7MB1.commscope.com> Date: Mon, 22 Nov 2010 19:45:35 -0500 Message-Id: <22092DAE-7560-4016-9522-3DA01E6A5133@brianrosen.net> References: <66485071-F496-4D33-A133-CA751A80B4A4@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC81880120F234D209@SISPE7MB1.commscope.com> <4DC5B8DD-6011-4EDD-B4E9-4F038A1B3202@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC81880120F234D232@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1081) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1290473152 X-Barracuda-URL: http://64.34.111.252:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.73 X-Barracuda-Spam-Status: No, SCORE=0.73 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332, HTML_FONT_FACE_BAD, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.47409 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 0.00 HTML_MESSAGE BODY: HTML included in message 0.61 HTML_FONT_FACE_BAD BODY: HTML font face is not a word Cc: ECRIT Org Subject: Re: [Ecrit] Validation for Dispatch in LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 00:45:00 -0000 --Apple-Mail-75-780806345 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It's MUCH better than not validating to dispatch quality. Having a rough location not return invalid is nice-to-have. Having location validation to dispatch quality is must have. Brian On Nov 22, 2010, at 7:41 PM, Winterbottom, James wrote: > I think this essentially leads to don=92t do location hiding in the US = and Canada because if you do you can=92t follow the guidance in = phoneBCP. > Personally I think that this is a problem, and simply saying let it = fail isn=92t a good option. > =20 > =20 > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, 23 November 2010 11:35 AM > To: Winterbottom, James > Cc: ECRIT Org > Subject: Re: [Ecrit] Validation for Dispatch in LoST > =20 > I think we are likely to need this in NENA. It is essential that the = North American 9-1-1 system have a location valid for dispatch. That is = the function of the current "MSAG" validation. This validation has to = happen on the public servers. I believe any system needs this. You = must be able to dispatch a responder with the address that is supplied. = Having some entirely separate validation for dispatch is silly, in my = opinion. > =20 > The validation that we really need is when a location is entered into = the LIS. This won't be rough - the entity that operates the LIS has the = actual location. > =20 > The phonebcp validation for rough may indeed fail. It depends on how = it's implemented. It certainly could be something that is valid, but it = doesn't have to be. I don't think that is a problem. > =20 > Brian > =20 > On Nov 22, 2010, at 6:13 PM, Winterbottom, James wrote: >=20 >=20 > Hi Brian, > =20 > I am sorry that it has taken so long to respond to this, I have been = busy with a few other things. > =20 > I still have concerns with your proposal here. I think it likely that = there will be LoST servers both on the public Internet and in the = ESInets. Both of these will be required to do location validation. = Location validation in ECRIT has a primary function of ensuring that the = location will route to a PSAP. If we take your approach, that LVF must = provide a dispatch capable location then things get very murky. > =20 > PhoneBCP says: =93ED-44 Endpoints SHOULD validate civic locations when = they receive > them from their LCP. Validation SHOULD be performed in conjunction > with the LoST route query to minimize load on the LoST server.=94 > =20 > If this guidance is followed, and a coarse location provided as is = proposed in http://tools.ietf.org/id/-ecrit-rough-loc then the end-point = will get an error saying that the location is invalid. Clearly this = wrong! > =20 > Cheers > James > =20 > =20 > =20 > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Brian Rosen > Sent: Thursday, 18 November 2010 1:57 AM > To: ECRIT Org > Subject: [Ecrit] Validation for Dispatch in LoST > =20 > James Winterbottom pointed out to me this text in RFC5102: > A caller location is considered valid if the > civic or geographic location is recognizable within an = acceptable > location reference system (e.g., United States Postal Address or > the WGS-84 datum) and can be mapped to one or more PSAPs.=20 > =20 > In -framework it says: > 6.10. Location validation >=20 > Validation in this context means both that there is a mapping from > the address to a PSAP and that the PSAP understands how to direct > responders to the location. It is recommended that location be > validated prior to a device placing an actual emergency call; some > jurisdictions require that this be done. > Notice that the second part ("and can be mapped...") in 5012 is = referring to validation for routing, where the text in -framework = includes validation for dispatch. =20 >=20 > James claims this is a conflict, which will lead to confusion. My = response is that "recognizable within an acceptable location reference = system" is the location reference system in the LoST server, which will = be whatever the local emergency authority's deem is needed. In most = cases, that would be valid for dispatch. >=20 > I gave James the following examples: > a) There is a building with 2 floor served by one PSAP, and the rest = served by another. This happens. The 2 floors could be part of a = university which has it's own PSAP and responders, or it could be part = of a secure government facility which has a similar situation. In this = case, for a civic address, FLOOR must be present, and valid, in order to = route (and to dispatch). > b) There is a building with a large number of floors in a jurisdiction = where there is a requirement that location be reported with FLOOR (and = often UNIT) if the building is over a certain size limit. Again, FLOOR = would have to be present and valid, even though FLOOR is not needed to = route. > c) The LoST server may have FLOOR information, but it may not be a = required element. If the location sent in the LoST request contained = FLOOR, but the value was not in the right range, the LoST server should = respond with FLOOR in the list. On the other hand, if FLOOR = was not present, it wouldn't be an error. >=20 > Recall that validation is best done when inserting location = information into a LIS; well before an emergency call. A location = suitable for dispatch is also suitable for routing, but a location = suitable for routing is not necessarily suitable for dispatch.=20 > =20 > I don't see a problem here. I think that the "acceptable location = system" is determined by the jurisdiction providing the LoST server, and = if it requires validation to a dispatchable location, it can reasonably = require the LoST server to do that (by suitable provisioning). = -framework says exactly the right thing. > =20 > Over in NENA, we are requiring location be valid for dispatch, and we = are equipping the LoST server with the information needed to determine = that. > =20 > Brian > =20 > =20 > =20 --Apple-Mail-75-780806345 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 It's = MUCH better than not validating to dispatch = quality.

Having a rough location not return invalid = is nice-to-have.

Having location validation to = dispatch quality is must = have.

Brian

On Nov 22, = 2010, at 7:41 PM, Winterbottom, James wrote:

I think this essentially leads to = don=92t do location hiding in the US and Canada because if you do you can=92t follow the guidance in = phoneBCP.

Personally I think that this is a = problem, and simply saying let it fail isn=92t a good = option.

 

 

 

From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Tuesday, 23 = November 2010 11:35 AM
To: Winterbottom, James
Cc: ECRIT Org
Subject: Re: [Ecrit] = Validation for Dispatch in LoST

 

I think we are likely to need this in NENA.  It is = essential that the North American 9-1-1 system have a location valid for dispatch. =  That is the function of the current "MSAG" validation.  This validation has to happen on the public servers.  I believe any = system needs this.  You must be able to dispatch a responder with the = address that is supplied.  Having some entirely separate validation for = dispatch is silly, in my opinion.

 

The validation that we really need is when a location is entered = into the LIS.  This won't be rough - the entity that operates the LIS = has the actual location.

 

The phonebcp validation for rough may indeed fail.   It = depends on how it's implemented.  It certainly could be something that is = valid, but it doesn't have to be.  I don't think that is a = problem.

 

Brian

 

On Nov 22, 2010, at 6:13 PM, Winterbottom, James wrote:



Hi = Brian,

 

I am sorry that it has taken so = long to respond to this, I have been busy with a few other = things.

 

I still have concerns with your = proposal here. I think it likely that there will be LoST servers both on the = public Internet and in the ESInets. Both of these will be required to do = location validation. Location validation in ECRIT has a primary function of = ensuring that the location will route to a PSAP. If we take your approach, that = LVF must provide a dispatch capable location then things get very = murky.

 

PhoneBCP says: =93ED-44 =
Endpoints SHOULD validate civic locations when they =
receive
   them from their =
LCP.  Validation SHOULD be performed in =
conjunction
   with the LoST route query to =
minimize load on the LoST =
server.=94

 

If this guidance is followed, and a = coarse location provided as is proposed in http://tools.ietf.org/i= d/-ecrit-rough-loc then the end-point will get an error saying that the location is = invalid. Clearly this wrong!

 

Cheers

James=

 

 

 

From: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org] = On Behalf Of Brian = Rosen
Sent: Thursday, 18 = November 2010 1:57 AM
To: ECRIT Org
Subject: [Ecrit] = Validation for Dispatch in LoST

 

James = Winterbottom pointed out to me this text in = RFC5102:

      A caller location is considered valid if = the

      civic or =
geographic location is recognizable within an =
acceptable
      location =
reference system (e.g., United States Postal Address =
or
      the WGS-84 =
datum) and can be mapped to one or more PSAPs. =

 

In -framework it says:

6.10.  Location validation

   Validation in this context means =
both that there is a mapping =
from
   the address to a PSAP and that =
the PSAP understands how to =
direct
   responders to the =
location.  It is recommended that location =
be
   validated prior to a device =
placing an actual emergency call; =
some
   jurisdictions require that this =
be done.

Notice that the second part ("and can be mapped...") in 5012 is referring to validation for routing, where the text in = -framework includes validation for dispatch. =  


James claims this is a conflict, which = will lead to confusion.  My response is that "recognizable within an = acceptable location reference system" is the location reference system in the LoST server, which will be whatever the local emergency authority's deem is needed. =  In most cases, that would be valid for dispatch.

I gave James the following = examples:
a) There is a building with 2 floor = served by one PSAP, and the rest served by another.  This happens.  The 2 = floors could be part of a university which has it's own PSAP and responders, =  or it could be part of a secure government facility which has a similar = situation.  In this case, for a civic address, FLOOR must be present, and = valid, in order to route (and to dispatch).
b) There is a building with a large = number of floors in a jurisdiction where there is a requirement that location be = reported with FLOOR (and often UNIT) if the building is over a certain size = limit.  Again, FLOOR would have to be present and valid, even though FLOOR is not = needed to route.
c) The LoST server may have FLOOR = information, but it may not be a required element.  If the location sent in the LoST request contained FLOOR, but the value was not in the right range, the = LoST server should respond with FLOOR in the <invalid> list.  On = the other hand, if FLOOR was not present, it wouldn't be an = error.

Recall that validation is best done when inserting location information into a = LIS; well before an emergency call.  A location suitable for dispatch is = also suitable for routing, but a location suitable for routing is not = necessarily suitable for dispatch. 

 

I don't see a problem here.  I think that the "acceptable location system" is determined by the jurisdiction providing the LoST server, and if it requires validation to a dispatchable location, it can reasonably = require the LoST server to do that (by suitable provisioning). =   -framework says exactly the right thing.

 

Over = in NENA, we are requiring location be valid for dispatch, and we are equipping the LoST = server with the information needed to determine = that.

 

Brian

 

 

 

=

=
= --Apple-Mail-75-780806345-- From Martin.Thomson@andrew.com Mon Nov 22 17:00:29 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD9E28C0D8 for ; Mon, 22 Nov 2010 17:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJfrRvtKseT0 for ; Mon, 22 Nov 2010 17:00:27 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 58BD93A6B02 for ; Mon, 22 Nov 2010 17:00:27 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:1511 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S38843209Ab0KWBBX (ORCPT ); Mon, 22 Nov 2010 19:01:23 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 22 Nov 2010 19:01:22 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 23 Nov 2010 09:01:20 +0800 From: "Thomson, Martin" To: Brian Rosen Date: Tue, 23 Nov 2010 09:01:17 +0800 Thread-Topic: [Ecrit] Validation for Dispatch in LoST Thread-Index: AcuKpx+6/PB2t/4iTkCQdlNQy6C3AgAAsQhQ Message-ID: <8B0A9FCBB9832F43971E38010638454F03F33EA945@SISPE7MB1.commscope.com> References: <66485071-F496-4D33-A133-CA751A80B4A4@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC81880120F234D209@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03F33EA91F@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F03F33EA945SISPE7MB1comm_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: ECRIT Org Subject: Re: [Ecrit] Validation for Dispatch in LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 01:00:29 -0000 --_000_8B0A9FCBB9832F43971E38010638454F03F33EA945SISPE7MB1comm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2FzIHRoYXQgZGlzY3Vzc2lvbiBjYXB0dXJlZCBhbnl3aGVyZSBvdGhlciB0aGFuIGluIGxpc3Qg ZGlzY3Vzc2lvbnM/DQoNCkZyb206IEJyaWFuIFJvc2VuIFttYWlsdG86YnJAYnJpYW5yb3Nlbi5u ZXRdDQpTZW50OiBUdWVzZGF5LCAyMyBOb3ZlbWJlciAyMDEwIDExOjQxIEFNDQpUbzogVGhvbXNv biwgTWFydGluDQpDYzogV2ludGVyYm90dG9tLCBKYW1lczsgRUNSSVQgT3JnDQpTdWJqZWN0OiBS ZTogW0Vjcml0XSBWYWxpZGF0aW9uIGZvciBEaXNwYXRjaCBpbiBMb1NUDQoNCkkgaGF2ZSBhc2tl ZCBvbiB0aGlzIGxpc3QgaWYgdGhlIDxpbnZhbGlkPiBsaXN0IGNhbiBjb250YWluIGFuIGVsZW1l bnQgbm90IGluIHRoZSBvcmlnaW5hbCBpbnB1dC4gIFRoZSBjb25jbHVzaW9uIG9mIHRoYXQgZGlz Y3Vzc2lvbiB3YXMgdGhhdCBpdCBjb3VsZC4NCg0KQnJpYW4NCg0KT24gTm92IDIyLCAyMDEwLCBh dCA2OjI5IFBNLCBUaG9tc29uLCBNYXJ0aW4gd3JvdGU6DQoNCg0KSSB0aGluayB0aGF0IGl0IG1p Z2h0IGJlIHJlYXNvbmFibGUgdG8gaGF2ZSB0aGUgZGV2aWNlL2VuZHBvaW50IGRldGVybWluZSB3 aGV0aGVyIHRoZXJlIGlzIGEgcm91dGUgb3Igbm90IGFzIHRoZSBwcmltYXJ5IGdvYWwgb2YgRUQt NDQgdmFsaWRhdGlvbi4gIEFzIGxvbmcgYXMgdGhpcyBpcyBub3QgYSBkZWZhdWx0IHJvdXRlLCB0 aGVuIHRoZXJlIGlzIG5vIGNhdXNlIGZvciBwYW5pYy4NCg0KTG9TVCB2YWxpZGF0aW9uIGlzIGNv bnN0cmFpbmVkIGluIHdoYXQgaXQgY2FuIHJlcG9ydCAtIGl04oCZcyB1bmNsZWFyIGhvdyBhIExv U1Qgc2VydmVyIHJlcG9ydHMgdGhhdCBhIGNpdmljIGFkZHJlc3MgaXMgaW52YWxpZCBkdWUgdG8g bWlzc2luZyBlbGVtZW50cy4gIEluIGFjdHVhbCBmYWN0LCB0aGUgdGV4dCBpcyB3cml0dGVuIGlu IGEgd2F5IHRoYXQgd291bGQgc2VlbSB0byBleGNsdWRlIHRoaXMgcG9zc2liaWxpdHkuICBJZiB0 aGlzIHdlcmUgcG9zc2libGUsIGEgcm91Z2ggbG9jYXRpb24gbWlnaHQgYmUgcmVwb3J0ZWQgYnkg dGhlIExvU1Qgc2VydmVyIGFzIGhhdmluZyBpbnZhbGlkIGVsZW1lbnRzICh0aG9zZSB0aGF0IG1p Z2h0IGJlIG5lZWRlZCBmb3IgZGlzcGF0Y2gpLCB0aG91Z2ggYSB2YWx1ZSByb3V0ZSBtaWdodCBz dGlsbCBiZSBwcm92aWRlZC4NCg0KVGhhdOKAmXMgc29tZSBwcmV0dHkgZnV6enkgc3BlY2lmaWNh dGlvbi4gIEkgZG9u4oCZdCB0aGluayB0aGF0IEkgY291bGQgcmVsaWFibHkgaW1wbGVtZW50IHRo YXQgZ2l2ZW4gd2hhdCBJIGtub3cgYWJvdXQgY2l2aWMgYWRkcmVzc2VzLCBidXQgaXTigJlzIHRo ZSBiZXN0IHRoYXQgSSBjb3VsZCBjb21lIHVwIHdpdGggYWZ0ZXIgdGhpbmtpbmcgbW9yZSBhYm91 dCBpdC4gIEkgc3VzcGVjdCB0aGF0IHRoaXMgaXMgd2h5IFNlY3Rpb24gOC40LjIgb2YgUkZDIDUy MjIgaXMgd3JpdHRlbiBhcyBpdCBpcyAtIHN1Y2ggZnV6emluZXNzIGlzbuKAmXQgY29uZHVjaXZl IHRvIGdldHRpbmcgaW50ZXJvcGVyYWJpbGl0eS4NCg0KKEEgY29uY2VybiB0aGF0IEkgaGF2ZSBo ZXJlIGlzIHRoYXQgYSBkZXZpY2UgZG9lc27igJl0IGhhdmUgYW55IG9wdGlvbiB0byByZW1lZHkg cHJvYmxlbXMgd2l0aCBsb2NhdGlvbiB1bmxlc3MgdGhleSBoYXZlIGFsdGVybmF0aXZlIHNvdXJj ZXMgb2YgbG9jYXRpb24uICAtcGhvbmUtYmNwIGRvZXNu4oCZdCBzcGVjaWZ5IHdoYXQgYSBkZXZp Y2UgZG9lcyBpZiBpdCBkaXNjb3ZlcnMgdGhhdCB0aGUgbG9jYXRpb24gaXQgaGFzIGlzIG5vIGdv b2QuKQ0KDQotLU1hcnRpbg0KDQpGcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpl Y3JpdC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBXaW50ZXJib3R0b20sIEphbWVzDQpTZW50OiBUdWVzZGF5LCAyMyBOb3ZlbWJl ciAyMDEwIDEwOjE0IEFNDQpUbzogQnJpYW4gUm9zZW47IEVDUklUIE9yZw0KU3ViamVjdDogUmU6 IFtFY3JpdF0gVmFsaWRhdGlvbiBmb3IgRGlzcGF0Y2ggaW4gTG9TVA0KDQpIaSBCcmlhbiwNCg0K SSBhbSBzb3JyeSB0aGF0IGl0IGhhcyB0YWtlbiBzbyBsb25nIHRvIHJlc3BvbmQgdG8gdGhpcywg SSBoYXZlIGJlZW4gYnVzeSB3aXRoIGEgZmV3IG90aGVyIHRoaW5ncy4NCg0KSSBzdGlsbCBoYXZl IGNvbmNlcm5zIHdpdGggeW91ciBwcm9wb3NhbCBoZXJlLiBJIHRoaW5rIGl0IGxpa2VseSB0aGF0 IHRoZXJlIHdpbGwgYmUgTG9TVCBzZXJ2ZXJzIGJvdGggb24gdGhlIHB1YmxpYyBJbnRlcm5ldCBh bmQgaW4gdGhlIEVTSW5ldHMuIEJvdGggb2YgdGhlc2Ugd2lsbCBiZSByZXF1aXJlZCB0byBkbyBs b2NhdGlvbiB2YWxpZGF0aW9uLiBMb2NhdGlvbiB2YWxpZGF0aW9uIGluIEVDUklUIGhhcyBhIHBy aW1hcnkgZnVuY3Rpb24gb2YgZW5zdXJpbmcgdGhhdCB0aGUgbG9jYXRpb24gd2lsbCByb3V0ZSB0 byBhIFBTQVAuIElmIHdlIHRha2UgeW91ciBhcHByb2FjaCwgdGhhdCBMVkYgbXVzdCBwcm92aWRl IGEgZGlzcGF0Y2ggY2FwYWJsZSBsb2NhdGlvbiB0aGVuIHRoaW5ncyBnZXQgdmVyeSBtdXJreS4N Cg0KDQpQaG9uZUJDUCBzYXlzOiDigJxFRC00NCBFbmRwb2ludHMgU0hPVUxEIHZhbGlkYXRlIGNp dmljIGxvY2F0aW9ucyB3aGVuIHRoZXkgcmVjZWl2ZQ0KDQogICB0aGVtIGZyb20gdGhlaXIgTENQ LiAgVmFsaWRhdGlvbiBTSE9VTEQgYmUgcGVyZm9ybWVkIGluIGNvbmp1bmN0aW9uDQoNCiAgIHdp dGggdGhlIExvU1Qgcm91dGUgcXVlcnkgdG8gbWluaW1pemUgbG9hZCBvbiB0aGUgTG9TVCBzZXJ2 ZXIu4oCdDQoNCklmIHRoaXMgZ3VpZGFuY2UgaXMgZm9sbG93ZWQsIGFuZCBhIGNvYXJzZSBsb2Nh dGlvbiBwcm92aWRlZCBhcyBpcyBwcm9wb3NlZCBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQv LWVjcml0LXJvdWdoLWxvYyB0aGVuIHRoZSBlbmQtcG9pbnQgd2lsbCBnZXQgYW4gZXJyb3Igc2F5 aW5nIHRoYXQgdGhlIGxvY2F0aW9uIGlzIGludmFsaWQuIENsZWFybHkgdGhpcyB3cm9uZyENCg0K Q2hlZXJzDQpKYW1lcw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc+ IFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIFJvc2Vu DQpTZW50OiBUaHVyc2RheSwgMTggTm92ZW1iZXIgMjAxMCAxOjU3IEFNDQpUbzogRUNSSVQgT3Jn DQpTdWJqZWN0OiBbRWNyaXRdIFZhbGlkYXRpb24gZm9yIERpc3BhdGNoIGluIExvU1QNCg0KSmFt ZXMgV2ludGVyYm90dG9tIHBvaW50ZWQgb3V0IHRvIG1lIHRoaXMgdGV4dCBpbiBSRkM1MTAyOg0K ICAgICAgQSBjYWxsZXIgbG9jYXRpb24gaXMgY29uc2lkZXJlZCB2YWxpZCBpZiB0aGUNCg0KICAg ICAgY2l2aWMgb3IgZ2VvZ3JhcGhpYyBsb2NhdGlvbiBpcyByZWNvZ25pemFibGUgd2l0aGluIGFu IGFjY2VwdGFibGUNCg0KICAgICAgbG9jYXRpb24gcmVmZXJlbmNlIHN5c3RlbSAoZS5nLiwgVW5p dGVkIFN0YXRlcyBQb3N0YWwgQWRkcmVzcyBvcg0KDQogICAgICB0aGUgV0dTLTg0IGRhdHVtKSBh bmQgY2FuIGJlIG1hcHBlZCB0byBvbmUgb3IgbW9yZSBQU0FQcy4NCg0KSW4gLWZyYW1ld29yayBp dCBzYXlzOg0KNi4xMC4gIExvY2F0aW9uIHZhbGlkYXRpb24NCg0KICAgVmFsaWRhdGlvbiBpbiB0 aGlzIGNvbnRleHQgbWVhbnMgYm90aCB0aGF0IHRoZXJlIGlzIGEgbWFwcGluZyBmcm9tDQoNCiAg IHRoZSBhZGRyZXNzIHRvIGEgUFNBUCBhbmQgdGhhdCB0aGUgUFNBUCB1bmRlcnN0YW5kcyBob3cg dG8gZGlyZWN0DQoNCiAgIHJlc3BvbmRlcnMgdG8gdGhlIGxvY2F0aW9uLiAgSXQgaXMgcmVjb21t ZW5kZWQgdGhhdCBsb2NhdGlvbiBiZQ0KDQogICB2YWxpZGF0ZWQgcHJpb3IgdG8gYSBkZXZpY2Ug cGxhY2luZyBhbiBhY3R1YWwgZW1lcmdlbmN5IGNhbGw7IHNvbWUNCg0KICAganVyaXNkaWN0aW9u cyByZXF1aXJlIHRoYXQgdGhpcyBiZSBkb25lLg0KTm90aWNlIHRoYXQgdGhlIHNlY29uZCBwYXJ0 ICgiYW5kIGNhbiBiZSBtYXBwZWQuLi4iKSBpbiA1MDEyIGlzIHJlZmVycmluZyB0byB2YWxpZGF0 aW9uIGZvciByb3V0aW5nLCB3aGVyZSB0aGUgdGV4dCBpbiAtZnJhbWV3b3JrIGluY2x1ZGVzIHZh bGlkYXRpb24gZm9yIGRpc3BhdGNoLg0KDQpKYW1lcyBjbGFpbXMgdGhpcyBpcyBhIGNvbmZsaWN0 LCB3aGljaCB3aWxsIGxlYWQgdG8gY29uZnVzaW9uLiAgTXkgcmVzcG9uc2UgaXMgdGhhdCAicmVj b2duaXphYmxlIHdpdGhpbiBhbiBhY2NlcHRhYmxlIGxvY2F0aW9uIHJlZmVyZW5jZSBzeXN0ZW0i IGlzIHRoZSBsb2NhdGlvbiByZWZlcmVuY2Ugc3lzdGVtIGluIHRoZSBMb1NUIHNlcnZlciwgd2hp Y2ggd2lsbCBiZSB3aGF0ZXZlciB0aGUgbG9jYWwgZW1lcmdlbmN5IGF1dGhvcml0eSdzIGRlZW0g aXMgbmVlZGVkLiAgSW4gbW9zdCBjYXNlcywgdGhhdCB3b3VsZCBiZSB2YWxpZCBmb3IgZGlzcGF0 Y2guDQoNCkkgZ2F2ZSBKYW1lcyB0aGUgZm9sbG93aW5nIGV4YW1wbGVzOg0KYSkgVGhlcmUgaXMg YSBidWlsZGluZyB3aXRoIDIgZmxvb3Igc2VydmVkIGJ5IG9uZSBQU0FQLCBhbmQgdGhlIHJlc3Qg c2VydmVkIGJ5IGFub3RoZXIuICBUaGlzIGhhcHBlbnMuICBUaGUgMiBmbG9vcnMgY291bGQgYmUg cGFydCBvZiBhIHVuaXZlcnNpdHkgd2hpY2ggaGFzIGl0J3Mgb3duIFBTQVAgYW5kIHJlc3BvbmRl cnMsICBvciBpdCBjb3VsZCBiZSBwYXJ0IG9mIGEgc2VjdXJlIGdvdmVybm1lbnQgZmFjaWxpdHkg d2hpY2ggaGFzIGEgc2ltaWxhciBzaXR1YXRpb24uICBJbiB0aGlzIGNhc2UsIGZvciBhIGNpdmlj IGFkZHJlc3MsIEZMT09SIG11c3QgYmUgcHJlc2VudCwgYW5kIHZhbGlkLCBpbiBvcmRlciB0byBy b3V0ZSAoYW5kIHRvIGRpc3BhdGNoKS4NCmIpIFRoZXJlIGlzIGEgYnVpbGRpbmcgd2l0aCBhIGxh cmdlIG51bWJlciBvZiBmbG9vcnMgaW4gYSBqdXJpc2RpY3Rpb24gd2hlcmUgdGhlcmUgaXMgYSBy ZXF1aXJlbWVudCB0aGF0IGxvY2F0aW9uIGJlIHJlcG9ydGVkIHdpdGggRkxPT1IgKGFuZCBvZnRl biBVTklUKSBpZiB0aGUgYnVpbGRpbmcgaXMgb3ZlciBhIGNlcnRhaW4gc2l6ZSBsaW1pdC4gIEFn YWluLCBGTE9PUiB3b3VsZCBoYXZlIHRvIGJlIHByZXNlbnQgYW5kIHZhbGlkLCBldmVuIHRob3Vn aCBGTE9PUiBpcyBub3QgbmVlZGVkIHRvIHJvdXRlLg0KYykgVGhlIExvU1Qgc2VydmVyIG1heSBo YXZlIEZMT09SIGluZm9ybWF0aW9uLCBidXQgaXQgbWF5IG5vdCBiZSBhIHJlcXVpcmVkIGVsZW1l bnQuICBJZiB0aGUgbG9jYXRpb24gc2VudCBpbiB0aGUgTG9TVCByZXF1ZXN0IGNvbnRhaW5lZCBG TE9PUiwgYnV0IHRoZSB2YWx1ZSB3YXMgbm90IGluIHRoZSByaWdodCByYW5nZSwgdGhlIExvU1Qg c2VydmVyIHNob3VsZCByZXNwb25kIHdpdGggRkxPT1IgaW4gdGhlIDxpbnZhbGlkPiBsaXN0LiAg T24gdGhlIG90aGVyIGhhbmQsIGlmIEZMT09SIHdhcyBub3QgcHJlc2VudCwgaXQgd291bGRuJ3Qg YmUgYW4gZXJyb3IuDQpSZWNhbGwgdGhhdCB2YWxpZGF0aW9uIGlzIGJlc3QgZG9uZSB3aGVuIGlu c2VydGluZyBsb2NhdGlvbiBpbmZvcm1hdGlvbiBpbnRvIGEgTElTOyB3ZWxsIGJlZm9yZSBhbiBl bWVyZ2VuY3kgY2FsbC4gIEEgbG9jYXRpb24gc3VpdGFibGUgZm9yIGRpc3BhdGNoIGlzIGFsc28g c3VpdGFibGUgZm9yIHJvdXRpbmcsIGJ1dCBhIGxvY2F0aW9uIHN1aXRhYmxlIGZvciByb3V0aW5n IGlzIG5vdCBuZWNlc3NhcmlseSBzdWl0YWJsZSBmb3IgZGlzcGF0Y2guDQoNCkkgZG9uJ3Qgc2Vl IGEgcHJvYmxlbSBoZXJlLiAgSSB0aGluayB0aGF0IHRoZSAiYWNjZXB0YWJsZSBsb2NhdGlvbiBz eXN0ZW0iIGlzIGRldGVybWluZWQgYnkgdGhlIGp1cmlzZGljdGlvbiBwcm92aWRpbmcgdGhlIExv U1Qgc2VydmVyLCBhbmQgaWYgaXQgcmVxdWlyZXMgdmFsaWRhdGlvbiB0byBhIGRpc3BhdGNoYWJs ZSBsb2NhdGlvbiwgaXQgY2FuIHJlYXNvbmFibHkgcmVxdWlyZSB0aGUgTG9TVCBzZXJ2ZXIgdG8g ZG8gdGhhdCAoYnkgc3VpdGFibGUgcHJvdmlzaW9uaW5nKS4gICAtZnJhbWV3b3JrIHNheXMgZXhh Y3RseSB0aGUgcmlnaHQgdGhpbmcuDQoNCk92ZXIgaW4gTkVOQSwgd2UgYXJlIHJlcXVpcmluZyBs b2NhdGlvbiBiZSB2YWxpZCBmb3IgZGlzcGF0Y2gsIGFuZCB3ZSBhcmUgZXF1aXBwaW5nIHRoZSBM b1NUIHNlcnZlciB3aXRoIHRoZSBpbmZvcm1hdGlvbiBuZWVkZWQgdG8gZGV0ZXJtaW5lIHRoYXQu DQoNCkJyaWFuDQoNCg0KDQo= --_000_8B0A9FCBB9832F43971E38010638454F03F33EA945SISPE7MB1comm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9VVRGLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29u dGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPjxiYXNlIGhyZWY9Ingt bXNnOi8vMTY0My8iPjwhLS1baWYgIW1zb10+PHN0eWxlPnZcOioge2JlaGF2aW9yOnVybCgjZGVm YXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2Jl aGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KPC9zdHlsZT48IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0 aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6 MCAxMSA1IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJp YSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUg NCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0x OjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlwwMDI3 VGltZXMgTmV3IFJvbWFuXDAwMjciO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowbW07DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQpoMw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28t c3R5bGUtbGluazoiSGVhZGluZyAzIENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowbW07DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MG1tOw0KCWZvbnQtc2l6ZToxMy41cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltYXJnaW46MG1tOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5hcHBsZS1z dHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5hcHBs ZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNl O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uSGVh ZGluZzNDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDMgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyI7DQoJZm9udC1mYW1pbHk6 IkNhbWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6IzRGODFCRDsNCglmb250LXdlaWdodDpib2xkO30N CnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2bGlu az1wdXJwbGUgc3R5bGU9J3dvcmQtd3JhcDogYnJlYWstd29yZDstd2Via2l0LW5ic3AtbW9kZTog c3BhY2U7LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZSc+PGRpdiBjbGFzcz1X b3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2Fz IHRoYXQgZGlzY3Vzc2lvbiBjYXB0dXJlZCBhbnl3aGVyZSBvdGhlciB0aGFuIGluIGxpc3QgZGlz Y3Vzc2lvbnM/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBtbSAwbW0gMG1tJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IEJyaWFuIFJvc2VuIFttYWlsdG86 YnJAYnJpYW5yb3Nlbi5uZXRdIDxicj48Yj5TZW50OjwvYj4gVHVlc2RheSwgMjMgTm92ZW1iZXIg MjAxMCAxMTo0MSBBTTxicj48Yj5Ubzo8L2I+IFRob21zb24sIE1hcnRpbjxicj48Yj5DYzo8L2I+ IFdpbnRlcmJvdHRvbSwgSmFtZXM7IEVDUklUIE9yZzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtF Y3JpdF0gVmFsaWRhdGlvbiBmb3IgRGlzcGF0Y2ggaW4gTG9TVDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPkkgaGF2ZSBhc2tlZCBvbiB0aGlzIGxpc3QgaWYgdGhlICZsdDtpbnZh bGlkJmd0OyBsaXN0IGNhbiBjb250YWluIGFuIGVsZW1lbnQgbm90IGluIHRoZSBvcmlnaW5hbCBp bnB1dC4gJm5ic3A7VGhlIGNvbmNsdXNpb24gb2YgdGhhdCBkaXNjdXNzaW9uIHdhcyB0aGF0IGl0 IGNvdWxkLjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkJyaWFuPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBOb3YgMjIsIDIwMTAsIGF0IDY6MjkgUE0sIFRo b21zb24sIE1hcnRpbiB3cm90ZTo8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PGJyPjxicj48bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSB0aGluayB0aGF0IGl0IG1pZ2h0IGJlIHJlYXNvbmFibGUg dG8gaGF2ZSB0aGUgZGV2aWNlL2VuZHBvaW50IGRldGVybWluZSB3aGV0aGVyIHRoZXJlIGlzIGEg cm91dGUgb3Igbm90IGFzIHRoZSBwcmltYXJ5IGdvYWwgb2YgRUQtNDQgdmFsaWRhdGlvbi4mbmJz cDsgQXMgbG9uZyBhcyB0aGlzIGlzIG5vdCBhIGRlZmF1bHQgcm91dGUsIHRoZW4gdGhlcmUgaXMg bm8gY2F1c2UgZm9yIHBhbmljLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPkxvU1QgdmFsaWRhdGlvbiBpcyBjb25zdHJhaW5lZCBpbiB3aGF0IGl0IGNhbiByZXBvcnQg LSBpdOKAmXMgdW5jbGVhciBob3cgYSBMb1NUIHNlcnZlciByZXBvcnRzIHRoYXQgYSBjaXZpYyBh ZGRyZXNzIGlzIGludmFsaWQgZHVlIHRvIG1pc3NpbmcgZWxlbWVudHMuJm5ic3A7IEluIGFjdHVh bCBmYWN0LCB0aGUgdGV4dCBpcyB3cml0dGVuIGluIGEgd2F5IHRoYXQgd291bGQgc2VlbSB0byBl eGNsdWRlIHRoaXMgcG9zc2liaWxpdHkuJm5ic3A7IElmIHRoaXMgd2VyZSBwb3NzaWJsZSwgYSBy b3VnaCBsb2NhdGlvbiBtaWdodCBiZSByZXBvcnRlZCBieSB0aGUgTG9TVCBzZXJ2ZXIgYXMgaGF2 aW5nIGludmFsaWQgZWxlbWVudHMgKHRob3NlIHRoYXQgbWlnaHQgYmUgbmVlZGVkIGZvciBkaXNw YXRjaCksIHRob3VnaCBhIHZhbHVlIHJvdXRlIG1pZ2h0IHN0aWxsIGJlIHByb3ZpZGVkLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoYXTigJlzIHNvbWUgcHJldHR5 IGZ1enp5IHNwZWNpZmljYXRpb24uJm5ic3A7IEkgZG9u4oCZdCB0aGluayB0aGF0IEkgY291bGQg cmVsaWFibHkgaW1wbGVtZW50IHRoYXQgZ2l2ZW4gd2hhdCBJIGtub3cgYWJvdXQgY2l2aWMgYWRk cmVzc2VzLCBidXQgaXTigJlzIHRoZSBiZXN0IHRoYXQgSSBjb3VsZCBjb21lIHVwIHdpdGggYWZ0 ZXIgdGhpbmtpbmcgbW9yZSBhYm91dCBpdC4mbmJzcDsgSSBzdXNwZWN0IHRoYXQgdGhpcyBpcyB3 aHkgU2VjdGlvbiA4LjQuMiBvZiBSRkMgNTIyMiBpcyB3cml0dGVuIGFzIGl0IGlzIC0gc3VjaCBm dXp6aW5lc3MgaXNu4oCZdCBjb25kdWNpdmUgdG8gZ2V0dGluZyBpbnRlcm9wZXJhYmlsaXR5Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPihBIGNvbmNlcm4gdGhhdCBJ IGhhdmUgaGVyZSBpcyB0aGF0IGEgZGV2aWNlIGRvZXNu4oCZdCBoYXZlIGFueSBvcHRpb24gdG8g cmVtZWR5IHByb2JsZW1zIHdpdGggbG9jYXRpb24gdW5sZXNzIHRoZXkgaGF2ZSBhbHRlcm5hdGl2 ZSBzb3VyY2VzIG9mIGxvY2F0aW9uLiZuYnNwOyAtcGhvbmUtYmNwIGRvZXNu4oCZdCBzcGVjaWZ5 IHdoYXQgYSBkZXZpY2UgZG9lcyBpZiBpdCBkaXNjb3ZlcnMgdGhhdCB0aGUgbG9jYXRpb24gaXQg aGFzIGlzIG5vIGdvb2QuKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn Pi0tTWFydGluPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMG1tIDBtbSAwbW07Ym9yZGVyLXdpZHRoOmluaXRpYWw7Ym9y ZGVyLWNvbG9yOmluaXRpYWwnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNl PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Jz48YSBocmVmPSJtYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZyI+ZWNyaXQtYm91bmNlc0Bp ZXRmLm9yZzwvYT48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFu PlttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ108c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0 ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNzPWFwcGxlLWNv bnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PC9iPldpbnRlcmJvdHRvbSwgSmFtZXM8YnI+PGI+ U2VudDo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj5U dWVzZGF5LCAyMyBOb3ZlbWJlciAyMDEwIDEwOjE0IEFNPGJyPjxiPlRvOjwvYj48c3BhbiBjbGFz cz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPkJyaWFuIFJvc2VuOyBFQ1JJVCBP cmc8YnI+PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZu YnNwOzwvc3Bhbj5SZTogW0Vjcml0XSBWYWxpZGF0aW9uIGZvciBEaXNwYXRjaCBpbiBMb1NUPC9z cGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOm5hdnknPkhpIEJyaWFuLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6bmF2eSc+ SSBhbSBzb3JyeSB0aGF0IGl0IGhhcyB0YWtlbiBzbyBsb25nIHRvIHJlc3BvbmQgdG8gdGhpcywg SSBoYXZlIGJlZW4gYnVzeSB3aXRoIGEgZmV3IG90aGVyIHRoaW5ncy48L3NwYW4+PG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6bmF2eSc+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOm5hdnknPkkgc3RpbGwgaGF2ZSBjb25jZXJucyB3aXRoIHlvdXIgcHJvcG9zYWwg aGVyZS4gSSB0aGluayBpdCBsaWtlbHkgdGhhdCB0aGVyZSB3aWxsIGJlIExvU1Qgc2VydmVycyBi b3RoIG9uIHRoZSBwdWJsaWMgSW50ZXJuZXQgYW5kIGluIHRoZSBFU0luZXRzLiBCb3RoIG9mIHRo ZXNlIHdpbGwgYmUgcmVxdWlyZWQgdG8gZG8gbG9jYXRpb24gdmFsaWRhdGlvbi4gTG9jYXRpb24g dmFsaWRhdGlvbiBpbiBFQ1JJVCBoYXMgYSBwcmltYXJ5IGZ1bmN0aW9uIG9mIGVuc3VyaW5nIHRo YXQgdGhlIGxvY2F0aW9uIHdpbGwgcm91dGUgdG8gYSBQU0FQLiBJZiB3ZSB0YWtlIHlvdXIgYXBw cm9hY2gsIHRoYXQgTFZGIG11c3QgcHJvdmlkZSBhIGRpc3BhdGNoIGNhcGFibGUgbG9jYXRpb24g dGhlbiB0aGluZ3MgZ2V0IHZlcnkgbXVya3kuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOm5hdnknPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD48L2Rpdj48cHJlPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz5QaG9uZUJDUCBzYXlzOiDigJw8L3NwYW4+RUQtNDQgRW5k cG9pbnRzIFNIT1VMRCB2YWxpZGF0ZSBjaXZpYyBsb2NhdGlvbnMgd2hlbiB0aGV5IHJlY2VpdmU8 bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7Jm5ic3A7IHRoZW0gZnJvbSB0aGVpciBMQ1AuJm5i c3A7IFZhbGlkYXRpb24gU0hPVUxEIGJlIHBlcmZvcm1lZCBpbiBjb25qdW5jdGlvbjxvOnA+PC9v OnA+PC9wcmU+PHByZT4mbmJzcDsmbmJzcDsgd2l0aCB0aGUgTG9TVCByb3V0ZSBxdWVyeSB0byBt aW5pbWl6ZSBsb2FkIG9uIHRoZSBMb1NUIHNlcnZlci7igJ08bzpwPjwvbzpwPjwvcHJlPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOm5hdnknPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz5J ZiB0aGlzIGd1aWRhbmNlIGlzIGZvbGxvd2VkLCBhbmQgYSBjb2Fyc2UgbG9jYXRpb24gcHJvdmlk ZWQgYXMgaXMgcHJvcG9zZWQgaW48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5i c3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC8tZWNyaXQtcm91Z2gt bG9jIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvLWVjcml0LXJvdWdoLWxvYzwvYT48c3BhbiBj bGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPnRoZW4gdGhlIGVuZC1wb2lu dCB3aWxsIGdldCBhbiBlcnJvciBzYXlpbmcgdGhhdCB0aGUgbG9jYXRpb24gaXMgaW52YWxpZC4g Q2xlYXJseSB0aGlzIHdyb25nITwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6bmF2eSc+Q2hlZXJz PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOm5hdnknPkphbWVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOm5hdnknPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6bmF2eSc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowbW0gMG1tIDBtbSA0LjBwdDtib3JkZXItd2lkdGg6aW5pdGlhbDtib3JkZXIt Y29sb3I6aW5pdGlhbCc+PGRpdj48ZGl2IGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5 bGU9J3RleHQtYWxpZ246Y2VudGVyJz48c3BhbiBsYW5nPUVOLVVTPjxociBzaXplPTIgd2lkdGg9 IjEwMCUiIGFsaWduPWNlbnRlcj48L3NwYW4+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz1hcHBsZS1j b252ZXJ0ZWQtc3BhY2U+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPjxhIGhyZWY9Im1haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnIj5l Y3JpdC1ib3VuY2VzQGlldGYub3JnPC9hPjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFj ZT4mbmJzcDs8L3NwYW4+W21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXTxzcGFuIGNsYXNz PWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNwYW4g Y2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L2I+QnJpYW4gUm9zZW48 YnI+PGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv c3Bhbj5UaHVyc2RheSwgMTggTm92ZW1iZXIgMjAxMCAxOjU3IEFNPGJyPjxiPlRvOjwvYj48c3Bh biBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPkVDUklUIE9yZzxicj48 Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9z cGFuPltFY3JpdF0gVmFsaWRhdGlvbiBmb3IgRGlzcGF0Y2ggaW4gTG9TVDwvc3Bhbj48bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBjbGFzcz1hcHBsZS1z dHlsZS1zcGFuPkphbWVzIFdpbnRlcmJvdHRvbSBwb2ludGVkIG91dCB0byBtZSB0aGlzIHRleHQg aW4gUkZDNTEwMjo8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQSBjYWxsZXIgbG9jYXRpb24gaXMgY29uc2lkZXJlZCB2 YWxpZCBpZiB0aGU8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2 PjxkaXY+PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2l2aWMgb3IgZ2VvZ3Jh cGhpYyBsb2NhdGlvbiBpcyByZWNvZ25pemFibGUgd2l0aGluIGFuIGFjY2VwdGFibGU8bzpwPjwv bzpwPjwvcHJlPjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxvY2F0aW9uIHJl ZmVyZW5jZSBzeXN0ZW0gKGUuZy4sIFVuaXRlZCBTdGF0ZXMgUG9zdGFsIEFkZHJlc3Mgb3I8bzpw PjwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBXR1Mt ODQgZGF0dW0pIGFuZCBjYW4gYmUgbWFwcGVkIHRvIG9uZSBvciBtb3JlIFBTQVBzLiA8bzpwPjwv bzpwPjwvcHJlPjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+SW4gLWZyYW1ld29yayBpdCBzYXlzOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2 PjwvZGl2PjxkaXY+PGgzPjxhIG5hbWU9c2VjdGlvbi02LjEwPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiQ291cmllciBOZXciJz42LjEwPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+LiZuYnNwOyBMb2NhdGlvbiB2YWxpZGF0aW9uPC9zcGFuPjxvOnA+ PC9vOnA+PC9oMz48cHJlPiZuYnNwOyZuYnNwOyBWYWxpZGF0aW9uIGluIHRoaXMgY29udGV4dCBt ZWFucyBib3RoIHRoYXQgdGhlcmUgaXMgYSBtYXBwaW5nIGZyb208bzpwPjwvbzpwPjwvcHJlPjxw cmU+Jm5ic3A7Jm5ic3A7IHRoZSBhZGRyZXNzIHRvIGEgUFNBUCBhbmQgdGhhdCB0aGUgUFNBUCB1 bmRlcnN0YW5kcyBob3cgdG8gZGlyZWN0PG86cD48L286cD48L3ByZT48cHJlPiZuYnNwOyZuYnNw OyByZXNwb25kZXJzIHRvIHRoZSBsb2NhdGlvbi4mbmJzcDsgSXQgaXMgcmVjb21tZW5kZWQgdGhh dCBsb2NhdGlvbiBiZTxvOnA+PC9vOnA+PC9wcmU+PHByZT4mbmJzcDsmbmJzcDsgdmFsaWRhdGVk IHByaW9yIHRvIGEgZGV2aWNlIHBsYWNpbmcgYW4gYWN0dWFsIGVtZXJnZW5jeSBjYWxsOyBzb21l PG86cD48L286cD48L3ByZT48cHJlPiZuYnNwOyZuYnNwOyBqdXJpc2RpY3Rpb25zIHJlcXVpcmUg dGhhdCB0aGlzIGJlIGRvbmUuPG86cD48L286cD48L3ByZT48ZGl2PjxkaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+Tm90aWNlIHRoYXQgdGhlIHNlY29uZCBwYXJ0ICgmcXVvdDthbmQgY2FuIGJl IG1hcHBlZC4uLiZxdW90OykgaW4gNTAxMiBpcyByZWZlcnJpbmcgdG8gdmFsaWRhdGlvbiBmb3Ig cm91dGluZywgd2hlcmUmbmJzcDt0aGUgdGV4dCBpbiAtZnJhbWV3b3JrIGluY2x1ZGVzIHZhbGlk YXRpb24gZm9yIGRpc3BhdGNoLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6IlwwMDI3VGltZXMgTmV3IFJvbWFuXDAwMjciJz48YnI+PHNwYW4gY2xhc3M9 YXBwbGUtc3R5bGUtc3Bhbj5KYW1lcyBjbGFpbXMgdGhpcyBpcyBhIGNvbmZsaWN0LCB3aGljaCB3 aWxsIGxlYWQgdG8gY29uZnVzaW9uLiAmbmJzcDtNeSByZXNwb25zZSBpcyB0aGF0ICZxdW90O3Jl Y29nbml6YWJsZSB3aXRoaW4gYW4gYWNjZXB0YWJsZSZuYnNwO2xvY2F0aW9uIHJlZmVyZW5jZSBz eXN0ZW0mcXVvdDsgaXMgdGhlIGxvY2F0aW9uIHJlZmVyZW5jZSBzeXN0ZW0gaW4gdGhlIExvU1Qg c2VydmVyLCB3aGljaCB3aWxsIGJlIHdoYXRldmVyIHRoZSBsb2NhbCBlbWVyZ2VuY3kgYXV0aG9y aXR5J3MgZGVlbSBpcyBuZWVkZWQuICZuYnNwO0luIG1vc3QgY2FzZXMsIHRoYXQgd291bGQgYmUg dmFsaWQgZm9yIGRpc3BhdGNoLjwvc3Bhbj48YnI+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxl LXNwYW4+SSBnYXZlIEphbWVzIHRoZSBmb2xsb3dpbmcgZXhhbXBsZXM6PC9zcGFuPjxicj48c3Bh biBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPmEpIFRoZXJlIGlzIGEgYnVpbGRpbmcgd2l0aCAyIGZs b29yIHNlcnZlZCBieSBvbmUgUFNBUCwgYW5kIHRoZSByZXN0IHNlcnZlZCBieSBhbm90aGVyLiAm bmJzcDtUaGlzIGhhcHBlbnMuICZuYnNwO1RoZSAyIGZsb29ycyBjb3VsZCBiZSBwYXJ0IG9mIGEg dW5pdmVyc2l0eSB3aGljaCBoYXMgaXQncyBvd24gUFNBUCBhbmQgcmVzcG9uZGVycywgJm5ic3A7 b3IgaXQgY291bGQgYmUgcGFydCBvZiBhIHNlY3VyZSBnb3Zlcm5tZW50IGZhY2lsaXR5IHdoaWNo IGhhcyBhIHNpbWlsYXIgc2l0dWF0aW9uLiAmbmJzcDtJbiB0aGlzIGNhc2UsIGZvciBhIGNpdmlj IGFkZHJlc3MsIEZMT09SIG11c3QgYmUgcHJlc2VudCwgYW5kIHZhbGlkLCBpbiBvcmRlciB0byBy b3V0ZSAoYW5kIHRvIGRpc3BhdGNoKS48L3NwYW4+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxl LXNwYW4+YikgVGhlcmUgaXMgYSBidWlsZGluZyB3aXRoIGEgbGFyZ2UgbnVtYmVyIG9mIGZsb29y cyBpbiBhIGp1cmlzZGljdGlvbiB3aGVyZSB0aGVyZSBpcyBhIHJlcXVpcmVtZW50IHRoYXQgbG9j YXRpb24gYmUgcmVwb3J0ZWQgd2l0aCBGTE9PUiAoYW5kIG9mdGVuIFVOSVQpIGlmIHRoZSBidWls ZGluZyBpcyBvdmVyIGEgY2VydGFpbiBzaXplIGxpbWl0LiAmbmJzcDtBZ2FpbiwgRkxPT1Igd291 bGQgaGF2ZSB0byBiZSBwcmVzZW50IGFuZCB2YWxpZCwgZXZlbiB0aG91Z2ggRkxPT1IgaXMgbm90 IG5lZWRlZCB0byByb3V0ZS48L3NwYW4+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+ YykgVGhlIExvU1Qgc2VydmVyIG1heSBoYXZlIEZMT09SIGluZm9ybWF0aW9uLCBidXQgaXQgbWF5 IG5vdCBiZSBhIHJlcXVpcmVkIGVsZW1lbnQuICZuYnNwO0lmIHRoZSBsb2NhdGlvbiBzZW50IGlu IHRoZSBMb1NUIHJlcXVlc3QgY29udGFpbmVkIEZMT09SLCBidXQgdGhlIHZhbHVlIHdhcyBub3Qg aW4gdGhlIHJpZ2h0IHJhbmdlLCB0aGUgTG9TVCBzZXJ2ZXIgc2hvdWxkIHJlc3BvbmQgd2l0aCBG TE9PUiBpbiB0aGUgJmx0O2ludmFsaWQmZ3Q7IGxpc3QuICZuYnNwO09uIHRoZSBvdGhlciBoYW5k LCBpZiBGTE9PUiB3YXMgbm90IHByZXNlbnQsIGl0IHdvdWxkbid0IGJlIGFuIGVycm9yLjwvc3Bh bj48L3NwYW4+PG86cD48L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiXDAwMjdU aW1lcyBOZXcgUm9tYW5cMDAyNyInPlJlY2FsbCB0aGF0IHZhbGlkYXRpb24gaXMgYmVzdCBkb25l IHdoZW4gaW5zZXJ0aW5nIGxvY2F0aW9uIGluZm9ybWF0aW9uIGludG8gYSBMSVM7IHdlbGwgYmVm b3JlIGFuIGVtZXJnZW5jeSBjYWxsLiAmbmJzcDtBIGxvY2F0aW9uIHN1aXRhYmxlIGZvciBkaXNw YXRjaCBpcyBhbHNvIHN1aXRhYmxlIGZvciByb3V0aW5nLCBidXQgYSBsb2NhdGlvbiBzdWl0YWJs ZSBmb3Igcm91dGluZyBpcyBub3QgbmVjZXNzYXJpbHkgc3VpdGFibGUgZm9yIGRpc3BhdGNoLiZu YnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBjbGFzcz1hcHBsZS1zdHls ZS1zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiXDAwMjdUaW1lcyBOZXcgUm9tYW5cMDAy NyInPkkgZG9uJ3Qgc2VlIGEgcHJvYmxlbSBoZXJlLiAmbmJzcDtJIHRoaW5rIHRoYXQgdGhlICZx dW90O2FjY2VwdGFibGUgbG9jYXRpb24gc3lzdGVtJnF1b3Q7IGlzIGRldGVybWluZWQgYnkgdGhl IGp1cmlzZGljdGlvbiBwcm92aWRpbmcgdGhlIExvU1Qgc2VydmVyLCBhbmQgaWYgaXQgcmVxdWly ZXMgdmFsaWRhdGlvbiB0byBhIGRpc3BhdGNoYWJsZSBsb2NhdGlvbiwgaXQgY2FuIHJlYXNvbmFi bHkgcmVxdWlyZSB0aGUgTG9TVCBzZXJ2ZXIgdG8gZG8gdGhhdCAoYnkgc3VpdGFibGUgcHJvdmlz aW9uaW5nKS4gJm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFu PiZuYnNwOy1mcmFtZXdvcmsgc2F5cyBleGFjdGx5IHRoZSByaWdodCB0aGluZy48L3NwYW4+PG86 cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJz cDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+T3ZlciBpbiBORU5BLCB3ZSBhcmUgcmVxdWly aW5nIGxvY2F0aW9uIGJlIHZhbGlkIGZvciBkaXNwYXRjaCwgYW5kIHdlIGFyZSBlcXVpcHBpbmcg dGhlIExvU1Qgc2VydmVyIHdpdGggdGhlIGluZm9ybWF0aW9uIG5lZWRlZCB0byBkZXRlcm1pbmUg dGhhdC48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJcMDAyN1RpbWVzIE5ldyBSb21hblwwMDI3Iic+QnJpYW48L3NwYW4+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_8B0A9FCBB9832F43971E38010638454F03F33EA945SISPE7MB1comm_-- From Martin.Thomson@andrew.com Mon Nov 22 18:42:09 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40DF428C192 for ; Mon, 22 Nov 2010 18:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.672 X-Spam-Level: X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sEp45HiYlgZ for ; Mon, 22 Nov 2010 18:42:06 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id CAA5D28C18F for ; Mon, 22 Nov 2010 18:42:02 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:30391 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S38844521Ab0KWCm7 (ORCPT ); Mon, 22 Nov 2010 20:42:59 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 22 Nov 2010 20:42:57 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 23 Nov 2010 10:42:32 +0800 From: "Thomson, Martin" To: Brian Rosen , Hannes Tschofenig Date: Tue, 23 Nov 2010 10:42:29 +0800 Thread-Topic: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! Thread-Index: AcuKVIgZnt5CuRf+SFud93kP1OYM/wASbyQQ Message-ID: <8B0A9FCBB9832F43971E38010638454F03F33EA97D@SISPE7MB1.commscope.com> References: <8B68D4BB-4565-4A78-8AC7-4B044D6BC966@gmx.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: ECRIT Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 02:42:09 -0000 SGF2aW5nIHRva2VucyBhZGRlZCBieSBpbnRlcm1lZGlhcmllcyBpcyBhIGJldHRlciBpZGVhLiAg Rm9yIG9uZSwgaXQgY2FuIGhlbHAgYXZvaWQgdGhlIHByb2JsZW0gd2hlcmUgaW50ZXJtZWRpYXJp ZXMgaGF2ZSB0byBhY2N1bXVsYXRlIHN0YXRlIGluIG9yZGVyIHRvIHJlY29nbml6ZSBsYXRlciBj YWxsYmFja3MuDQoNCkkgdGhpbmsgdGhhdCBjYWxsIGZvcndhcmRpbmcgaXMgYSBzaW1wbGUgZW5v dWdoIGNhc2UsIGFuZCBmaW5kaW5nIGFuIGFwcHJvcHJpYXRlIHBsYWNlIHRvIGF0dGFjaCB0aGUg dG9rZW4gc2hvdWxkIGVuc3VyZSB0aGF0IGl0IHN0YXlzIGF0dGFjaGVkIHRvIHRoZSBmb3J3YXJk ZWQgY2FsbC4gIChOb3QgdG8gcHJlLWVtcHQgYSBzb2x1dGlvbiwgYnV0IGl0IG9jY3VycyB0aGF0 IGEgQ29udGFjdCBVUkkgcGFyYW1ldGVyIG1pZ2h0IHdvcmsgaW4gdGhlIHNhbWUgd2F5IGFzIEdS VVUuKQ0KDQpUaGUgcm91dGUtYXN5bW1ldHJ5IGlzIG1vcmUgZGlmZmljdWx0LCBidXQgaXQgbWln aHQgYmUgbWFkZSBlYXNpZXIgYnkgYW4gYXNzdW1wdGlvbiBhbmQgYSBsaXR0bGUgc29waGlzdGlj YXRlZCBzdGF0ZSBtYW5hZ2VtZW50Lg0KDQpJbXBvcnRhbnQgdG8gbm90ZSB0aGF0IGluIHJvdXRl LWFzeW1tZXRyeSAoYW5kIFBTVE4gaW50ZXJ3b3JraW5nKSBjYXNlcyB0aGF0IHRoZSBvbmx5IHRp bWVzIHRoYXQgYW4gaW50ZXJtZWRpYXJ5IG5lZWRzIHRvIGhhdmUgYWNjZXNzIHRvIGEgdG9rZW4g aXMgd2hlbiBpdCB0cmVhdHMgdGhlIGluY29taW5nIGNhbGwgZGlmZmVyZW50bHkuICAoQnlwYXNz aW5nIHZvaWNlIG1haWwsIHRoYXQgc29ydCBvZiB0aGluZy4pICBJIGV4cGVjdCB0aGF0IG1vc3Qg U0lQIHByb3ZpZGVycyBvbiB0aGUgcGF0aCB3b250IG5lZWQgdG8gdHJlYXQgdGhpcyBjYWxsIHNw ZWNpYWxseSwgc28gYWNjZXNzIHRvIHRoZSB0b2tlbiBpc24ndCBuZWNlc3NhcnkuDQoNClRoZSBt b3N0IGxpa2VseSBuZWVkIGZvciB0b2tlbiBhY2Nlc3MgaXMgZm9yIHRoZSBzZXJ2aWNlIHRoYXQg YSB1c2VyIHN1YnNjcmliZXMgdG8uICBUaGUgc2VydmljZSB0aGF0IG9wZXJhdGVzIHRoZSBkb21h aW4gb2YgdGhlaXIgQW9SLiAgVGhpcyBzZXJ2aWNlIGlzIHRoZSBvbmx5IG9uZSBsaWtlbHkgdG8g ZG8gcG9saWN5LWJhc2VkIHRyZWF0bWVudCBvZiBjYWxscyAodm9pY2UgbWFpbCwgcmVkaXJlY3Qg dG8gYWx0ZXJuYXRpdmUgY29udGFjdCBhbmQgc28gZm9ydGgpLiAgVGhpcyBtZWFucyB0aGF0IGZv ciByb3V0ZSBhc3ltbWV0cnkgd2UgY2FuIGFzc3VtZSB0aGF0IGEgcHJvdmlkZXIgb24gdGhlIGNh bGxiYWNrIHBhdGggb25seSBpcyB1bmxpa2VseSB0byBuZWVkIHRvIHN1YmplY3QgdGhlIGNhbGwg dG8gc3BlY2lhbCBoYW5kbGluZy4gIElmIHRoaXMgYXNzdW1wdGlvbiBpcyBnb29kLCB0aGVuIHRo aXMgdGFnZ2luZyBzY2hlbWUgd29ya3MuDQoNClNvLCBvbiB0aGUgb3V0Ym91bmQgZW1lcmdlbmN5 IGNhbGwgdGhlIGludGVybWVkaWFyeSBpZGVudGlmaWVzIHRoYXQgdGhlIGNhbGwgaXMgYW4gZW1l cmdlbmN5IGNhbGwgKHVybjpzZXJ2aWNlOnNvcyB0cmVlIG9yIGJ5IGxvY2FsbHkgZGVmaW5lZCBt ZWFucykuICBUaGV5IHRhZyB0aGUgY2FsbCB3aXRoIGEgc3BlY2lhbCB0b2tlbi4gIElmIGl0IHdl cmUgbWUsIEknZCBpbmNsdWRlIHRoZSB0aW1lLCBhbnkgc3VwcGxlbWVudGFyeSBpbmZvcm1hdGlv biB0aGV5IHdhbnQgdG8gc2F2ZSAobWF5YmUgZW5jcnlwdGVkIHRvIHNoaWVsZCBmcm9tIHByeWlu ZyBleWVzKSwgYW5kIHNvbWUgZm9ybSBvZiBpbnRlZ3JpdHkgcHJvdGVjdGlvbi4NCg0KT24gdGhl IGNhbGxiYWNrLCBhIGRpZmZlcmVudCBpbnRlcm1lZGlhcnkgZ2V0cyB0aGUgY2FsbGJhY2ssIGJ1 dCB0aGV5IGtub3cgYWJvdXQgdGhlIHRhZ2dpbmcgYW5kIGhhdmUgdGhlIG1lYW5zIHRvIGlkZW50 aWZ5IHRoZSBpbnRlZ3JpdHktcHJvdGVjdGVkIHRhZyAoYW5kIHRvIGRlY3J5cHQgdGhlIG5lY2Vz c2FyeSBkYXRhKS4gIFRoZXkgZXh0cmFjdCB0aGlzIGluZm9ybWF0aW9uIGFuZCBhcHBseSBsb2Nh bCBwb2xpY3kgdGhhdCBub3cgaGFzIHRoaXMgYWRkaXRpb25hbCBpbnB1dCAodGhlIHRpbWUgb2Yg dGhlIGNhbGwsIGV0Yy4uLikuICBUaHVzLCBjYWxsYmFjayBpcyBhY2hpZXZlZCAob3Igbm90LCBh cyBsb2NhbCBwb2xpY3kgZGljdGF0ZXMpLg0KDQpUaGUgY29uZGl0aW9uIGhlcmUgaXMgdGhhdCBk aWZmZXJlbnQgaW50ZXJtZWRpYXJpZXMgb3BlcmF0ZWQgYnkgdGhlIHNhbWUgcHJvdmlkZXIgYXJl IGFsbCBjb25maWd1cmVkIHdpdGggdGhlIHNhbWUgc2VjcmV0IGtleSBpbmZvcm1hdGlvbiBuZWNl c3NhcnkgdG8gY2hlY2sgdGhlIGludGVncml0eSBvZiB0aGUgdG9rZW4gKGFuZCBkZWNyeXB0KS4N Cg0KVGhpcyB3b3JrcywgdGhvdWdoIEkgaGF2ZSB0byB3b25kZXIgaWYgdGhlIGFkZGl0aW9uYWwg bWVjaGFuaXNtIGlzIG5vdCBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gd2hhdCB3YXMgcHJvcG9zZWQg aW4gLWVjcml0LWRpcmVjdC4NCg0KLS1NYXJ0aW4NCg0KT24gMjAxMC0xMS0yMyBhdCAwMTo0OTo0 MiwgQnJpYW4gUm9zZW4gd3JvdGU6DQo+IElTVE0gdGhhdCBhIHRva2VuIGNvdWxkIGJlIGluc2Vy dGVkIGJ5IGFueSBlbGVtZW50IGluIHRoZSBwYXRoLCBhbmQNCj4gdGhlcmUgY291bGQgYmUgbW9y ZSB0aGFuIG9uZSBvZiB0aGVtLg0KPiANCj4gVHJ5aW5nIHRvIG1ha2UgdGhlIGRldmljZSBmYWJy aWNhdGUgdGhlIHRva2VuIG1heSBvciBtYXkgbm90IG1ha2UNCj4gc2Vuc2UsIGRlcGVuZGluZyBv biB0aGUgY2lyY3Vtc3RhbmNlcy4NCj4gDQo+IEkgdGhpbmsgdGhhdCB0aGUgb25seSBpbXBsaWNh dGlvbnMgYXJlIGF0IHRoZSBQU0FQOiB0aGUgUFNBUCBoYXMgdG8NCj4gaW5jbHVkZSB0aGUgdG9r ZW4ocykgaW4gY2FsbCBmb3J3YXJkaW5nIG9yIGNhbGwgYmFjayBzaXR1YXRpb25zLg0KPiANCj4g QnJpYW4NCj4gDQo+IE9uIE5vdiAyMiwgMjAxMCwgYXQgNzozMSBBTSwgSGFubmVzIFRzY2hvZmVu aWcgd3JvdGU6DQo+IA0KPiA+IEhpIGFsbCwNCj4gPg0KPiA+IHdlIGhhZCBhIGZhaXJseSBnb29k IGRpc2N1c3Npb24gYXQgdGhlIGxhc3QgbWVldGluZyBvbiB0aGUgUFNBUA0KPiBjYWxsYmFjayB0 b3BpYyB0cmlnZ2VyZWQgYnkgYSByZXZpZXcgZnJvbSBDdWxsZW4uIEFzIGEgc3VtbWFyeSB0aGUN Cj4gcXVlc3Rpb24gY2FtZSB1cCB3aGV0aGVyIHdlIGNvdWxkbid0IGZhbGwgYmFjayB0byBhICJ0 b2tlbi1iYXNlZA0KPiBzb2x1dGlvbiBhcHByb2FjaCIuDQo+ID4NCj4gPiBUaGlzIHRva2VuLWJh c2VkIGFwcHJvYWNoIHJvdWdobHkgd29ya3MgYXMgZm9sbG93czogV2hlbiB0aGUNCj4gZW1lcmdl bmN5IGNhbGwgaXMgaW5pdGlhbGx5IG1hZGUgdGhlbiB0aGUgY2FsbGluZyBkZXZpY2UgYXR0YWNo ZXMgc29tZQ0KPiBibG9iIChjYWxsZWQgdGhlIHRva2VuIGhlcmUpIHRoYXQgaXMgdGhlbiBzdG9y ZWQgYXQgaW50ZXJtZWRpYXRlDQo+IGRldmljZXMgYWxvbmcgdGhlIHBhdGggKGZvciBhIGxpbWl0 ZWQgcGVyaW9kIG9mIHRpbWU7IHN1Y2ggYXMgMiBob3VycykuDQo+IFRoZW4sIHdoZW4gYSBjYWxs YmFjayBpcyBtYWRlIHRoZSBzYW1lIGJsb2IgaXMgYXR0YWNoZWQuIFdoZW4gY2hlY2tpbmcNCj4g Zm9yIHRoZSBjYWxsYmFjayB0aGUgcmVjZWl2ZWQgYmxvYiBpcyBjb21wYXJlZCB3aXRoIHRoZSBz dG9yZWQgb25lIGFuZA0KPiBpZiB0aGV5IG1hdGNoIGJldHRlciB0cmVhdG1lbnQgaXMgcHJvdmlk ZWQgdG8gdGhlIGNhbGxiYWNrIChvdGhlcndpc2UNCj4gdGhlIGNhbGwgd291bGQgYmUgdHJlYXRl ZCBhcyBhbnkgb3RoZXIgY2FsbCB0aGF0IGhhcyBubyBtYXJraW5nDQo+IGF0dGFjaGVkIGF0IGFs bCkuDQo+ID4NCj4gPiBUaGUgaW1wbGljYXRpb24gb2YgdGhpcyBkZXNpZ24gaXMgdGhlIGZvbGxv d2luZzogU2VjdGlvbiAxIG9mDQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtZWNyaXQtcHNhcC1jYWxsYmFjay0wMiBsaXN0cyBhDQo+IGNvdXBsZSBvZiBjYXNlcyB3aGVy ZSB0aGUgY3VycmVudGx5IGRlc2NyaWJlZCBzb2x1dGlvbiBmcm9tIHRoZQ0KPiBQaG9uZUJDUCBk b2N1bWVudCBkb2VzIG5vdCB3b3JrLiBXaXRoIHRoZSB0b2tlbiBiYXNlZCBhcHByb2FjaCB0aGUN Cj4gZm9sbG93aW5nIGFzc3VtcHRpb25zIGhhdmUgdG8gYmUgbWFkZSByZWdhcmRpbmcgdGhlIHN5 bmNocm9uaXphdGlvbiBvZg0KPiB0aGUgdG9rZW4gYmV0d2VlbiBkaWZmZXJlbnQgZW50aXRpZXM6 DQo+ID4NCj4gPiBfIFNlY3Rpb24gMS4xOiAgUm91dGUgQXN5bW1ldHJ5DQo+ID4NCj4gPiAgIFRo ZSB0b2tlbiBoYXMgdG8gYmUgc2hhcmVkIGJldHdlZW4gdGhlIGluYm91bmQgYW5kIHRoZSBvdXRi b3VuZA0KPiBwcm94eS4NCj4gPg0KPiA+IC0gU2VjdGlvbiAxLjI6IE11bHRpLVN0YWdlIFJlc29s dXRpb24NCj4gPg0KPiA+ICAgTm8gYWRkaXRpb25hbCBjb25zaWRlcmF0aW9ucw0KPiA+DQo+ID4g LSBTZWN0aW9uIDEuMzogIENhbGwgRm9yd2FyZGluZw0KPiA+DQo+ID4gICBJbiBhIGNhbGwgZm9y d2FyZGluZyBzY2VuYXJpbyB0aGUgdG9rZW4gbmVlZHMgdG8gYmUgZm9yd2FyZGVkIGFzDQo+IHdl bGwuDQo+ID4NCj4gPiAtIFNlY3Rpb24gMS40OiAgUFNUTiBJbnRlcndvcmtpbmcNCj4gPg0KPiA+ ICBJbiB0aGlzIHNjZW5hcmlvIHRoZSB0b2tlbiB3b3VsZCBub3QgYmUgZm9yd2FyZGVkIHRvIHRo ZSBQU1ROIGRldmljZQ0KPiBhbmQgaGVuY2UgbWF5IG5vdCBiZSBhdmFpbGFibGUgZm9yIHRoZSBj YWxsYmFjay4gQXMgc3VjaCwgdGhlIHRva2VuIGhhcw0KPiB0byBiZSBzaGFyZWQgYmV0d2VlbiB0 aGUgdHdvIFBTVE4tVm9JUCBnYXRld2F5cy4NCj4gPg0KPiA+IC0gU2VjdGlvbiAxLjU6ICBOZXR3 b3JrLWJhc2VkIFNlcnZpY2UgVVJOIFJlc29sdXRpb24NCj4gPg0KPiA+ICAgTm8gYWRkaXRpb25h bCBjb25zaWRlcmF0aW9ucw0KPiA+DQo+ID4gSWYgdGhlcmUgYXJlIG5vIG9iamVjdGlvbnMgd2l0 aCB0aGUgc3VnZ2VzdGVkIGFwcHJvYWNoIChub3Igd2l0aCB0aGUNCj4gcG90ZW50aWFsIHJlcXVp cmVtZW50IGZvciBzdGF0ZSBzeW5jaHJvbml6YXRpb24pIHRoZW4gSSB3aWxsIG1ha2UgdGhlDQo+ IGNoYW5nZXMgd2l0aCB0aGUgbmV4dCBkcmFmdCB1cGRhdGUuDQo+ID4NCj4gPiBQbGVhc2UgcmVz cG9uZCBieSB0aGUgZW5kIG9mIHRoZSB3ZWVrIGlmIHlvdSBoYXZlIG9iamVjdGlvbnMhDQo+ID4N Cj4gPiBDaWFvDQo+ID4gSGFubmVzDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEVjcml0IG1haWxpbmcgbGlzdA0KPiA+IEVjcml0 QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3Jp dA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+IEVjcml0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KDQo= From christer.holmberg@ericsson.com Tue Nov 23 00:16:34 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B7F28C1A3 for ; Tue, 23 Nov 2010 00:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.69 X-Spam-Level: X-Spam-Status: No, score=-6.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq4q7z92luqR for ; Tue, 23 Nov 2010 00:16:32 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id E311C28C1AC for ; Tue, 23 Nov 2010 00:16:31 -0800 (PST) X-AuditID: c1b4fb3d-b7c05ae0000028e7-2d-4ceb78979da4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id FB.53.10471.8987BEC4; Tue, 23 Nov 2010 09:17:28 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 23 Nov 2010 09:17:27 +0100 From: Christer Holmberg To: Hannes Tschofenig , ECRIT Date: Tue, 23 Nov 2010 09:17:27 +0100 Thread-Topic: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! Thread-Index: AcuKQSrnl5neuBOBR3Ci7oBxnNaldwApQ+6g Message-ID: <7F2072F1E0DE894DA4B517B93C6A058503033AA5@ESESSCMS0356.eemea.ericsson.se> References: <8B68D4BB-4565-4A78-8AC7-4B044D6BC966@gmx.net> In-Reply-To: <8B68D4BB-4565-4A78-8AC7-4B044D6BC966@gmx.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: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 08:16:34 -0000 Hi, In my opinion the "blob" approach would not work for IMS. The reasons are: 1. In the beginning, the vast majority of the cases will be PSTN breakouts.= =20 (I think a solution that doesn't support PSTN would be useless in lots of n= on-IMS networks also.) 2. Emergency is a local service, and in roaming scenarios the only node tha= t could store this "blob" is the P-CSCF in the visited network. But, the ps= ap emergency callback must be detected before it reaches the visited P-CSCF= , already in the home network (e.g. in order to disable services), which wi= ll receive the callback and then route it back to the visited network where= the calling user is located. Regards, Christer=20 =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Hannes Tschofenig > Sent: 22. marraskuuta 2010 14:31 > To: ECRIT > Cc: Hannes Tschofenig > Subject: [Ecrit] PSAP Callback: Pending Draft Update -=20 > Feedback needed! >=20 > Hi all,=20 >=20 > we had a fairly good discussion at the last meeting on the=20 > PSAP callback topic triggered by a review from Cullen. As a=20 > summary the question came up whether we couldn't fall back to=20 > a "token-based solution approach". >=20 > This token-based approach roughly works as follows: When the=20 > emergency call is initially made then the calling device=20 > attaches some blob (called the token here) that is then=20 > stored at intermediate devices along the path (for a limited=20 > period of time; such as 2 hours). Then, when a callback is=20 > made the same blob is attached. When checking for the=20 > callback the received blob is compared with the stored one=20 > and if they match better treatment is provided to the=20 > callback (otherwise the call would be treated as any other=20 > call that has no marking attached at all).=20 >=20 > The implication of this design is the following: Section 1 of=20 > http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02=20 > lists a couple of cases where the currently described=20 > solution from the PhoneBCP document does not work. With the=20 > token based approach the following assumptions have to be=20 > made regarding the synchronization of the token between=20 > different entities:=20 >=20 > _ Section 1.1: Route Asymmetry >=20 > The token has to be shared between the inbound and the=20 > outbound proxy. =20 >=20 > - Section 1.2: Multi-Stage Resolution >=20 > No additional considerations=20 >=20 > - Section 1.3: Call Forwarding >=20 > In a call forwarding scenario the token needs to be=20 > forwarded as well.=20 >=20 > - Section 1.4: PSTN Interworking >=20 > In this scenario the token would not be forwarded to the=20 > PSTN device and hence may not be available for the callback.=20 > As such, the token has to be shared between the two PSTN-VoIP=20 > gateways.=20 >=20 > - Section 1.5: Network-based Service URN Resolution >=20 > No additional considerations=20 > =20 > If there are no objections with the suggested approach (nor=20 > with the potential requirement for state synchronization)=20 > then I will make the changes with the next draft update.=20 >=20 > Please respond by the end of the week if you have objections! >=20 > Ciao > Hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From hannes.tschofenig@gmx.net Tue Nov 23 00:29:09 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48B628C130 for ; Tue, 23 Nov 2010 00:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.336 X-Spam-Level: X-Spam-Status: No, score=-102.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRUpIkr-7tR8 for ; Tue, 23 Nov 2010 00:29:07 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 761E628C112 for ; Tue, 23 Nov 2010 00:29:05 -0800 (PST) Received: (qmail invoked by alias); 23 Nov 2010 08:30:01 -0000 Received: from unknown (EHLO [10.255.128.169]) [192.100.123.77] by mail.gmx.net (mp006) with SMTP; 23 Nov 2010 09:30:01 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18g0t1NvBsgyj77q/+14g2jan3H+P0Ydo3Yalo8NC kAE2mil22rM/iz Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058503033AA5@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 23 Nov 2010 10:29:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B68D4BB-4565-4A78-8AC7-4B044D6BC966@gmx.net> <7F2072F1E0DE894DA4B517B93C6A058503033AA5@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig , ECRIT Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 08:29:09 -0000 Item (2) is the feedback I recall from discussions earlier this year = that had lead us to explore solutions beyond the token-based approach.=20= For the callback there is, however, the question whether this would = indeed be routed through the home network or rather through the visited = network. Furthermore, why wouldn't the visited and the home network be = able to share the token given that they share many other things as well.=20= The PSTN case is a bit more complicated particularly since the current = PSTN does not have a solution that would be equivalent. So, is it useful = to have a solution for the PSTN case at all?=20 On Nov 23, 2010, at 10:17 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > In my opinion the "blob" approach would not work for IMS. The reasons = are: >=20 > 1. In the beginning, the vast majority of the cases will be PSTN = breakouts.=20 >=20 > (I think a solution that doesn't support PSTN would be useless in lots = of non-IMS networks also.) >=20 > 2. Emergency is a local service, and in roaming scenarios the only = node that could store this "blob" is the P-CSCF in the visited network. = But, the psap emergency callback must be detected before it reaches the = visited P-CSCF, already in the home network (e.g. in order to disable = services), which will receive the callback and then route it back to the = visited network where the calling user is located. >=20 > Regards, >=20 > Christer=20 >=20 >=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >> On Behalf Of Hannes Tschofenig >> Sent: 22. marraskuuta 2010 14:31 >> To: ECRIT >> Cc: Hannes Tschofenig >> Subject: [Ecrit] PSAP Callback: Pending Draft Update -=20 >> Feedback needed! >>=20 >> Hi all,=20 >>=20 >> we had a fairly good discussion at the last meeting on the=20 >> PSAP callback topic triggered by a review from Cullen. As a=20 >> summary the question came up whether we couldn't fall back to=20 >> a "token-based solution approach". >>=20 >> This token-based approach roughly works as follows: When the=20 >> emergency call is initially made then the calling device=20 >> attaches some blob (called the token here) that is then=20 >> stored at intermediate devices along the path (for a limited=20 >> period of time; such as 2 hours). Then, when a callback is=20 >> made the same blob is attached. When checking for the=20 >> callback the received blob is compared with the stored one=20 >> and if they match better treatment is provided to the=20 >> callback (otherwise the call would be treated as any other=20 >> call that has no marking attached at all).=20 >>=20 >> The implication of this design is the following: Section 1 of=20 >> http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02=20 >> lists a couple of cases where the currently described=20 >> solution from the PhoneBCP document does not work. With the=20 >> token based approach the following assumptions have to be=20 >> made regarding the synchronization of the token between=20 >> different entities:=20 >>=20 >> _ Section 1.1: Route Asymmetry >>=20 >> The token has to be shared between the inbound and the=20 >> outbound proxy. =20 >>=20 >> - Section 1.2: Multi-Stage Resolution >>=20 >> No additional considerations=20 >>=20 >> - Section 1.3: Call Forwarding >>=20 >> In a call forwarding scenario the token needs to be=20 >> forwarded as well.=20 >>=20 >> - Section 1.4: PSTN Interworking >>=20 >> In this scenario the token would not be forwarded to the=20 >> PSTN device and hence may not be available for the callback.=20 >> As such, the token has to be shared between the two PSTN-VoIP=20 >> gateways.=20 >>=20 >> - Section 1.5: Network-based Service URN Resolution >>=20 >> No additional considerations=20 >>=20 >> If there are no objections with the suggested approach (nor=20 >> with the potential requirement for state synchronization)=20 >> then I will make the changes with the next draft update.=20 >>=20 >> Please respond by the end of the week if you have objections! >>=20 >> Ciao >> Hannes >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 From christer.holmberg@ericsson.com Tue Nov 23 04:08:52 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886BB3A693A for ; Tue, 23 Nov 2010 04:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.682 X-Spam-Level: X-Spam-Status: No, score=-6.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FG8XQOJ5Tkpo for ; Tue, 23 Nov 2010 04:08:51 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2459F3A693B for ; Tue, 23 Nov 2010 04:08:49 -0800 (PST) X-AuditID: c1b4fb3d-b7c05ae0000028e7-18-4cebaef5e859 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BE.0D.10471.5FEABEC4; Tue, 23 Nov 2010 13:09:25 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 23 Nov 2010 13:09:25 +0100 From: Christer Holmberg To: Hannes Tschofenig Date: Tue, 23 Nov 2010 13:09:24 +0100 Thread-Topic: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! Thread-Index: AcuK6J+6+6WvbXNKTWGzeqSXpxQDNAAHkHSg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850307D163@ESESSCMS0356.eemea.ericsson.se> References: <8B68D4BB-4565-4A78-8AC7-4B044D6BC966@gmx.net> <7F2072F1E0DE894DA4B517B93C6A058503033AA5@ESESSCMS0356.eemea.ericsson.se> 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 Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 12:08:52 -0000 =20 Hi, >Item (2) is the feedback I recall from discussions earlier this year=20 >that had lead us to explore solutions beyond the token-based approach. So, based on what is it now suggested that ECRIT should consider Item (2) a= s a non-valid case to solve? >For the callback there is, however, the question whether this would=20 >indeed be routed through the home network or rather through the visited=20 >network. I am not sure I understand. Maybe such networks exists somewhere, but the n= etworks I am aware of works as following: 1. The callback will be made towards the number from where the emg call was= made, using normal SIP routing procedures, and ENUM/SIP-URI will always po= int towards the home network. 2. A PSTN network has no clue in what visited network the calling IMS user = is located, so the callback will always be routed towards the home network. >Furthermore, why wouldn't the visited and the home network be able to=20 >share the token given that they share many other things as well. First, it is not enough to share the token. There must also be a way for th= e home network to associate a specific callback with a specific token. So, = the token would need to be associated with the number of the calling UA, so= that the callback made towards that number can then be associated with the= blob associated with that UA. Second, it is not enough to be able to associate the callback with the toke= n. The home network needs to know that the call is a callback in the first = place.=20 In some cases the MGCF determines that based on received ISUP indicator. In other case the MGCF determines that based on number analysis. So, yes, the MGCF could probably determine that the call is callback, and i= nsert the token, rather than a generic callback indicator. But, that would = require that not only the home S-CSCF, but also the home MGCF(s) (and maybe= other border nodes in the home network) have the token/UA_number informati= on, which makes things even more complex. Technically it might be possible to come up with a solution for this, but I= don't see why the token solution as such is so superior that it would be w= orth all the trouble. But, maybe I've missed something. >The PSTN case is a bit more complicated particularly since the current=20 >PSTN does not have a solution that would be equivalent. So, is it=20 >useful to have a solution for the PSTN case at all? As I said, I think that PSTN breakout will be the most common case for a co= nsiderable time to come, and a solution that doesn't support that is not fe= asible in real networks. Regards, Christer > On Nov 23, 2010, at 10:17 AM, Christer Holmberg wrote: >=20 > >=20 > > Hi, > >=20 > > In my opinion the "blob" approach would not work for IMS.=20 > The reasons are: > >=20 > > 1. In the beginning, the vast majority of the cases will be=20 > PSTN breakouts.=20 > >=20 > > (I think a solution that doesn't support PSTN would be=20 > useless in lots=20 > > of non-IMS networks also.) > >=20 > > 2. Emergency is a local service, and in roaming scenarios=20 > the only node that could store this "blob" is the P-CSCF in=20 > the visited network. But, the psap emergency callback must be=20 > detected before it reaches the visited P-CSCF, already in the=20 > home network (e.g. in order to disable services), which will=20 > receive the callback and then route it back to the visited=20 > network where the calling user is located. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > >> Behalf Of Hannes Tschofenig > >> Sent: 22. marraskuuta 2010 14:31 > >> To: ECRIT > >> Cc: Hannes Tschofenig > >> Subject: [Ecrit] PSAP Callback: Pending Draft Update - Feedback=20 > >> needed! > >>=20 > >> Hi all, > >>=20 > >> we had a fairly good discussion at the last meeting on the PSAP=20 > >> callback topic triggered by a review from Cullen. As a summary the=20 > >> question came up whether we couldn't fall back to a "token-based=20 > >> solution approach". > >>=20 > >> This token-based approach roughly works as follows: When the=20 > >> emergency call is initially made then the calling device attaches=20 > >> some blob (called the token here) that is then stored at=20 > intermediate=20 > >> devices along the path (for a limited period of time; such as 2=20 > >> hours). Then, when a callback is made the same blob is=20 > attached. When=20 > >> checking for the callback the received blob is compared with the=20 > >> stored one and if they match better treatment is provided to the=20 > >> callback (otherwise the call would be treated as any other=20 > call that=20 > >> has no marking attached at all). > >>=20 > >> The implication of this design is the following: Section 1 of > >> http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 > >> lists a couple of cases where the currently described=20 > solution from=20 > >> the PhoneBCP document does not work. With the token based approach=20 > >> the following assumptions have to be made regarding the=20 > >> synchronization of the token between different entities: > >>=20 > >> _ Section 1.1: Route Asymmetry > >>=20 > >> The token has to be shared between the inbound and the outbound=20 > >> proxy. > >>=20 > >> - Section 1.2: Multi-Stage Resolution > >>=20 > >> No additional considerations > >>=20 > >> - Section 1.3: Call Forwarding > >>=20 > >> In a call forwarding scenario the token needs to be forwarded as=20 > >> well. > >>=20 > >> - Section 1.4: PSTN Interworking > >>=20 > >> In this scenario the token would not be forwarded to the=20 > PSTN device=20 > >> and hence may not be available for the callback. > >> As such, the token has to be shared between the two PSTN-VoIP=20 > >> gateways. > >>=20 > >> - Section 1.5: Network-based Service URN Resolution > >>=20 > >> No additional considerations > >>=20 > >> If there are no objections with the suggested approach=20 > (nor with the=20 > >> potential requirement for state synchronization) then I=20 > will make the=20 > >> changes with the next draft update. > >>=20 > >> Please respond by the end of the week if you have objections! > >>=20 > >> Ciao > >> Hannes > >>=20 > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >>=20 >=20 > = From hannes.tschofenig@nsn.com Tue Nov 23 04:16:07 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9E323A68FD for ; Tue, 23 Nov 2010 04:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.946 X-Spam-Level: X-Spam-Status: No, score=-101.946 tagged_above=-999 required=5 tests=[AWL=0.654, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCnSerBVx3cY for ; Tue, 23 Nov 2010 04:16:05 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id C4BF53A6924 for ; Tue, 23 Nov 2010 04:16:04 -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 oANCGuVj013067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Nov 2010 13:16:56 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id oANCGsm9025664; Tue, 23 Nov 2010 13:16:56 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Nov 2010 13:16:40 +0100 Received: from 10.144.242.208 ([10.144.242.208]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.35]) with Microsoft Exchange Server HTTP-DAV ; Tue, 23 Nov 2010 12:16:38 +0000 User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Tue, 23 Nov 2010 14:16:38 +0200 From: Hannes Tschofenig To: ext Christer Holmberg , Hannes Tschofenig Message-ID: Thread-Topic: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! Thread-Index: AcuK6J+6+6WvbXNKTWGzeqSXpxQDNAAHkHSgAABZZzU= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850307D163@ESESSCMS0356.eemea.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Nov 2010 12:16:40.0115 (UTC) FILETIME=[486AD030:01CB8B08] Cc: ECRIT Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 12:16:07 -0000 Hi Christer, > Hi, > >> Item (2) is the feedback I recall from discussions earlier this year >> that had lead us to explore solutions beyond the token-based approach. > > So, based on what is it now suggested that ECRIT should consider Item (2) as a > non-valid case to solve? This was the suggestion that was raised during the meeting. Hence, I have posted a mail to discuss this issue on the list. > >> For the callback there is, however, the question whether this would >> indeed be routed through the home network or rather through the visited >> network. > > I am not sure I understand. Maybe such networks exists somewhere, but the > networks I am aware of works as following: > > 1. The callback will be made towards the number from where the emg call was > made, using normal SIP routing procedures, and ENUM/SIP-URI will always point > towards the home network. We have to differentiate between the AoR and the GRUU. > > 2. A PSTN network has no clue in what visited network the calling IMS user is > located, so the callback will always be routed towards the home network. Let us treat the PSTN case different from the other scenario. > >> Furthermore, why wouldn't the visited and the home network be able to >> share the token given that they share many other things as well. > > First, it is not enough to share the token. There must also be a way for the > home network to associate a specific callback with a specific token. So, the > token would need to be associated with the number of the calling UA, so that > the callback made towards that number can then be associated with the blob > associated with that UA. Not necessarily. The suggestion was to use a token and not necessarily to tie it to any identifier > > Second, it is not enough to be able to associate the callback with the token. > The home network needs to know that the call is a callback in the first place. You mean there additionally needs to be a marking that the call is indeed a callback related to an emergency. That's OK. > > In some cases the MGCF determines that based on received ISUP indicator. > > In other case the MGCF determines that based on number analysis. > > So, yes, the MGCF could probably determine that the call is callback, and > insert the token, rather than a generic callback indicator. But, that would > require that not only the home S-CSCF, but also the home MGCF(s) (and maybe > other border nodes in the home network) have the token/UA_number information, > which makes things even more complex. > > Technically it might be possible to come up with a solution for this, but I > don't see why the token solution as such is so superior that it would be worth > all the trouble. But, maybe I've missed something. The difference is the security story around it. > >> The PSTN case is a bit more complicated particularly since the current >> PSTN does not have a solution that would be equivalent. So, is it >> useful to have a solution for the PSTN case at all? > > As I said, I think that PSTN breakout will be the most common case for a > considerable time to come, and a solution that doesn't support that is not > feasible in real networks. I am not sure how the PSTN case is supposed to work given that the first VoIP-PSTN gateway by magic has to determine whether the outgoing call is a callback or any other call that happens to come from the PSTN. Ciao Hannes > > Regards, > > Christer > > > > >> On Nov 23, 2010, at 10:17 AM, Christer Holmberg wrote: >> >>> >>> Hi, >>> >>> In my opinion the "blob" approach would not work for IMS. >> The reasons are: >>> >>> 1. In the beginning, the vast majority of the cases will be >> PSTN breakouts. >>> >>> (I think a solution that doesn't support PSTN would be >> useless in lots >>> of non-IMS networks also.) >>> >>> 2. Emergency is a local service, and in roaming scenarios >> the only node that could store this "blob" is the P-CSCF in >> the visited network. But, the psap emergency callback must be >> detected before it reaches the visited P-CSCF, already in the >> home network (e.g. in order to disable services), which will >> receive the callback and then route it back to the visited >> network where the calling user is located. >>> >>> Regards, >>> >>> Christer >>> >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf Of Hannes Tschofenig >>>> Sent: 22. marraskuuta 2010 14:31 >>>> To: ECRIT >>>> Cc: Hannes Tschofenig >>>> Subject: [Ecrit] PSAP Callback: Pending Draft Update - Feedback >>>> needed! >>>> >>>> Hi all, >>>> >>>> we had a fairly good discussion at the last meeting on the PSAP >>>> callback topic triggered by a review from Cullen. As a summary the >>>> question came up whether we couldn't fall back to a "token-based >>>> solution approach". >>>> >>>> This token-based approach roughly works as follows: When the >>>> emergency call is initially made then the calling device attaches >>>> some blob (called the token here) that is then stored at >> intermediate >>>> devices along the path (for a limited period of time; such as 2 >>>> hours). Then, when a callback is made the same blob is >> attached. When >>>> checking for the callback the received blob is compared with the >>>> stored one and if they match better treatment is provided to the >>>> callback (otherwise the call would be treated as any other >> call that >>>> has no marking attached at all). >>>> >>>> The implication of this design is the following: Section 1 of >>>> http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 >>>> lists a couple of cases where the currently described >> solution from >>>> the PhoneBCP document does not work. With the token based approach >>>> the following assumptions have to be made regarding the >>>> synchronization of the token between different entities: >>>> >>>> _ Section 1.1: Route Asymmetry >>>> >>>> The token has to be shared between the inbound and the outbound >>>> proxy. >>>> >>>> - Section 1.2: Multi-Stage Resolution >>>> >>>> No additional considerations >>>> >>>> - Section 1.3: Call Forwarding >>>> >>>> In a call forwarding scenario the token needs to be forwarded as >>>> well. >>>> >>>> - Section 1.4: PSTN Interworking >>>> >>>> In this scenario the token would not be forwarded to the >> PSTN device >>>> and hence may not be available for the callback. >>>> As such, the token has to be shared between the two PSTN-VoIP >>>> gateways. >>>> >>>> - Section 1.5: Network-based Service URN Resolution >>>> >>>> No additional considerations >>>> >>>> If there are no objections with the suggested approach >> (nor with the >>>> potential requirement for state synchronization) then I >> will make the >>>> changes with the next draft update. >>>> >>>> Please respond by the end of the week if you have objections! >>>> >>>> Ciao >>>> Hannes >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >> >> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Tue Nov 23 05:24:48 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605C03A693E for ; Tue, 23 Nov 2010 05:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.676 X-Spam-Level: X-Spam-Status: No, score=-6.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wPc-qGoGOfE for ; Tue, 23 Nov 2010 05:24:32 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id F019B3A6939 for ; Tue, 23 Nov 2010 05:24:31 -0800 (PST) X-AuditID: c1b4fb39-b7cabae000005002-cb-4cebc0c8d377 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 69.5E.20482.8C0CBEC4; Tue, 23 Nov 2010 14:25:28 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 23 Nov 2010 14:25:28 +0100 From: Christer Holmberg To: Hannes Tschofenig , Hannes Tschofenig Date: Tue, 23 Nov 2010 14:25:27 +0100 Thread-Topic: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! Thread-Index: AcuK6J+6+6WvbXNKTWGzeqSXpxQDNAAHkHSgAABZZzUAAlGuMA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850307D245@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850307D163@ESESSCMS0356.eemea.ericsson.se> 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 Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 13:24:48 -0000 Hi, >>>Item (2) is the feedback I recall from discussions earlier this year=20 >>>that had lead us to explore solutions beyond the token-based=20 >>>approach. >>=20 >>So, based on what is it now suggested that ECRIT should consider Item=20 >>(2) as a non-valid case to solve? >=20 >This was the suggestion that was raised during the meeting.=20 >Hence, I have posted a mail to discuss this issue on the list. I was not able to participate in the ECRIT session, but I will take a look = at the minutes for the reasoning. >>>For the callback there is, however, the question whether this would=20 >>>indeed be routed through the home network or rather through the=20 >>>visited network. >>=20 >>I am not sure I understand. Maybe such networks exists somewhere, but=20 >>the networks I am aware of works as following: >>=20 >>1. The callback will be made towards the number from where the emg=20 >>call was made, using normal SIP routing procedures, and ENUM/SIP-URI=20 >>will always point towards the home network. >=20 >We have to differentiate between the AoR and the GRUU. In IMS even a gruu will be routed via the home network. >>2. A PSTN network has no clue in what visited network the calling IMS=20 >>user is located, so the callback will always be routed towards the=20 >>home network. >=20 >Let us treat the PSTN case different from the other scenario. Fair enough, but I hope that we will not end up defining a separate mechani= sm for PSTN. For example, gruu does not work with PSTN. >>>Furthermore, why wouldn't the visited and the home network be able to=20 >>>share the token given that they share many other things as well. >>=20 >>First, it is not enough to share the token. There must also be a way=20 >>for the home network to associate a specific callback with a specific=20 >>token. So, the token would need to be associated with the number of=20 >>the calling UA, so that the callback made towards that number can then=20 >>be associated with the blob associated with that UA. >=20 >Not necessarily. The suggestion was to use a token and not necessarily=20 >to tie it to any identifier So, a specific network would use the same token value for all emergency cal= ls? But, even in that case the home network entity that determines that the= call is callback needs to know in which visited network the call is going = to end up, in order to insert the token value associated with that network.= The border entities (MGCF/IBCF) do not have that information. >>Second, it is not enough to be able to associate the callback with the to= ken.=20 >>The home network needs to know that the call is a callback in the first p= lace. >=20 >You mean there additionally needs to be a marking that the call is=20 >indeed a callback related to an emergency. That's OK. Yes. The home network needs to know, in order to e.g. disable services that= normally would be enabled for the UE. >>In some cases the MGCF determines that based on received ISUP indicator. >>=20 >>In other case the MGCF determines that based on number analysis. >>=20 >>So, yes, the MGCF could probably determine that the call is callback,=20 >>and insert the token, rather than a generic callback indicator. But,=20 >>that would require that not only the home S-CSCF, but also the home >>MGCF(s) (and maybe other border nodes in the home network) have the=20 >>token/UA_number information, which makes things even more complex. >>=20 >>Technically it might be possible to come up with a solution for this,=20 >>but I don't see why the token solution as such is so superior that it=20 >>would be worth all the trouble. But, maybe I've missed something. >=20 >The difference is the security story around it. Are you talking about the case where a normal use could fake a callback by = inserting the indicator? If the home network uses number analysis to determine that a call is fallba= ck, then it will also detect fake callbacks. This is no different from othe= r types of priority calls. =20 >>>The PSTN case is a bit more complicated particularly since the=20 >>>current PSTN does not have a solution that would be equivalent. So,=20 >>>is it useful to have a solution for the PSTN case at all? >>=20 >>As I said, I think that PSTN breakout will be the most common case for=20 >>a considerable time to come, and a solution that doesn't support that=20 >>is not feasible in real networks. >=20 >I am not sure how the PSTN case is supposed to work given that the=20 >first VoIP-PSTN gateway by magic has to determine whether the outgoing=20 >call is a callback or any other call that happens to come from the=20 >PSTN. In some ISUP variants there is an indicator. In other cases, number analysi= s is used. Regards, Christer =20 > >> On Nov 23, 2010, at 10:17 AM, Christer Holmberg wrote: > >>=20 > >>>=20 > >>> Hi, > >>>=20 > >>> In my opinion the "blob" approach would not work for IMS. > >> The reasons are: > >>>=20 > >>> 1. In the beginning, the vast majority of the cases will be > >> PSTN breakouts.=20 > >>>=20 > >>> (I think a solution that doesn't support PSTN would be > >> useless in lots > >>> of non-IMS networks also.) > >>>=20 > >>> 2. Emergency is a local service, and in roaming scenarios > >> the only node that could store this "blob" is the P-CSCF in the=20 > >> visited network. But, the psap emergency callback must be detected=20 > >> before it reaches the visited P-CSCF, already in the home network=20 > >> (e.g. in order to disable services), which will receive=20 > the callback=20 > >> and then route it back to the visited network where the=20 > calling user=20 > >> is located. > >>>=20 > >>> Regards, > >>>=20 > >>> Christer > >>>=20 > >>>=20 > >>>> -----Original Message----- > >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > >>>> Behalf Of Hannes Tschofenig > >>>> Sent: 22. marraskuuta 2010 14:31 > >>>> To: ECRIT > >>>> Cc: Hannes Tschofenig > >>>> Subject: [Ecrit] PSAP Callback: Pending Draft Update - Feedback=20 > >>>> needed! > >>>>=20 > >>>> Hi all, > >>>>=20 > >>>> we had a fairly good discussion at the last meeting on the PSAP=20 > >>>> callback topic triggered by a review from Cullen. As a=20 > summary the=20 > >>>> question came up whether we couldn't fall back to a "token-based=20 > >>>> solution approach". > >>>>=20 > >>>> This token-based approach roughly works as follows: When the=20 > >>>> emergency call is initially made then the calling device=20 > attaches=20 > >>>> some blob (called the token here) that is then stored at > >> intermediate > >>>> devices along the path (for a limited period of time; such as 2=20 > >>>> hours). Then, when a callback is made the same blob is > >> attached. When > >>>> checking for the callback the received blob is compared with the=20 > >>>> stored one and if they match better treatment is provided to the=20 > >>>> callback (otherwise the call would be treated as any other > >> call that > >>>> has no marking attached at all). > >>>>=20 > >>>> The implication of this design is the following: Section 1 of > >>>> http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02 > >>>> lists a couple of cases where the currently described > >> solution from > >>>> the PhoneBCP document does not work. With the token=20 > based approach=20 > >>>> the following assumptions have to be made regarding the=20 > >>>> synchronization of the token between different entities: > >>>>=20 > >>>> _ Section 1.1: Route Asymmetry > >>>>=20 > >>>> The token has to be shared between the inbound and the=20 > outbound=20 > >>>> proxy. > >>>>=20 > >>>> - Section 1.2: Multi-Stage Resolution > >>>>=20 > >>>> No additional considerations > >>>>=20 > >>>> - Section 1.3: Call Forwarding > >>>>=20 > >>>> In a call forwarding scenario the token needs to be=20 > forwarded as=20 > >>>> well. > >>>>=20 > >>>> - Section 1.4: PSTN Interworking > >>>>=20 > >>>> In this scenario the token would not be forwarded to the > >> PSTN device > >>>> and hence may not be available for the callback. > >>>> As such, the token has to be shared between the two PSTN-VoIP=20 > >>>> gateways. > >>>>=20 > >>>> - Section 1.5: Network-based Service URN Resolution > >>>>=20 > >>>> No additional considerations > >>>>=20 > >>>> If there are no objections with the suggested approach > >> (nor with the > >>>> potential requirement for state synchronization) then I > >> will make the > >>>> changes with the next draft update. > >>>>=20 > >>>> Please respond by the end of the week if you have objections! > >>>>=20 > >>>> Ciao > >>>> Hannes > >>>>=20 > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>=20 > >>=20 > >>=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > = From hannes.tschofenig@nsn.com Tue Nov 23 05:33:01 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 968043A6939 for ; Tue, 23 Nov 2010 05:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyPTTKu415oe for ; Tue, 23 Nov 2010 05:32:52 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 578683A6954 for ; Tue, 23 Nov 2010 05:32:49 -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 oANDXhDw006384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Nov 2010 14:33:43 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id oANDXf41008085; Tue, 23 Nov 2010 14:33:43 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Nov 2010 14:33:39 +0100 Received: from 10.144.242.208 ([10.144.242.208]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.35]) with Microsoft Exchange Server HTTP-DAV ; Tue, 23 Nov 2010 13:33:39 +0000 User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Tue, 23 Nov 2010 15:33:35 +0200 From: Hannes Tschofenig To: ext Christer Holmberg , Hannes Tschofenig Message-ID: Thread-Topic: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! Thread-Index: AcuK6J+6+6WvbXNKTWGzeqSXpxQDNAAHkHSgAABZZzUAAlGuMAAAXk90 In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850307D245@ESESSCMS0356.eemea.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Nov 2010 13:33:40.0148 (UTC) FILETIME=[0A2BE740:01CB8B13] Cc: ECRIT Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 13:33:01 -0000 What are the properties of the design in the PSTN case? Based on what information is the PSTN-VoIP gateway going to put a callback marking on the call? On 11/23/10 3:25 PM, "ext Christer Holmberg" wrote: > Fair enough, but I hope that we will not end up defining a separate mechanism > for PSTN. For example, gruu does not work with PSTN. From christer.holmberg@ericsson.com Tue Nov 23 05:47:14 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 940DD3A6947 for ; Tue, 23 Nov 2010 05:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.67 X-Spam-Level: X-Spam-Status: No, score=-6.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLw6k+GQ2uZH for ; Tue, 23 Nov 2010 05:47:13 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 61C9B28C0D0 for ; Tue, 23 Nov 2010 05:47:13 -0800 (PST) X-AuditID: c1b4fb3d-b7c05ae0000028e7-44-4cebc61ac44d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1A.5C.10471.A16CBEC4; Tue, 23 Nov 2010 14:48:10 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 23 Nov 2010 14:48:10 +0100 From: Christer Holmberg To: Hannes Tschofenig , Hannes Tschofenig Date: Tue, 23 Nov 2010 14:48:09 +0100 Thread-Topic: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! Thread-Index: AcuK6J+6+6WvbXNKTWGzeqSXpxQDNAAHkHSgAABZZzUAAlGuMAAAXk90AABzflA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850307D293@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850307D245@ESESSCMS0356.eemea.ericsson.se> 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 Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 13:47:14 -0000 =20 Hi, >What are the properties of the design in the PSTN case? >=20 >Based on what information is the PSTN-VoIP gateway going to=20 >put a callback marking on the call? Unfortunately I don't have details of that available. I think the informati= on elements have different names depending on countries etc. And, as I said, if no such information element is available, number analysi= s can be used. Regards, Christer From br@brianrosen.net Tue Nov 23 06:05:02 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1782E3A6961 for ; Tue, 23 Nov 2010 06:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.381 X-Spam-Level: X-Spam-Status: No, score=-103.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3AdWdrdEOU7 for ; Tue, 23 Nov 2010 06:05:01 -0800 (PST) Received: from barmail3.idig.net (barmail3.idig.net [64.34.111.253]) by core3.amsl.com (Postfix) with ESMTP id 0D4233A6953 for ; Tue, 23 Nov 2010 06:05:01 -0800 (PST) X-ASG-Debug-ID: 1290521154-357d01c30001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail3.idig.net with ESMTP id 6U5pNyVe0y17X6xb; Tue, 23 Nov 2010 06:05:54 -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.54]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PKtVI-0003K9-LF; Tue, 23 Nov 2010 06:05:53 -0800 Mime-Version: 1.0 (Apple Message framework v1081) X-ASG-Orig-Subj: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850307D293@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 23 Nov 2010 09:05:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05850307D245@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850307D293@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1081) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1290521154 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.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.47462 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: Hannes Tschofenig , Hannes Tschofenig , ECRIT Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 14:05:02 -0000 In every nation I know the details of (which isn't many), the PSTN = affords no special processing to call backs. Having the gateway aware that a call was a call back is not useful in = those countries. Brian On Nov 23, 2010, at 8:48 AM, Christer Holmberg wrote: >=20 > Hi, >=20 >> What are the properties of the design in the PSTN case? >>=20 >> Based on what information is the PSTN-VoIP gateway going to=20 >> put a callback marking on the call? >=20 > Unfortunately I don't have details of that available. I think the = information elements have different names depending on countries etc. >=20 > And, as I said, if no such information element is available, number = analysis can be used. >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Tue Nov 23 06:13:51 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17F103A696C for ; Tue, 23 Nov 2010 06:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.666 X-Spam-Level: X-Spam-Status: No, score=-6.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leShDBpjSoJc for ; Tue, 23 Nov 2010 06:13:50 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B4E963A696D for ; Tue, 23 Nov 2010 06:13:49 -0800 (PST) X-AuditID: c1b4fb39-b7cabae000005002-86-4cebcc56e9e1 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 00.26.20482.65CCBEC4; Tue, 23 Nov 2010 15:14:46 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 23 Nov 2010 15:14:45 +0100 From: Christer Holmberg To: Brian Rosen Date: Tue, 23 Nov 2010 15:14:45 +0100 Thread-Topic: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! Thread-Index: AcuLF47o7NdDLYsFTVicn8vwVqFSWQAAPrhg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850307D2F2@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850307D245@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850307D293@ESESSCMS0356.eemea.ericsson.se> 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: Hannes Tschofenig , Hannes Tschofenig , ECRIT Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 14:13:51 -0000 Hi Brian, Do you agree that the home network in general needs to know (based on whate= ver information) that the call is callback (e.g. in order to disable servic= es etc)?=20 Regards, Christer > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: 23. marraskuuta 2010 16:06 > To: Christer Holmberg > Cc: Hannes Tschofenig; Hannes Tschofenig; ECRIT > Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update -=20 > Feedback needed! >=20 > In every nation I know the details of (which isn't many), the=20 > PSTN affords no special processing to call backs. >=20 > Having the gateway aware that a call was a call back is not=20 > useful in those countries. >=20 > Brian >=20 > On Nov 23, 2010, at 8:48 AM, Christer Holmberg wrote: >=20 > >=20 > > Hi, > >=20 > >> What are the properties of the design in the PSTN case? > >>=20 > >> Based on what information is the PSTN-VoIP gateway going to put a=20 > >> callback marking on the call? > >=20 > > Unfortunately I don't have details of that available. I=20 > think the information elements have different names depending=20 > on countries etc. > >=20 > > And, as I said, if no such information element is=20 > available, number analysis can be used. > >=20 > > Regards, > >=20 > > Christer > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > = From br@brianrosen.net Tue Nov 23 06:27:54 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 152283A6970 for ; Tue, 23 Nov 2010 06:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.397 X-Spam-Level: X-Spam-Status: No, score=-103.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7GTwUu4vm-z for ; Tue, 23 Nov 2010 06:27:52 -0800 (PST) Received: from barmail3.idig.net (barmail3.idig.net [64.34.111.253]) by core3.amsl.com (Postfix) with ESMTP id DB88B3A696C for ; Tue, 23 Nov 2010 06:27:52 -0800 (PST) X-ASG-Debug-ID: 1290522529-357e053f0001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail3.idig.net with ESMTP id qsDDXSl906WwHHX4; Tue, 23 Nov 2010 06:28:49 -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.54]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PKtrS-0001mK-EW; Tue, 23 Nov 2010 06:28:49 -0800 Mime-Version: 1.0 (Apple Message framework v1081) X-ASG-Orig-Subj: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850307D2F2@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 23 Nov 2010 09:28:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05850307D245@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850307D293@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850307D2F2@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1081) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1290522529 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.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.47464 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: Hannes Tschofenig , Hannes Tschofenig , ECRIT Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 14:27:54 -0000 In the present system, this isn't done. I agree it should be done, and therefore, I do want call backs to be = marked. I personally think the token mechanism is the best way to link the = outgoing call with the incoming call for security purposes. I think = that the home/local issue can be solved reasonably. In North America, we will have a PKI which could be used to identify the = emergency services. I'm not sure that will actually be practical = everywhere, so something much more "local" is desirable. =20 Brian On Nov 23, 2010, at 9:14 AM, Christer Holmberg wrote: >=20 > Hi Brian, >=20 > Do you agree that the home network in general needs to know (based on = whatever information) that the call is callback (e.g. in order to = disable services etc)?=20 >=20 > Regards, >=20 > Christer >=20 >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net]=20 >> Sent: 23. marraskuuta 2010 16:06 >> To: Christer Holmberg >> Cc: Hannes Tschofenig; Hannes Tschofenig; ECRIT >> Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update -=20 >> Feedback needed! >>=20 >> In every nation I know the details of (which isn't many), the=20 >> PSTN affords no special processing to call backs. >>=20 >> Having the gateway aware that a call was a call back is not=20 >> useful in those countries. >>=20 >> Brian >>=20 >> On Nov 23, 2010, at 8:48 AM, Christer Holmberg wrote: >>=20 >>>=20 >>> Hi, >>>=20 >>>> What are the properties of the design in the PSTN case? >>>>=20 >>>> Based on what information is the PSTN-VoIP gateway going to put a=20= >>>> callback marking on the call? >>>=20 >>> Unfortunately I don't have details of that available. I=20 >> think the information elements have different names depending=20 >> on countries etc. >>>=20 >>> And, as I said, if no such information element is=20 >> available, number analysis can be used. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 From jgunn6@csc.com Tue Nov 23 08:04:42 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0437D28C14A; Tue, 23 Nov 2010 08:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIfuAHAhPg0m; Tue, 23 Nov 2010 08:04:39 -0800 (PST) Received: from mail63.messagelabs.com (mail63.messagelabs.com [216.82.242.83]) by core3.amsl.com (Postfix) with ESMTP id 9BA5B28C148; Tue, 23 Nov 2010 08:04:38 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-10.tower-63.messagelabs.com!1290528334!115148264!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 6653 invoked from network); 23 Nov 2010 16:05:35 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-10.tower-63.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Nov 2010 16:05:35 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id oANG5YZT002496; Tue, 23 Nov 2010 11:05:34 -0500 In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850307D245@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850307D163@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850307D245@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg MIME-Version: 1.0 X-KeepSent: E22AC6B4:52F04970-852577E4:0057EA2B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Tue, 23 Nov 2010 11:05:25 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.1FP1 HF440|June 18, 2010) at 11/23/2010 11:05:19 AM, Serialize complete at 11/23/2010 11:05:19 AM Content-Type: multipart/alternative; boundary="=_alternative 005865B6852577E4_=" Cc: Hannes Tschofenig , Hannes Tschofenig , ECRIT , ecrit-bounces@ietf.org Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 16:04:42 -0000 This is a multipart message in MIME format. --=_alternative 005865B6852577E4_= Content-Type: text/plain; charset="US-ASCII" ecrit-bounces@ietf.org wrote on 11/23/2010 08:25:27 AM: > [image removed] > Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! > Christer Holmberg > to: > Hannes Tschofenig, Hannes Tschofenig > 11/23/2010 08:25 AM > Sent by: > ecrit-bounces@ietf.org > Cc: > ECRIT > > Hi, > > Are you talking about the case where a normal use could fake a > callback by inserting the indicator? > > If the home network uses number analysis to determine that a call is > fallback, then it will also detect fake callbacks. This is no > different from other types of priority calls. > I am not sure which "priority calls" you are referring to, but the ones I am familiar with do NOT use "number analysis" to "determine that a call is priority". They may use number analysis to identify a REQUEST for a priority call. But once the priority has been granted/authenticated/authorized, there is nothing in the number analysis that will tell you it is a priority call. Janet --=_alternative 005865B6852577E4_= Content-Type: text/html; charset="US-ASCII"

ecrit-bounces@ietf.org wrote on 11/23/2010 08:25:27 AM:

> [image removed]
> Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed!
> Christer Holmberg
> to:
> Hannes Tschofenig, Hannes Tschofenig
> 11/23/2010 08:25 AM
> Sent by:
> ecrit-bounces@ietf.org
> Cc:
> ECRIT
>
> Hi,
>
> Are you talking about the case where a normal use could fake a
> callback by inserting the indicator?
>
> If the home network uses number analysis to determine that a call is
> fallback, then it will also detect fake callbacks. This is no
> different from other types of priority calls.
>
I am not sure which "priority calls" you are referring to, but the ones I am familiar with do NOT use "number analysis" to "determine that a call is priority".

They may use number analysis to identify a REQUEST for a priority call.  But once the priority has been granted/authenticated/authorized, there is nothing in the number analysis that will tell you it is a priority call.

Janet --=_alternative 005865B6852577E4_=-- From dworley@avaya.com Tue Nov 23 10:40:55 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ABB53A69A3 for ; Tue, 23 Nov 2010 10:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.186 X-Spam-Level: X-Spam-Status: No, score=-102.186 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdjFJY3Mghwa for ; Tue, 23 Nov 2010 10:40:54 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id AF1F13A69A1 for ; Tue, 23 Nov 2010 10:40:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMeZ60zGmAcF/2dsb2JhbACiYXGlRAKZJIVLBIRaiS0 X-IronPort-AV: E=Sophos;i="4.59,243,1288584000"; d="scan'208";a="219932073" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Nov 2010 13:41:50 -0500 X-IronPort-AV: E=Sophos;i="4.59,243,1288584000"; d="scan'208";a="544750174" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Nov 2010 13:41:46 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 23 Nov 2010 13:41:17 -0500 From: "Worley, Dale R (Dale)" To: "ecrit@ietf.org" , Robert Sparks Date: Tue, 23 Nov 2010 13:39:42 -0500 Thread-Topic: Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Service Translation Protocol) Thread-Index: AQHLiz3ybWCGMKdypUuFebbPPdhwYA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Ecrit] Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Service Translation Protocol) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 18:40:55 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC5222, "LoST: A Location-to-Service Translation Protocol" Source of RFC: ecrit (rai) Errata ID: 2511 Status: Reported Type: Technical Reported By: Martin Thomson Date Reported: 2010-09-07 Section 8.3.5, 8.4.2 says: In 8.3.5: country A1 A3 A6 PC HNO In 8.4.2: ... Each element contains a list of tokens separated by whitespace, enumerating the civic location labels used in child elements of the element. ... and: The example shown in Figure 5 and in Figure 6 indicates that the tokens 'country', 'A1', 'A3', and 'A6' have been validated by the LoST server. ... It should say: In 8.3.5: ca:country ca:A1 ca:A3 ca:A6 ca:PC ca:HNO In 8.4.2: ... Each element contains a list of qualified element names separated by whitespace, enumerating child elements of the element. .= .. and: The example shown in Figure 5 and in Figure 6 indicates that the tokens 'country', 'A1', 'A3', and 'A6' from [RFC5139] have been validate= d by the LoST server. ... Notes: It's not clear from the description how the location validation response elements are to be interpreted. The example seems to indicate that the local name (only) for the civic address elements is used. On the other hand, the schema seems to imply that, because this is a list of xs:QName, a qualified name is used for each. The text itself is ambiguous. Using the local name only could result in errors - it would be possible (albeit inadvisable) to extend RFC 5139 with an element that had the same local name as an existing element or an element in another extension. As long as the namespace is distinct, this is perfectly legal, but it could lead to a naming conflict here. With this interpretation, the elements in the example in 8.3.5 indicate elements from the LoST namespace (urn:ietf:params:xml:ns:lost1), rather than the civic address namespace (urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr). Updating the description in 8.4.2 and the example in 8.3.5 would ensure that this doesn't result in interoperability problems. ---------------------------------------------------------------------- Recommended status: I think the erratum is incorrect, but the matter needs serious consideration in the WG. As the erratum notes say, it's not clear from the RFC text how the , etc., elements are to be interpreted. The examples, what seems natural to me, and how I expect people to implement, suggest that the element content is a whitespace-separated list of the "LocalParts" of the child elements of -- that is, would contain "A1" even if had an explicit namespace qualifier. But the schema in the RFC explicitly says that the elements are QNames. Now that latter may be an error (and the schema is labeled non-normative), and also all LocalParts are QNames. But the implication of the fact that QNames are allowed is that the values in are to be interpreted as namespace-qualified. However, if the values in are namespace-qualified, the example of Figure 6 becomes invalid, as the A1, etc., elements are in namespace "urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" whereas the default namespace at the point of is "urn:ietf:params:xml:ns:lost1". Fixing that requires the changes listed in the erratum. I suspect these changes would propagate into almost all existing implementations. But if we interpret the values as not namespace-qualified, that places certain limitations on future extensibility, as extension elements of would have to have distinct LocalParts even if they were in different namespaces. This ambiguity needs to be clarified in one way or another, as it affects interoperability. There appears to have been some discussion of this problem in the Geopriv working group. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dale From rjsparks@nostrum.com Tue Nov 23 10:57:06 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72DC3A6987 for ; Tue, 23 Nov 2010 10:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dMy8WiOrIWN for ; Tue, 23 Nov 2010 10:57:04 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 686BF3A693E for ; Tue, 23 Nov 2010 10:57:04 -0800 (PST) Received: from [192.168.2.105] (pool-173-71-48-4.dllstx.fios.verizon.net [173.71.48.4]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oANIw0Ut089564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 23 Nov 2010 12:58:01 -0600 (CST) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Nov 2010 12:58:00 -0600 Message-Id: To: ecrit@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Received-SPF: pass (nostrum.com: 173.71.48.4 is authenticated by a trusted mechanism) Subject: [Ecrit] AD Evaluation: draft-ietf-ecrit-lost-servicelistboundary-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 18:57:06 -0000 I've requested IETF Last call of this document. A question: The examples use a civic address boundary (of Lower Austria). Do you = expect automata to be able to recognize when they have left these regions? (Would a phone be able to turn "Lower Austria" into = a polygon so that it would know when it left?). Would it have made more sense to have constructed these examples with geospatial = regions? ---- Some suggestions: Since the introduction is long, it would help to move the main point of = the introduction (currently in the last paragraph) to the front of the = section. On page 4, 2nd to last paragraph, the sentence "Nevertheless, the client = does not detect this, because only the mapping of the initially = discovered services (police, ambulance, fire) are refreshed." is hard to = parse. I suggest "Since the client is only required to refresh the mappings for = the initially discovered services, the new service is not detected." At the top of page 10, the phrase "so no boundary information is = reasonable" is ambiguous. Is it trying to say "there is no boundary information that is reasonable to send" or "it is = reasonable to send no boundary information"? From br@brianrosen.net Tue Nov 23 11:03:10 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 698EC3A6987 for ; Tue, 23 Nov 2010 11:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.41 X-Spam-Level: X-Spam-Status: No, score=-103.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3c7+J2uVNvLm for ; Tue, 23 Nov 2010 11:03:07 -0800 (PST) Received: from barmail2.idig.net (barmail2.idig.net [64.34.111.252]) by core3.amsl.com (Postfix) with ESMTP id 667F228C129 for ; Tue, 23 Nov 2010 11:03:05 -0800 (PST) X-ASG-Debug-ID: 1290539031-1a2252fc0001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail2.idig.net with ESMTP id ophzeExFuSU3WGd5; Tue, 23 Nov 2010 11:03:51 -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.54]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PKy9f-000146-6O; Tue, 23 Nov 2010 11:03:51 -0800 Mime-Version: 1.0 (Apple Message framework v1081) X-ASG-Orig-Subj: Re: [Ecrit] AD Evaluation: draft-ietf-ecrit-lost-servicelistboundary-04 Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Tue, 23 Nov 2010 14:03:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Robert Sparks X-Mailer: Apple Mail (2.1081) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1290539031 X-Barracuda-URL: http://64.34.111.252:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net 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.47481 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: ecrit@ietf.org Subject: Re: [Ecrit] AD Evaluation: draft-ietf-ecrit-lost-servicelistboundary-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 19:03:10 -0000 Yes, I think it will recognize when it left that area. If it's using = civic, then it gets a civic address, and it can check. If it's getting = geo locations, it needs a geo boundary. We don't have any instances of any element needing to geocode or reverse = geocode, and I don't want to have any. Brian On Nov 23, 2010, at 1:58 PM, Robert Sparks wrote: > I've requested IETF Last call of this document. >=20 > A question: >=20 > The examples use a civic address boundary (of Lower Austria). Do you = expect automata to be able to recognize when they have > left these regions? (Would a phone be able to turn "Lower Austria" = into a polygon so that it would know when it left?). Would it have > made more sense to have constructed these examples with geospatial = regions? >=20 > ---- > Some suggestions: >=20 > Since the introduction is long, it would help to move the main point = of the introduction (currently in the last paragraph) to the front of = the section. >=20 > On page 4, 2nd to last paragraph, the sentence "Nevertheless, the = client does not detect this, because only the mapping of the initially = discovered services (police, ambulance, fire) are refreshed." is hard to = parse. > I suggest "Since the client is only required to refresh the mappings = for the initially discovered services, the new service is not detected." >=20 > At the top of page 10, the phrase "so no boundary information is = reasonable" is ambiguous. Is it trying to say > "there is no boundary information that is reasonable to send" or "it = is reasonable to send no boundary information"? >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From iesg-secretary@ietf.org Tue Nov 23 11:04:17 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13A23A6987; Tue, 23 Nov 2010 11:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.426 X-Spam-Level: X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOmwfUWyoh0g; Tue, 23 Nov 2010 11:04:16 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D552E28C182; Tue, 23 Nov 2010 11:04:15 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101123190415.16070.64616.idtracker@localhost> Date: Tue, 23 Nov 2010 11:04:15 -0800 Cc: ecrit@ietf.org Subject: [Ecrit] Last Call: (LoST Service List Boundary Extension) to Experimental RFC X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 19:04:17 -0000 The IESG has received a request from the Emergency Context Resolution with Internet Technologies WG (ecrit) to consider the following document: - 'LoST Service List Boundary Extension' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-12-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-servicelistboundary/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-servicelistboundary/ No IPR declarations have been submitted directly on this I-D. From christer.holmberg@ericsson.com Tue Nov 23 11:33:33 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B0B28C11E; Tue, 23 Nov 2010 11:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.661 X-Spam-Level: X-Spam-Status: No, score=-6.661 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPkpbtcu0qzJ; Tue, 23 Nov 2010 11:33:33 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 9673C28C115; Tue, 23 Nov 2010 11:33:32 -0800 (PST) X-AuditID: c1b4fb39-b7cabae000005002-f8-4cec17454907 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E3.75.20482.5471CEC4; Tue, 23 Nov 2010 20:34:30 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 23 Nov 2010 20:34:29 +0100 From: Christer Holmberg To: Janet P Gunn Date: Tue, 23 Nov 2010 20:33:30 +0100 Thread-Topic: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! Thread-Index: AcuLKEbMQUldHpK6Q/yM04v6o13SPwAHQf4G Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C71873@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850307D163@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850307D245@ESESSCMS0356.eemea.ericsson.se>, 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Hannes Tschofenig , Hannes Tschofenig , ECRIT , "ecrit-bounces@ietf.org" Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 19:33:34 -0000 Hi, >>Are you talking about the case where a normal use could fake a >>callback by inserting the indicator? >> >>If the home network uses number analysis to determine that a call is >>fallback, then it will also detect fake callbacks. This is no >>different from other types of priority calls. > >I am not sure which "priority calls" you are referring to, but the ones I = am >familiar with do NOT use "number analysis" to "determine that a call is= priority". > >They may use number analysis to identify a REQUEST for a priority call. Yes, that is what I meant. Sorry for the confusion. Regards, Christer But once the priority has been granted/authenticated/authorized, there is= nothing in the number analysis that will tell you it is a priority call. Janet From Martin.Thomson@andrew.com Tue Nov 23 19:26:28 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9CC428C107 for ; Tue, 23 Nov 2010 19:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_00=-2.599, J_CHICKENPOX_25=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGOdRfRMamvO for ; Tue, 23 Nov 2010 19:26:27 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id C1F0228C100 for ; Tue, 23 Nov 2010 19:26:27 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:33609 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S502651Ab0KXD10 (ORCPT ); Tue, 23 Nov 2010 21:27:26 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 23 Nov 2010 21:27:25 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 24 Nov 2010 11:27:23 +0800 From: "Thomson, Martin" To: "Worley, Dale R (Dale)" , "ecrit@ietf.org" , Robert Sparks Date: Wed, 24 Nov 2010 11:27:19 +0800 Thread-Topic: [Ecrit] Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Service Translation Protocol) Thread-Index: AQHLiz3ybWCGMKdypUuFebbPPdhwYJN/9q0w Message-ID: <8B0A9FCBB9832F43971E38010638454F03F33EAB5B@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Ecrit] Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Service Translation Protocol) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 03:26:29 -0000 VGhpcyBpcyBhIHNvdW5kIGFuYWx5c2lzLCB3aXRoIG9uZSBzbWFsbCwgYnV0IHNpZ25pZmljYW50 IGV4Y2VwdGlvbjoNCg0KVGhlIGFuYWx5c2lzIHJlbGllcyBvbiB0aGUgcHJlbWlzZSB0aGF0IHRo ZSBzY2hlbWEgaXMgbm9uLW5vcm1hdGl2ZToNCg0KPiAuLi4gTm93IHRoYXQgbGF0dGVyIG1heSBi ZSBhbiBlcnJvciAoYW5kIHRoZSBzY2hlbWEgaXMNCj4gbGFiZWxlZCBub24tbm9ybWF0aXZlKSwg Li4uDQoNClRoaXMgaXMgb25seSB0cnVlIG9mIHRoZSBzY2hlbWEgaW4gdGhlIGFwcGVuZGljZXMu ICBJIGFzc3VtZSB0aGF0IHRoZSBSZWxheE5HIHNjaGVtYSBpbiBTZWN0aW9uIDE1IGlzIG5vcm1h dGl2ZSBpbiB0aGUgYWJzZW5jZSBvZiBzdGF0ZW1lbnRzIHRvIHRoZSBjb250cmFyeS4NCg0KUmVn YXJkbGVzcywgYWNoaWV2aW5nIGludGVyb3BlcmFiaWxpdHkgaW4gdGhlIHByZXNlbmNlIG9mIGV4 dGVuc2lvbnMgdG8gdGhlIGNpdmljIGFkZHJlc3MgZm9ybWF0IGJhc2VkIHNvbGVseSBvbiB0aGUg UkZDIHRleHQgaXMgZGlmZmljdWx0IC0gaGVuY2UgdGhlIHRlY2huaWNhbCBlcnJhdHVtLg0KDQot LU1hcnRpbg0KDQpPbiAyMDEwLTExLTI0IGF0IDA1OjM5OjQyLCBXb3JsZXksIERhbGUgUiAoRGFs ZSkgd3JvdGU6DQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gUkZDNTIyMiwgIkxvU1Q6IEEgTG9jYXRpb24t dG8tU2VydmljZSBUcmFuc2xhdGlvbiBQcm90b2NvbCINCj4gU291cmNlIG9mIFJGQzogZWNyaXQg KHJhaSkNCj4gDQo+IEVycmF0YSBJRDogMjUxMQ0KPiANCj4gU3RhdHVzOiBSZXBvcnRlZA0KPiBU eXBlOiBUZWNobmljYWwNCj4gDQo+IFJlcG9ydGVkIEJ5OiBNYXJ0aW4gVGhvbXNvbg0KPiBEYXRl IFJlcG9ydGVkOiAyMDEwLTA5LTA3DQo+IA0KPiBTZWN0aW9uIDguMy41LCA4LjQuMiBzYXlzOg0K PiANCj4gSW4gOC4zLjU6DQo+ICAgICAgPGxvY2F0aW9uVmFsaWRhdGlvbj4NCj4gICAgICAgIDx2 YWxpZD5jb3VudHJ5IEExIEEzIEE2PC92YWxpZD4NCj4gICAgICAgIDxpbnZhbGlkPlBDPC9pbnZh bGlkPg0KPiAgICAgICAgPHVuY2hlY2tlZD5ITk88L3VuY2hlY2tlZD4NCj4gICAgICA8L2xvY2F0 aW9uVmFsaWRhdGlvbj4NCj4gDQo+IEluIDguNC4yOg0KPiAgICAuLi4gRWFjaCBlbGVtZW50IGNv bnRhaW5zIGEgbGlzdCBvZiB0b2tlbnMgc2VwYXJhdGVkIGJ5DQo+ICAgIHdoaXRlc3BhY2UsIGVu dW1lcmF0aW5nIHRoZSBjaXZpYyBsb2NhdGlvbiBsYWJlbHMgdXNlZCBpbiBjaGlsZA0KPiAgICBl bGVtZW50cyBvZiB0aGUgPGNpdmljQWRkcmVzcz4gZWxlbWVudC4gIC4uLg0KPiBhbmQ6DQo+ICAg IFRoZSBleGFtcGxlIHNob3duIGluIEZpZ3VyZSA1IGFuZCBpbiBGaWd1cmUgNiBpbmRpY2F0ZXMg dGhhdCB0aGUNCj4gICAgdG9rZW5zICdjb3VudHJ5JywgJ0ExJywgJ0EzJywgYW5kICdBNicgaGF2 ZSBiZWVuIHZhbGlkYXRlZCBieSB0aGUNCj4gICAgTG9TVCBzZXJ2ZXIuICAuLi4NCj4gDQo+IEl0 IHNob3VsZCBzYXk6DQo+IA0KPiBJbiA4LjMuNToNCj4gICAgICA8bG9jYXRpb25WYWxpZGF0aW9u DQo+ICAgICAgICAgeG1sbnM6Y2E9InVybjppZXRmOnBhcmFtczp4bWw6bnM6cGlkZjpnZW9wcml2 MTA6Y2l2aWNBZGRyIj4NCj4gICAgICAgIDx2YWxpZD5jYTpjb3VudHJ5IGNhOkExIGNhOkEzIGNh OkE2PC92YWxpZD4NCj4gICAgICAgIDxpbnZhbGlkPmNhOlBDPC9pbnZhbGlkPg0KPiAgICAgICAg PHVuY2hlY2tlZD5jYTpITk88L3VuY2hlY2tlZD4NCj4gICAgICA8L2xvY2F0aW9uVmFsaWRhdGlv bj4NCj4gDQo+IEluIDguNC4yOg0KPiAgICAuLi4gRWFjaCBlbGVtZW50IGNvbnRhaW5zIGEgbGlz dCBvZiBxdWFsaWZpZWQgZWxlbWVudCBuYW1lcw0KPiBzZXBhcmF0ZWQgYnkNCj4gICAgd2hpdGVz cGFjZSwgZW51bWVyYXRpbmcgY2hpbGQgZWxlbWVudHMgb2YgdGhlIDxjaXZpY0FkZHJlc3M+DQo+ IGVsZW1lbnQuICAuLi4NCj4gYW5kOg0KPiAgICBUaGUgZXhhbXBsZSBzaG93biBpbiBGaWd1cmUg NSBhbmQgaW4gRmlndXJlIDYgaW5kaWNhdGVzIHRoYXQgdGhlDQo+ICAgIHRva2VucyAnY291bnRy eScsICdBMScsICdBMycsIGFuZCAnQTYnIGZyb20gW1JGQzUxMzldIGhhdmUgYmVlbg0KPiB2YWxp ZGF0ZWQNCj4gICAgYnkgdGhlIExvU1Qgc2VydmVyLiAgLi4uDQo+IA0KPiBOb3RlczoNCj4gDQo+ IEl0J3Mgbm90IGNsZWFyIGZyb20gdGhlIGRlc2NyaXB0aW9uIGhvdyB0aGUgbG9jYXRpb24gdmFs aWRhdGlvbg0KPiByZXNwb25zZSBlbGVtZW50cyBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQuIFRoZSBl eGFtcGxlIHNlZW1zIHRvIGluZGljYXRlDQo+IHRoYXQgdGhlIGxvY2FsIG5hbWUgKG9ubHkpIGZv ciB0aGUgY2l2aWMgYWRkcmVzcyBlbGVtZW50cyBpcyB1c2VkLiBPbg0KPiB0aGUgb3RoZXIgaGFu ZCwgdGhlIHNjaGVtYSBzZWVtcyB0byBpbXBseSB0aGF0LCBiZWNhdXNlIHRoaXMgaXMgYSBsaXN0 DQo+IG9mIHhzOlFOYW1lLCBhIHF1YWxpZmllZCBuYW1lIGlzIHVzZWQgZm9yIGVhY2guIFRoZSB0 ZXh0IGl0c2VsZiBpcw0KPiBhbWJpZ3VvdXMuDQo+IA0KPiBVc2luZyB0aGUgbG9jYWwgbmFtZSBv bmx5IGNvdWxkIHJlc3VsdCBpbiBlcnJvcnMgLSBpdCB3b3VsZCBiZQ0KPiBwb3NzaWJsZSAoYWxi ZWl0IGluYWR2aXNhYmxlKSB0byBleHRlbmQgUkZDIDUxMzkgd2l0aCBhbiBlbGVtZW50IHRoYXQN Cj4gaGFkIHRoZSBzYW1lIGxvY2FsIG5hbWUgYXMgYW4gZXhpc3RpbmcgZWxlbWVudCBvciBhbiBl bGVtZW50IGluDQo+IGFub3RoZXIgZXh0ZW5zaW9uLiBBcyBsb25nIGFzIHRoZSBuYW1lc3BhY2Ug aXMgZGlzdGluY3QsIHRoaXMgaXMNCj4gcGVyZmVjdGx5IGxlZ2FsLCBidXQgaXQgY291bGQgbGVh ZCB0byBhIG5hbWluZyBjb25mbGljdCBoZXJlLg0KPiANCj4gV2l0aCB0aGlzIGludGVycHJldGF0 aW9uLCB0aGUgZWxlbWVudHMgaW4gdGhlIGV4YW1wbGUgaW4gOC4zLjUNCj4gaW5kaWNhdGUgZWxl bWVudHMgZnJvbSB0aGUgTG9TVCBuYW1lc3BhY2UNCj4gKHVybjppZXRmOnBhcmFtczp4bWw6bnM6 bG9zdDEpLCByYXRoZXIgdGhhbiB0aGUgY2l2aWMgYWRkcmVzcw0KPiBuYW1lc3BhY2UgKHVybjpp ZXRmOnBhcmFtczp4bWw6bnM6cGlkZjpnZW9wcml2MTA6Y2l2aWNBZGRyKS4NCj4gDQo+IFVwZGF0 aW5nIHRoZSBkZXNjcmlwdGlvbiBpbiA4LjQuMiBhbmQgdGhlIGV4YW1wbGUgaW4gOC4zLjUgd291 bGQNCj4gZW5zdXJlIHRoYXQgdGhpcyBkb2Vzbid0IHJlc3VsdCBpbiBpbnRlcm9wZXJhYmlsaXR5 IHByb2JsZW1zLg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFJlY29tbWVuZGVkIHN0YXR1czogIEkgdGhp bmsgdGhlIGVycmF0dW0gaXMgaW5jb3JyZWN0LCBidXQgdGhlIG1hdHRlcg0KPiBuZWVkcyBzZXJp b3VzIGNvbnNpZGVyYXRpb24gaW4gdGhlIFdHLg0KPiANCj4gQXMgdGhlIGVycmF0dW0gbm90ZXMg c2F5LCBpdCdzIG5vdCBjbGVhciBmcm9tIHRoZSBSRkMgdGV4dCBob3cgdGhlDQo+IDx2YWxpZD4s IGV0Yy4sIGVsZW1lbnRzIGFyZSB0byBiZSBpbnRlcnByZXRlZC4gIFRoZSBleGFtcGxlcywgd2hh dA0KPiBzZWVtcyBuYXR1cmFsIHRvIG1lLCBhbmQgaG93IEkgZXhwZWN0IHBlb3BsZSB0byBpbXBs ZW1lbnQsIHN1Z2dlc3QNCj4gdGhhdCB0aGUgZWxlbWVudCBjb250ZW50IGlzIGEgd2hpdGVzcGFj ZS1zZXBhcmF0ZWQgbGlzdCBvZiB0aGUNCj4gIkxvY2FsUGFydHMiIG9mIHRoZSBjaGlsZCBlbGVt ZW50cyBvZiA8bG9jYXRpb25WYWxpZGF0aW9uPiAtLSB0aGF0IGlzLA0KPiA8dmFsaWQ+IHdvdWxk IGNvbnRhaW4gIkExIiBldmVuIGlmIDx2YWxpZD4gaGFkIGFuIGV4cGxpY2l0IG5hbWVzcGFjZQ0K PiBxdWFsaWZpZXIuICBCdXQgdGhlIHNjaGVtYSBpbiB0aGUgUkZDIGV4cGxpY2l0bHkgc2F5cyB0 aGF0IHRoZSBlbGVtZW50cw0KPiBhcmUgUU5hbWVzLiAgTm93IHRoYXQgbGF0dGVyIG1heSBiZSBh biBlcnJvciAoYW5kIHRoZSBzY2hlbWEgaXMNCj4gbGFiZWxlZCBub24tbm9ybWF0aXZlKSwgYW5k IGFsc28gYWxsIExvY2FsUGFydHMgYXJlIFFOYW1lcy4gIEJ1dCB0aGUNCj4gaW1wbGljYXRpb24g b2YgdGhlIGZhY3QgdGhhdCBRTmFtZXMgYXJlIGFsbG93ZWQgaXMgdGhhdCB0aGUgdmFsdWVzIGlu DQo+IDx2YWxpZD4gYXJlIHRvIGJlIGludGVycHJldGVkIGFzIG5hbWVzcGFjZS1xdWFsaWZpZWQu DQo+IA0KPiBIb3dldmVyLCBpZiB0aGUgdmFsdWVzIGluIDx2YWxpZD4gYXJlIG5hbWVzcGFjZS1x dWFsaWZpZWQsIHRoZSBleGFtcGxlDQo+IG9mIEZpZ3VyZSA2IGJlY29tZXMgaW52YWxpZCwgYXMg dGhlIEExLCBldGMuLCBlbGVtZW50cyBhcmUgaW4NCj4gbmFtZXNwYWNlICJ1cm46aWV0ZjpwYXJh bXM6eG1sOm5zOnBpZGY6Z2VvcHJpdjEwOmNpdmljQWRkciIgd2hlcmVhcw0KPiB0aGUgZGVmYXVs dCBuYW1lc3BhY2UgYXQgdGhlIHBvaW50IG9mIDx2YWxpZD4gaXMNCj4gInVybjppZXRmOnBhcmFt czp4bWw6bnM6bG9zdDEiLiAgRml4aW5nIHRoYXQgcmVxdWlyZXMgdGhlIGNoYW5nZXMNCj4gbGlz dGVkIGluIHRoZSBlcnJhdHVtLiAgSSBzdXNwZWN0IHRoZXNlIGNoYW5nZXMgd291bGQgcHJvcGFn YXRlIGludG8NCj4gYWxtb3N0IGFsbCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMuDQo+IA0KPiBC dXQgaWYgd2UgaW50ZXJwcmV0IHRoZSB2YWx1ZXMgYXMgbm90IG5hbWVzcGFjZS1xdWFsaWZpZWQs IHRoYXQgcGxhY2VzDQo+IGNlcnRhaW4gbGltaXRhdGlvbnMgb24gZnV0dXJlIGV4dGVuc2liaWxp dHksIGFzIGV4dGVuc2lvbiBlbGVtZW50cyBvZg0KPiA8Y2l2aWNBZGRyZXNzPiB3b3VsZCBoYXZl IHRvIGhhdmUgZGlzdGluY3QgTG9jYWxQYXJ0cyBldmVuIGlmIHRoZXkNCj4gd2VyZSBpbiBkaWZm ZXJlbnQgbmFtZXNwYWNlcy4NCj4gDQo+IFRoaXMgYW1iaWd1aXR5IG5lZWRzIHRvIGJlIGNsYXJp ZmllZCBpbiBvbmUgd2F5IG9yIGFub3RoZXIsIGFzIGl0DQo+IGFmZmVjdHMgaW50ZXJvcGVyYWJp bGl0eS4NCj4gDQo+IFRoZXJlIGFwcGVhcnMgdG8gaGF2ZSBiZWVuIHNvbWUgZGlzY3Vzc2lvbiBv ZiB0aGlzIHByb2JsZW0gaW4gdGhlDQo+IEdlb3ByaXYgd29ya2luZyBncm91cC4NCj4gPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KPiANCj4gRGFsZQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQoNCg== From khwolf1@gmail.com Wed Nov 24 04:16:07 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F95B3A6A30 for ; Wed, 24 Nov 2010 04:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9E3ZSHCGDko for ; Wed, 24 Nov 2010 04:16:06 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 99CF93A6920 for ; Wed, 24 Nov 2010 04:16:06 -0800 (PST) Received: by iwn40 with SMTP id 40so11205209iwn.31 for ; Wed, 24 Nov 2010 04:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=im+J+/k49Zxg5cGa5o5nIoCf9seW6RXkRBVJ7BU+PAw=; b=HqgGWm2uS3iJWZF7yCLNJReq50e3dZDRIggGHkLdUL2WMuRKpog0emfuSYsMNoxCAU TuEylpekKBlXHETrz8aT7oEzY98os/P6VqNvCfzyDsqSEnv62K1tDyxdyCp1jLWCYdDZ h8o/Q/kPVQJOIlwaQz1mvrChWrGee/1V0SyYM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UK6vE72+8XhrRUiNJPwljfs98LCCC+jgyl0FRu4vlu9vyqe42r1ZmaPPTPZh4sZmJC YlqUvVrv5i3WBfhZPnSZXzuRXfGQUOfI/8epMYgCwDTJw+B70f8PMyUSve24M/76XrIG KhU4VNa2GQQtAtZAy2EQhgS5zs1q/JGz8pWaM= MIME-Version: 1.0 Received: by 10.231.16.131 with SMTP id o3mr9690077iba.38.1290601024668; Wed, 24 Nov 2010 04:17:04 -0800 (PST) Received: by 10.231.145.203 with HTTP; Wed, 24 Nov 2010 04:17:04 -0800 (PST) In-Reply-To: References: Date: Wed, 24 Nov 2010 13:17:04 +0100 Message-ID: From: Karl Heinz Wolf To: Robert Sparks Content-Type: text/plain; charset=ISO-8859-1 Cc: ecrit@ietf.org Subject: Re: [Ecrit] AD Evaluation: draft-ietf-ecrit-lost-servicelistboundary-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 12:16:07 -0000 Robert, On Tue, Nov 23, 2010 at 7:58 PM, Robert Sparks wrote: > I've requested IETF Last call of this document. > > A question: > > The examples use a civic address boundary (of Lower Austria). Do you expect automata to be able to recognize when they have > left these regions? (Would a phone be able to turn "Lower Austria" into a polygon so that it would know when it left?). Would it have > made more sense to have constructed these examples with geospatial regions? > For clients knowing their civic address a civic boundary makes sense, no geocoding desired. In order to ensure that each client gets suitable boundary information Section 3.3 says: The server ... MUST use at least one profile that the client used in the request in order to ensure that the client is able to process the boundary information. > ---- > Some suggestions: > > Since the introduction is long, it would help to move the main point of the introduction (currently in the last paragraph) to the front of the section. ok > On page 4, 2nd to last paragraph, the sentence "Nevertheless, the client does not detect this, because only the mapping of the initially discovered services (police, ambulance, fire) are refreshed." is hard to parse. > I suggest "Since the client is only required to refresh the mappings for the initially discovered services, the new service is not detected." ok > At the top of page 10, the phrase "so no boundary information is reasonable" is ambiguous. Is it trying to say > "there is no boundary information that is reasonable to send" or "it is reasonable to send no boundary information"? Would putting the sentence this way make it clearer: The request is purely for diagnostic purposes and does not contain location information at all, so boundary information cannot be calculated. Thank you for your suggestions, I'll note them. Karl Heinz From rjsparks@nostrum.com Wed Nov 24 05:57:41 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1A713A6A4D for ; Wed, 24 Nov 2010 05:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.31 X-Spam-Level: X-Spam-Status: No, score=-102.31 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RY8Qt6fpFZpz for ; Wed, 24 Nov 2010 05:57:41 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 4E86D3A6A58 for ; Wed, 24 Nov 2010 05:57:40 -0800 (PST) Received: from [192.168.2.105] (pool-173-71-48-4.dllstx.fios.verizon.net [173.71.48.4]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oAODwbbJ082972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Nov 2010 07:58:38 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: Date: Wed, 24 Nov 2010 07:58:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1307C542-6B38-40FA-85C7-D64608DD6E8D@nostrum.com> References: To: Karl Heinz Wolf X-Mailer: Apple Mail (2.1081) Received-SPF: pass (nostrum.com: 173.71.48.4 is authenticated by a trusted mechanism) Cc: ecrit@ietf.org Subject: Re: [Ecrit] AD Evaluation: draft-ietf-ecrit-lost-servicelistboundary-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 13:57:42 -0000 >=20 >=20 >> At the top of page 10, the phrase "so no boundary information is = reasonable" is ambiguous. Is it trying to say >> "there is no boundary information that is reasonable to send" or "it = is reasonable to send no boundary information"? >=20 > Would putting the sentence this way make it clearer: > The request is purely for diagnostic purposes and does > not contain location information at all, so boundary information > cannot be calculated. >=20 Yes - thanks! >=20 > Thank you for your suggestions, I'll note them. >=20 > Karl Heinz From dworley@avaya.com Wed Nov 24 06:38:23 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2183A6970 for ; Wed, 24 Nov 2010 06:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzO8kePXfpYN for ; Wed, 24 Nov 2010 06:38:23 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 096843A6968 for ; Wed, 24 Nov 2010 06:38:22 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMqy7EyHCzI1/2dsb2JhbACieHGlNgKZJIVHBIRbiS4 X-IronPort-AV: E=Sophos;i="4.59,248,1288584000"; d="scan'208";a="251652978" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 Nov 2010 09:39:22 -0500 X-IronPort-AV: E=Sophos;i="4.59,248,1288584000"; d="scan'208";a="544430810" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Nov 2010 09:39:22 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 24 Nov 2010 09:39:21 -0500 From: "Worley, Dale R (Dale)" To: "Thomson, Martin" , "ecrit@ietf.org" , Robert Sparks Date: Wed, 24 Nov 2010 09:35:58 -0500 Thread-Topic: [Ecrit] Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Service Translation Protocol) Thread-Index: AQHLiz3ybWCGMKdypUuFebbPPdhwYJN/9q0wgAC8qJE= Message-ID: References: , <8B0A9FCBB9832F43971E38010638454F03F33EAB5B@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F33EAB5B@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Service Translation Protocol) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 14:38:24 -0000 ________________________________________ From: Thomson, Martin [Martin.Thomson@andrew.com] This is a sound analysis, with one small, but significant exception: The analysis relies on the premise that the schema is non-normative: > ... Now that latter may be an error (and the schema is > labeled non-normative), ... This is only true of the schema in the appendices. I assume that the Relax= NG schema in Section 15 is normative in the absence of statements to the co= ntrary. _______________________________________________ Ugh, that is an error on my part. Yes, clearly the schema in section 15 is= normative. Unfortunately, I think this problem is beyond "errata" but rather is an inc= onsistency in the design, and there is no clearly correct resolution. Henc= e my desire to return it to the WG. Dale From christer.holmberg@ericsson.com Wed Nov 24 10:50:30 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45C913A6980 for ; Wed, 24 Nov 2010 10:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN3ZOnWnX-vM for ; Wed, 24 Nov 2010 10:50:23 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0DD9C3A68DC for ; Wed, 24 Nov 2010 10:50:03 -0800 (PST) X-AuditID: c1b4fb39-b7c5aae000003b0f-e9-4ced5e97eb58 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D7.7B.15119.79E5DEC4; Wed, 24 Nov 2010 19:51:03 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 24 Nov 2010 19:51:02 +0100 From: Christer Holmberg To: Brian Rosen Date: Wed, 24 Nov 2010 19:49:11 +0100 Thread-Topic: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! Thread-Index: AcuLGsGtQOjsw3xXSK6KVT5IysmXfAA7Ybww Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C7187F@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05850307D245@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850307D293@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850307D2F2@ESESSCMS0356.eemea.ericsson.se>, 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: Hannes Tschofenig , Hannes Tschofenig , ECRIT Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 18:50:30 -0000 Hi, >In the present system, this isn't done. >=20 >I agree it should be done, and therefore, I do want call=20 >backs to be marked. >=20 >I personally think the token mechanism is the best way to=20 >link the outgoing call with the incoming call for security=20 >purposes. I think that the home/local issue can be solved reasonably. Ok, so I guess the first question is then whether the group agrees to cover= the home/local issue. I think it would also be useful for 3GPP to know. Regarding the callback indication from PSTN, I hade a chat with some of our= ISUP guys. There is no global ISUP standard for callback indication. However, there ar= e national ISUP variants where this kind of information can be inserted in = the ISUP ample space. Other mechanisms involve making the decission based o= n CPC, or to use reserved trunks for emergency and callback (e.g. use a spe= cific set of CIC values/B-channels as indicator). Such informatino is norma= lly not sent to the S-CSCF (I don't want to require ISUP encapsulation for = this :) A possible way to allow this could be to allow the MGCF to insert an "empty= " token. The home S-CSCF could then insert the value of the called UA, befo= re forwarding the INVITE. I don't think that would have any impacts on secu= rity. Regards, Christer > Hi Brian, > > Do you agree that the home network in general needs to know (based on wha= tever information) that the call is callback (e.g. in order to disable serv= ices etc)? > > Regards, > > Christer > >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: 23. marraskuuta 2010 16:06 >> To: Christer Holmberg >> Cc: Hannes Tschofenig; Hannes Tschofenig; ECRIT >> Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - >> Feedback needed! >> >> In every nation I know the details of (which isn't many), the >> PSTN affords no special processing to call backs. >> >> Having the gateway aware that a call was a call back is not >> useful in those countries. >> >> Brian >> >> On Nov 23, 2010, at 8:48 AM, Christer Holmberg wrote: >> >>> >>> Hi, >>> >>>> What are the properties of the design in the PSTN case? >>>> >>>> Based on what information is the PSTN-VoIP gateway going to put a >>>> callback marking on the call? >>> >>> Unfortunately I don't have details of that available. I >> think the information elements have different names depending >> on countries etc. >>> >>> And, as I said, if no such information element is >> available, number analysis can be used. >>> >>> Regards, >>> >>> Christer >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >>= From Martin.Thomson@andrew.com Wed Nov 24 13:48:45 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF3B28C17A for ; Wed, 24 Nov 2010 13:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkWhKymzrtYd for ; Wed, 24 Nov 2010 13:48:44 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 0FDB728C17D for ; Wed, 24 Nov 2010 13:48:43 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:60035 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S38997269Ab0KXVtn (ORCPT ); Wed, 24 Nov 2010 15:49:43 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Wed, 24 Nov 2010 15:49:43 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 25 Nov 2010 05:49:40 +0800 From: "Thomson, Martin" To: "Worley, Dale R (Dale)" , "ecrit@ietf.org" , Robert Sparks Date: Thu, 25 Nov 2010 05:49:38 +0800 Thread-Topic: [Ecrit] Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Service Translation Protocol) Thread-Index: AQHLiz3ybWCGMKdypUuFebbPPdhwYJN/9q0wgAC8qJGAAHjucA== Message-ID: <8B0A9FCBB9832F43971E38010638454F03F33EAC59@SISPE7MB1.commscope.com> References: , <8B0A9FCBB9832F43971E38010638454F03F33EAB5B@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Ecrit] Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Service Translation Protocol) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 21:48:45 -0000 T24gMjAxMC0xMS0yNSBhdCAwMTozNTo1OCwgV29ybGV5LCBEYWxlIFIgKERhbGUpIHdyb3RlOg0K PiBVbmZvcnR1bmF0ZWx5LCBJIHRoaW5rIHRoaXMgcHJvYmxlbSBpcyBiZXlvbmQgImVycmF0YSIg YnV0IHJhdGhlciBpcyBhbg0KPiBpbmNvbnNpc3RlbmN5IGluIHRoZSBkZXNpZ24sIGFuZCB0aGVy ZSBpcyBubyBjbGVhcmx5IGNvcnJlY3QNCj4gcmVzb2x1dGlvbi4gIEhlbmNlIG15IGRlc2lyZSB0 byByZXR1cm4gaXQgdG8gdGhlIFdHLg0KDQpJIGNhbid0IGFyZ3VlIHdpdGggdGhhdC4gIFdlIGRl ZmluaXRlbHkgbmVlZCB0byBkaXNjdXNzIHRoaXMgZnVydGhlci4gIFByb2JhYmx5IGRpc2N1c3Mg YWxvbmcgd2l0aCB0aGUgcmVzb2x1dGlvbiB0byB0aGUgR0VPUFJJViBxdWVzdGlvbi4NCg0KLS1N YXJ0aW4NCg0K From keith.drage@alcatel-lucent.com Wed Nov 24 19:00:31 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A276528C175 for ; Wed, 24 Nov 2010 19:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.708 X-Spam-Level: X-Spam-Status: No, score=-103.708 tagged_above=-999 required=5 tests=[AWL=-1.459, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CnX038FNobW for ; Wed, 24 Nov 2010 19:00:30 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id A261428C0F0 for ; Wed, 24 Nov 2010 19:00:30 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAP31NeS022978 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 25 Nov 2010 04:01:23 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 25 Nov 2010 04:01:23 +0100 From: "DRAGE, Keith (Keith)" To: Brian Rosen , Christer Holmberg Date: Thu, 25 Nov 2010 04:01:22 +0100 Thread-Topic: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! Thread-Index: AcuLF5RegKD5vsezR6CNZ+QmLlUm8gBANLBA Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05850307D245@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850307D293@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: Hannes Tschofenig , Hannes Tschofenig , ECRIT Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 03:00:31 -0000 Surely the IETF work is to enable the original user with an emergency to be= IP connected.=20 Giving the caller the benifit of the callback experience should be possible= whether the PSAP is IP connected or connected via the PSTN. In many countr= ies we expect to see PSAPs connected via the PSTN for a long time, while th= e users are increasingly IP connected. Therefore whether the PSAP is IP connected or connected via the PSTN should= not affect the way callbacks occur to that user. Whether there are technic= al problems with providing a solution or not, the use case is equally valid= . regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Brian Rosen > Sent: Tuesday, November 23, 2010 2:06 PM > To: Christer Holmberg > Cc: Hannes Tschofenig; Hannes Tschofenig; ECRIT > Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update -=20 > Feedback needed! >=20 > In every nation I know the details of (which isn't many), the=20 > PSTN affords no special processing to call backs. >=20 > Having the gateway aware that a call was a call back is not=20 > useful in those countries. >=20 > Brian >=20 > On Nov 23, 2010, at 8:48 AM, Christer Holmberg wrote: >=20 > >=20 > > Hi, > >=20 > >> What are the properties of the design in the PSTN case? > >>=20 > >> Based on what information is the PSTN-VoIP gateway going to put a=20 > >> callback marking on the call? > >=20 > > Unfortunately I don't have details of that available. I=20 > think the information elements have different names depending=20 > on countries etc. > >=20 > > And, as I said, if no such information element is=20 > available, number analysis can be used. > >=20 > > Regards, > >=20 > > Christer > >=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 hannes.tschofenig@gmx.net Thu Nov 25 03:53:29 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2E428C0F6 for ; Thu, 25 Nov 2010 03:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7hdgoAazTw5 for ; Thu, 25 Nov 2010 03:53:28 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id C4CB028C0D8 for ; Thu, 25 Nov 2010 03:53:27 -0800 (PST) Received: (qmail invoked by alias); 25 Nov 2010 11:54:27 -0000 Received: from unknown (EHLO [10.255.137.37]) [192.100.123.77] by mail.gmx.net (mp014) with SMTP; 25 Nov 2010 12:54:27 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19FRw5VLhNF26UTy/oDOJ11CD7adEeVf35da3u5Y2 NfWxDbmfRaXvmf Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 25 Nov 2010 13:54:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05850307D245@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850307D293@ESESSCMS0356.eemea.ericsson.se> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig , Hannes Tschofenig , ECRIT Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update - Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 11:53:29 -0000 I understand the desire to have that use cases covered.=20 I was interested to hear more about the desire properties because there = are security implications that we may not want to ignore.=20 The implication I see that it is difficult for the PSTN-IP gateway to = decide whether an outgoing call is a callback or not.=20 I am curious to hear whether there are mechanisms on the PSTN side that = would allow such "callback marking" to be signaled to the gateway.=20 On Nov 25, 2010, at 5:01 AM, DRAGE, Keith (Keith) wrote: > Surely the IETF work is to enable the original user with an emergency = to be IP connected.=20 >=20 > Giving the caller the benifit of the callback experience should be = possible whether the PSAP is IP connected or connected via the PSTN. In = many countries we expect to see PSAPs connected via the PSTN for a long = time, while the users are increasingly IP connected. >=20 > Therefore whether the PSAP is IP connected or connected via the PSTN = should not affect the way callbacks occur to that user. Whether there = are technical problems with providing a solution or not, the use case is = equally valid. >=20 > regards >=20 > Keith >=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >> On Behalf Of Brian Rosen >> Sent: Tuesday, November 23, 2010 2:06 PM >> To: Christer Holmberg >> Cc: Hannes Tschofenig; Hannes Tschofenig; ECRIT >> Subject: Re: [Ecrit] PSAP Callback: Pending Draft Update -=20 >> Feedback needed! >>=20 >> In every nation I know the details of (which isn't many), the=20 >> PSTN affords no special processing to call backs. >>=20 >> Having the gateway aware that a call was a call back is not=20 >> useful in those countries. >>=20 >> Brian >>=20 >> On Nov 23, 2010, at 8:48 AM, Christer Holmberg wrote: >>=20 >>>=20 >>> Hi, >>>=20 >>>> What are the properties of the design in the PSTN case? >>>>=20 >>>> Based on what information is the PSTN-VoIP gateway going to put a=20= >>>> callback marking on the call? >>>=20 >>> Unfortunately I don't have details of that available. I=20 >> think the information elements have different names depending=20 >> on countries etc. >>>=20 >>> And, as I said, if no such information element is=20 >> available, number analysis can be used. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20