From ecrit-bounces@ietf.org Thu May 05 09:12:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTg9u-0000Ab-JU; Thu, 05 May 2005 09:12:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTg9s-00009u-Kr; Thu, 05 May 2005 09:12:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23578; Thu, 5 May 2005 09:12:50 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTgOA-0001Fy-17; Thu, 05 May 2005 09:27:39 -0400 Received: from [193.0.8.74] ([::ffff:193.0.8.74]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 05 May 2005 09:12:48 -0400 id 000FF875.427A1BD0.00003BA8 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <5c923107b05c0a939f84fcc4698b0702@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed To: GEOPRIV WG , ecrit@ietf.org From: Andrew Newton Date: Thu, 5 May 2005 09:12:45 -0400 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Subject: [Ecrit] Registration for the Interim Meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If you plan on attending the joint GEOPRIV/ECRIT interim meeting, please send email to Rosemary Addarich so that Columbia will have a proper head-count in making their preparations. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 06 16:41:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU9dz-0005aJ-OR; Fri, 06 May 2005 16:41:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU9dv-0005aE-3R for ecrit@megatron.ietf.org; Fri, 06 May 2005 16:41:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08842 for ; Fri, 6 May 2005 16:41:47 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU9sS-0001ga-0T for ecrit@ietf.org; Fri, 06 May 2005 16:56:53 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j46KfcF9028073 for ; Fri, 6 May 2005 22:41:38 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j46Kfba4028642 for ; Fri, 6 May 2005 22:41:37 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 6 May 2005 22:41:37 +0200 Message-ID: From: Tschofenig Hannes To: "'ecrit@ietf.org'" Date: Fri, 6 May 2005 22:38:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] WG: I-D ACTION:draft-schulzrinne-ecrit-requirements-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 this document is an attempt to consolidate the requirements of the individual documents into a single document. as indicated at the ecrit working group meeting henning's document was used as the starting = point.=20 the draft authors of the other requirements documents have tried to determine whether their requirements are already covered by henning's document. roger incorporated them if they weren't. roger also clean up = the terminology and removed non-relevant parts. thanks for the good work, = roger. please review the document carefully. we will spend some time at the = interim meeting to discuss the open issues.=20 ciao hannes -----Urspr=FCngliche Nachricht----- Von: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] Im Auftrag von Internet-Drafts@ietf.org Gesendet: Freitag, 6. Mai 2005 21:44 An: i-d-announce@ietf.org Betreff: I-D ACTION:draft-schulzrinne-ecrit-requirements-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Emergency Context Resolution=20 with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-schulzrinne-ecrit-requirements-00.txt Pages : 38 Date : 2005-5-6 =09 This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet = multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements= -00. txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schulzrinne-ecrit-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schulzrinne-ecrit-requirements-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 09 05:51:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV4vc-000247-7D; Mon, 09 May 2005 05:51:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV4va-000242-H1 for ecrit@megatron.ietf.org; Mon, 09 May 2005 05:51:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21783 for ; Mon, 9 May 2005 05:51:52 -0400 (EDT) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV5Ae-0000KP-KI for ecrit@ietf.org; Mon, 09 May 2005 06:07:30 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j499pfWF010817 for ; Mon, 9 May 2005 11:51:41 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j499pe4D020913 for ; Mon, 9 May 2005 11:51:40 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 9 May 2005 11:51:40 +0200 Message-ID: From: Tschofenig Hannes To: "'ecrit@ietf.org'" Date: Mon, 9 May 2005 11:48:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Ecrit] security threats and requirements X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all, we have not seen much input on the security threats and requirements so far. hence, we (henning, raj and myself) have tried to work on a document to capture a few aspects: http://www.ietf-ecrit.org/cache/draft-tschofenig-ecrit-security-threats-00.t xt ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 09 09:38:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV8TK-0006Vn-1M; Mon, 09 May 2005 09:38:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV8TJ-0006Vi-AP for ecrit@megatron.ietf.org; Mon, 09 May 2005 09:38:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12385 for ; Mon, 9 May 2005 09:38:55 -0400 (EDT) Message-Id: <200505091338.JAA12385@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV8iQ-0000Lb-QZ for ecrit@ietf.org; Mon, 09 May 2005 09:54:35 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DV8T3-0000Be-TF; Mon, 09 May 2005 08:38:42 -0500 From: "Brian Rosen" To: "'Tschofenig Hannes'" , Subject: RE: [Ecrit] security threats and requirements Date: Mon, 9 May 2005 09:38:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcVUfNLYZYGRRwt4SvyDLJ+jRl4OyAAGetRg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thanks for working on this. On the threat side, I think you have not explicitly covered corruption of, or masquerading as the database. There is wording about corruption of configuration information, which, depending on how the database is used, could be included. If you think of it as a run time lookup (location in, URI out) it's not configuration data. There is text in the Impersonating a PSAP threat that discusses how corruption of or impersonating the database would allow impersonating a PSAP, but those are two threats. You have covered denial of service attacks on the database adequately. In the 5.3 location spoofing section, there is some text talking about the coverage area of a wireless network. While this is true of some systems (geosynchronous satellites, for example), it is less true in more common cases, where you may have access to the "tower" location currently serving the AIP subscriber. More on that below. I can't make any sense of this bullet point: The recipient of the asserted location information MUST have a way to verify that the asserting party is indeed authorized to create such an assertion. As such, authentication is insufficient if not further authorization decision can be associated to the authenticated identity. The second sentence isn't a sentence, and I'm unable to guess what you are talking about. The discussion which follows seems to me more applicable to identity spoofing than location spoofing. I guess they are related in that if someone spoofs location, you'd like to be able to find out who it was that did it, but it's a pretty tenuous connection. In the section on impersonating a PSAP, you have a discussion about impersonating the database. These are two independent entities. Both threats exist, and must be considered separately. The text is actually about impersonating the database. A security requirement to mitigate the threat of impersonating the PSAP is to have a way to authenticate that the UA answering the call is in fact a legitimate, and duly authorized PSAP. The number of PSAPs is small enough, and they are already creatures of government, so that the idea that we could create a PKI covering them seems doable, for example. I'd like to explore the issue of location spoofing a little more. I make the following observation: There is ALWAYS an Access Infrastructure Provider In almost every case, the AIP is actually some kind of carrier. In a very small number of cases, an enterprise can create a path that does not use a carrier (they can use a free space laser for example). However, the carrier is not always in a position to supply accurate enough information. An easy example is an enterprise PBX where the enterprise knows building, room and floor information, but the AIP doesn't. This leads me to suggest that we consider always requiring an AIP provided location, which may be supplemented by another entity, such as an enterprise. Since AIPs are local, the local authorities could reasonably provide them with a CA path that is verifiable. In cases where the AIP is not providing an IP service, but merely a circuit, the location would have a very long effective lifetime, and could be sent from the AIP to the enterprise via an offline mechanism or email. In a typical residential broadband case, the AIP normally provides location. A sophisticated home owner could provide room level location supplementary to that. A typical small enterprise would be the same. A medium or large enterprise with a single site would work the same, but depending on local ordinance, may be required to provide room level location. A multisite enterprise using IP services from AIPs would get the location from the AIP periodically. This would include a branch facility. The enterprise may have to select from a portfolio of authenticated location objects, one per site, that it obtains from its AIPs, adding its own building/room/floor data. The case of enterprise using a bare bit transport facility with no IP service would get a long-lived location off line from the AIP of that facility. In the case of an actual private circuit, the local authorities may sign the enterprise site cert, which it then uses. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Tschofenig Hannes > Sent: Monday, May 09, 2005 5:49 AM > To: 'ecrit@ietf.org' > Subject: [Ecrit] security threats and requirements > > hi all, > > we have not seen much input on the security threats and requirements so > far. > > hence, we (henning, raj and myself) have tried to work on a document to > capture a few aspects: > http://www.ietf-ecrit.org/cache/draft-tschofenig-ecrit-security-threats- > 00.t > xt > > ciao > hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 09 21:11:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVJHt-0001PI-CZ; Mon, 09 May 2005 21:11:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVJHs-0001PD-72 for ecrit@megatron.ietf.org; Mon, 09 May 2005 21:11:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04719 for ; Mon, 9 May 2005 21:11:45 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVJX0-0005Ns-Nx for ecrit@ietf.org; Mon, 09 May 2005 21:27:31 -0400 Received: from [192.168.0.31] (pool-138-89-81-67.mad.east.verizon.net [138.89.81.67]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4A1BhcN011688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 May 2005 21:11:44 -0400 (EDT) Message-ID: <42800A69.90607@cs.columbia.edu> Date: Mon, 09 May 2005 21:12:09 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] security threats and requirements References: <200505091338.JAA12385@ietf.org> In-Reply-To: <200505091338.JAA12385@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > In the 5.3 location spoofing section, there is some text talking about the > coverage area of a wireless network. While this is true of some systems > (geosynchronous satellites, for example), it is less true in more common > cases, where you may have access to the "tower" location currently serving > the AIP subscriber. I think in general, spoofing needs to be made more precise: "wide-area spoofing", i.e., "caller in Iowa can summon police to address in Florida" and 'local-area' spoofing, i.e., limited to a few miles. > > More on that below. > > I can't make any sense of this bullet point: > The recipient of the asserted location information MUST have a way > to verify that the asserting party is indeed authorized to create > such an assertion. As such, authentication is insufficient if not > further authorization decision can be associated to the > authenticated identity. > > The second sentence isn't a sentence, and I'm unable to guess what you are > talking about. I think this is best deleted. > > The discussion which follows seems to me more applicable to identity > spoofing than location spoofing. I guess they are related in that if > someone spoofs location, you'd like to be able to find out who it was that > did it, but it's a pretty tenuous connection. We should probably make a more explicit connection. There are layers of defense: - prevent wide-area spoofing (solves the difficulty of prosecuting some guy in Russia in France) - increase accountability (if spoofing occurs, there's a reasonable chance that the person can be brought to justice or at least that future calls from the same person are considered suspect) - prevent local-area spoofing (prevent somebody who is not in place X from pretending to be there) - prevent local-area cloning (prevent person from pretending to be in place X if they were actually there a while ago) > I make the following observation: > There is ALWAYS an Access Infrastructure Provider > In almost every case, the AIP is actually some kind of carrier. In a very > small number of cases, an enterprise can create a path that does not use a > carrier (they can use a free space laser for example). > > However, the carrier is not always in a position to supply accurate enough > information. An easy example is an enterprise PBX where the enterprise > knows building, room and floor information, but the AIP doesn't. In many cases, the distinction between enterprise and carrier is dicey. Columbia University is an end user, but it is not fundamentally different from an ISP (and probably has more users than a large fraction of them). By the same token, the local ISP that serves Smalltown, KS, but gets its bandwidth from a T1 provider wouldn't be an AIP, either. Columbia's service area is small, but there are state university campuses that probably exceed the service area of many small WiFi or DSL ISPs. As far as I know, you don't need a license (beyond maybe a business license) to be an ISP, including one that offers WiMax or dial-up services. > A multisite enterprise using IP services from AIPs would get the location > from the AIP periodically. This would include a branch facility. The > enterprise may have to select from a portfolio of authenticated location > objects, one per site, that it obtains from its AIPs, adding its own > building/room/floor data. > > The case of enterprise using a bare bit transport facility with no IP > service would get a long-lived location off line from the AIP of that > facility. > > In the case of an actual private circuit, the local authorities may sign the > enterprise site cert, which it then uses. Rather than assuming a single AIP, I think a hierarchy is much more generic and avoids silly definitional discussions as why Bob's Corner DSL & Tackle is an AIP and Ohio State University isn't. As you note, each provider of IP or circuit connectivity provides a signed location blob, in some fashion, to the downstream customer. That way, if Bob's Corner DSL & Tackle isn't trust, but its upstream provider is, at least wide-area location fraud is made less likely. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 09 21:54:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVJxT-00080b-R5; Mon, 09 May 2005 21:54:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVJxS-00080W-S7 for ecrit@megatron.ietf.org; Mon, 09 May 2005 21:54:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07999 for ; Mon, 9 May 2005 21:54:49 -0400 (EDT) Message-Id: <200505100154.VAA07999@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVKCf-0006ox-Lq for ecrit@ietf.org; Mon, 09 May 2005 22:10:35 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DVJxF-00049Z-E3; Mon, 09 May 2005 20:54:38 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] security threats and requirements Date: Mon, 9 May 2005 21:54:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <42800A69.90607@cs.columbia.edu> Thread-Index: AcVU/TtnBL8z3mK3SpWAq8QKLc66RQABSlrw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning Your responses seem very reasonable. I'm not sure if we need more than two levels of hierarchy, but I suppose we might as well make it general and allow for it. One has to differentiate between an AIP and an ISP. One entity can be both, of course. The difference is that the AIP actually owns the infrastructure, and actually can determine where you are. The issue is, the AIP may not have any relationship with, and cannot provide any path to the subscriber. The ISP can. The question becomes, do you just pass through the location from the AIP to the ISP to the subscriber, or do you create a transitive trust relationship so that the AIP tells the ISP and the ISP tells the subscriber the location. It's a question of who signs the location the subscriber gets, the AIP or the ISP. I like the former, because I really worry how we do the CA chain. The latter is more attractive to the ISP of course. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, May 09, 2005 9:12 PM > To: Brian Rosen > Cc: 'Tschofenig Hannes'; ecrit@ietf.org > Subject: Re: [Ecrit] security threats and requirements > > Brian Rosen wrote: > > > In the 5.3 location spoofing section, there is some text talking about > the > > coverage area of a wireless network. While this is true of some systems > > (geosynchronous satellites, for example), it is less true in more common > > cases, where you may have access to the "tower" location currently > serving > > the AIP subscriber. > > I think in general, spoofing needs to be made more precise: "wide-area > spoofing", i.e., "caller in Iowa can summon police to address in > Florida" and 'local-area' spoofing, i.e., limited to a few miles. > > > > > More on that below. > > > > I can't make any sense of this bullet point: > > The recipient of the asserted location information MUST have a way > > to verify that the asserting party is indeed authorized to create > > such an assertion. As such, authentication is insufficient if not > > further authorization decision can be associated to the > > authenticated identity. > > > > The second sentence isn't a sentence, and I'm unable to guess what you > are > > talking about. > > I think this is best deleted. > > > > > > The discussion which follows seems to me more applicable to identity > > spoofing than location spoofing. I guess they are related in that if > > someone spoofs location, you'd like to be able to find out who it was > that > > did it, but it's a pretty tenuous connection. > > We should probably make a more explicit connection. There are layers of > defense: > > - prevent wide-area spoofing (solves the difficulty of prosecuting some > guy in Russia in France) > > - increase accountability (if spoofing occurs, there's a reasonable > chance that the person can be brought to justice or at least that future > calls from the same person are considered suspect) > > - prevent local-area spoofing (prevent somebody who is not in place X > from pretending to be there) > > - prevent local-area cloning (prevent person from pretending to be in > place X if they were actually there a while ago) > > > > I make the following observation: > > There is ALWAYS an Access Infrastructure Provider > > In almost every case, the AIP is actually some kind of carrier. In a > very > > small number of cases, an enterprise can create a path that does not use > a > > carrier (they can use a free space laser for example). > > > > However, the carrier is not always in a position to supply accurate > enough > > information. An easy example is an enterprise PBX where the enterprise > > knows building, room and floor information, but the AIP doesn't. > > In many cases, the distinction between enterprise and carrier is dicey. > Columbia University is an end user, but it is not fundamentally > different from an ISP (and probably has more users than a large fraction > of them). By the same token, the local ISP that serves Smalltown, KS, > but gets its bandwidth from a T1 provider wouldn't be an AIP, either. > > Columbia's service area is small, but there are state university > campuses that probably exceed the service area of many small WiFi or DSL > ISPs. > > As far as I know, you don't need a license (beyond maybe a business > license) to be an ISP, including one that offers WiMax or dial-up > services. > > > > A multisite enterprise using IP services from AIPs would get the > location > > from the AIP periodically. This would include a branch facility. The > > enterprise may have to select from a portfolio of authenticated location > > objects, one per site, that it obtains from its AIPs, adding its own > > building/room/floor data. > > > > The case of enterprise using a bare bit transport facility with no IP > > service would get a long-lived location off line from the AIP of that > > facility. > > > > In the case of an actual private circuit, the local authorities may sign > the > > enterprise site cert, which it then uses. > > Rather than assuming a single AIP, I think a hierarchy is much more > generic and avoids silly definitional discussions as why Bob's Corner > DSL & Tackle is an AIP and Ohio State University isn't. > > As you note, each provider of IP or circuit connectivity provides a > signed location blob, in some fashion, to the downstream customer. That > way, if Bob's Corner DSL & Tackle isn't trust, but its upstream provider > is, at least wide-area location fraud is made less likely. > > Henning > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 09 22:13:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVKCn-0002AI-DQ; Mon, 09 May 2005 22:10:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVKCm-0002AD-AV for ecrit@megatron.ietf.org; Mon, 09 May 2005 22:10:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08735 for ; Mon, 9 May 2005 22:10:38 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVKRy-0007H1-Az for ecrit@ietf.org; Mon, 09 May 2005 22:26:24 -0400 Received: from [192.168.0.31] (pool-138-89-81-67.mad.east.verizon.net [138.89.81.67]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4A2AQOq021269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 May 2005 22:10:30 -0400 (EDT) Message-ID: <4280182D.3090909@cs.columbia.edu> Date: Mon, 09 May 2005 22:10:53 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] security threats and requirements References: <200505100154.j4A1slqt003483@cs.columbia.edu> In-Reply-To: <200505100154.j4A1slqt003483@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org While there are probably definitions that we can come up with that cleanly differentiate AIP and ISP, I'm a bit worried that this strays a bit too far into policy and business land for a standard. What does it mean to "own" infrastructure? Does leasing count? Do I have to lease it for 10 years to count as owner? I don't see a need to decide and get into business classification. In most practical cases, both ISP and AIP have a pretty reliable notion of where the customer gets service and can provide the customer with a certificate to that effect. The customer can choose which one(s) it uses and would presumably have some interest in clearing up any mistakes ahead of time. Ohio State University has staff to deal with this and Archie Bunker has a single provider and doesn't care about the difference between ISP and AIP. Henning Brian Rosen wrote: > Henning > > Your responses seem very reasonable. I'm not sure if we need more than two > levels of hierarchy, but I suppose we might as well make it general and > allow for it. > > One has to differentiate between an AIP and an ISP. One entity can be both, > of course. The difference is that the AIP actually owns the infrastructure, > and actually can determine where you are. The issue is, the AIP may not > have any relationship with, and cannot provide any path to the subscriber. > The ISP can. > > The question becomes, do you just pass through the location from the AIP to > the ISP to the subscriber, or do you create a transitive trust relationship > so that the AIP tells the ISP and the ISP tells the subscriber the location. > It's a question of who signs the location the subscriber gets, the AIP or > the ISP. > > I like the former, because I really worry how we do the CA chain. The > latter is more attractive to the ISP of course. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 10 07:41:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVT7W-00060E-DX; Tue, 10 May 2005 07:41:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVT7V-000609-LH for ecrit@megatron.ietf.org; Tue, 10 May 2005 07:41:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17081 for ; Tue, 10 May 2005 07:41:48 -0400 (EDT) Message-Id: <200505101141.HAA17081@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVTMn-0000wz-Iw for ecrit@ietf.org; Tue, 10 May 2005 07:57:39 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DVT7G-0003E6-8H; Tue, 10 May 2005 06:41:34 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] security threats and requirements Date: Tue, 10 May 2005 07:41:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4280182D.3090909@cs.columbia.edu> Thread-Index: AcVVBXNyC/ksBW98Q/GdBPkN9LzMLQATndvg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree we don't have to be very careful about differentiating. The essential difference really becomes who really does know where the wire ends? In most cases, this is obvious; it's the entity that terminates layer 2. I think that in the end, the local emergency calling authorities will sign the cert that the entity that really determines location uses to sign the location object. I think the text of the document need only state that the entity providing location has to have the ability to effectively determine the actual source of the packets by, for example, determining the wire pair or circuit ID or cable modem, etc they came from. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, May 09, 2005 10:11 PM > To: Brian Rosen > Cc: 'Tschofenig Hannes'; ecrit@ietf.org > Subject: Re: [Ecrit] security threats and requirements > > While there are probably definitions that we can come up with that > cleanly differentiate AIP and ISP, I'm a bit worried that this strays a > bit too far into policy and business land for a standard. What does it > mean to "own" infrastructure? Does leasing count? Do I have to lease it > for 10 years to count as owner? > > I don't see a need to decide and get into business classification. In > most practical cases, both ISP and AIP have a pretty reliable notion of > where the customer gets service and can provide the customer with a > certificate to that effect. The customer can choose which one(s) it uses > and would presumably have some interest in clearing up any mistakes > ahead of time. Ohio State University has staff to deal with this and > Archie Bunker has a single provider and doesn't care about the > difference between ISP and AIP. > > Henning > > Brian Rosen wrote: > > Henning > > > > Your responses seem very reasonable. I'm not sure if we need more than > two > > levels of hierarchy, but I suppose we might as well make it general and > > allow for it. > > > > One has to differentiate between an AIP and an ISP. One entity can be > both, > > of course. The difference is that the AIP actually owns the > infrastructure, > > and actually can determine where you are. The issue is, the AIP may not > > have any relationship with, and cannot provide any path to the > subscriber. > > The ISP can. > > > > The question becomes, do you just pass through the location from the AIP > to > > the ISP to the subscriber, or do you create a transitive trust > relationship > > so that the AIP tells the ISP and the ISP tells the subscriber the > location. > > It's a question of who signs the location the subscriber gets, the AIP > or > > the ISP. > > > > I like the former, because I really worry how we do the CA chain. The > > latter is more attractive to the ISP of course. > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 10 08:22:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVTkp-0005Nw-Vk; Tue, 10 May 2005 08:22:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVTko-0005Nq-SD for ecrit@megatron.ietf.org; Tue, 10 May 2005 08:22:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20450 for ; Tue, 10 May 2005 08:22:25 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DVU07-0003zi-7v for ecrit@ietf.org; Tue, 10 May 2005 08:38:16 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 10 May 2005 14:25:17 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BE75@oefeg-s04.oefeg.loc> Thread-Topic: ECRIT requirements - Comments to Rx and Ax Thread-Index: AcU9B6UzWE/J7oqrT0KXeyHVEUtImAOeGizwAB+DIlACVvHCeQ== From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] ECRIT requirements - Comments to Rx and Ax X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Dear all, =20 I want to repeat my comments on the ecrit list to the ecrit-reqirements = not dealt with by Roger yet in the published draft-schulzrinne-ecrit-requirements-00 =20 =20 R2 International see discussion on A1 on Universal and Global R4 Multiple Modes Maybe we have to split this: IPSAPs MUST support multiple modes Devices MAY support multiple modes, but which mode is supported depends on the device capabilities. It is recommended that devices support at least voice. Comments to Section 4 - Ax Starting backwards from the Ed. Comment to A7 Clarification sought on whether 9-1-1 equates to local or universal I think we first have to reach consitency with the terms International/universal/global (which are used inconsistently in the document)and with local/(national) I personally prefer Global - local, Because international is something in between but in any case the terms need to be included in the terminology and explained, especially that global is global and international is used in more than one country and local means in most cases also national, and that the NANP local means within the NANP region (puh) In addition we need a definition of: Foreign local (where you currently are) and Home local (where you are from) Now we run into the problem of defining 911 and 112. Both are international, but according what I said above 911 is also local. So A1 should either be International or Global Since I proposed 911 and 112 as global identifiers, We need to update the text in the remaining reqs. A2. I suggest reconsidering the whole requirement, taking the comments into account (3 reqs!) What do we want to say? 1.UAs, proxies and call routers MUST recognize the global identifiers, 2.they MUST/should/may? recognize the foreign local identifiers 3. they MUST/should/may? recognize the home local (A7) What to do if the home local clashes with a foreign local short code? What takes precedence? A3 Additional req: Since emergency calls must be recognized By UA, proxies and other network elements, it is required that local identifiers are converted to global identifiers. This replaces eventually part of A7 Regards Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 10 10:14:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVT1-0005ZW-ND; Tue, 10 May 2005 10:12:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVSz-0005WM-HQ for ecrit@megatron.ietf.org; Tue, 10 May 2005 10:12:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29052 for ; Tue, 10 May 2005 10:12:07 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVViJ-0002fF-Vm for ecrit@ietf.org; Tue, 10 May 2005 10:28:00 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 10 May 2005 10:26:38 -0400 X-IronPort-AV: i="3.92,172,1112587200"; d="scan'208"; a="48581977:sNHT740113928" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4AEBYnc012966; Tue, 10 May 2005 10:11:57 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 10:11:07 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] security threats and requirements X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 10 May 2005 10:11:07 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E31C60BB@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] security threats and requirements Thread-Index: AcVVBtfiQfbhAQwnTYusrEKfm+qZGwAYjo/g From: "Michael Hammer \(mhammer\)" To: "Henning Schulzrinne" , "Brian Rosen" X-OriginalArrivalTime: 10 May 2005 14:11:07.0998 (UTC) FILETIME=[1C5257E0:01C5556A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning, While you don't want to standardize business relationships, you do need to operate in business environments where there might be adversarial relationships. What if two companies want to provide telephony service, a local ISP and a remote SP. The customer may choose the remote SP and IPSEC or TLS tunnel to it. Does the local ISP charge an exorbitant fee to make the location determination, whereas that charge would be lower if the customer had chosen to use it for telephony service in addition to Internet access? Would it be sufficient for E911 folks, if the user can just register his location with the remote SP? Could the home network provider (super-small ISP) sign the location himself as a capability of his consumer box? Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Henning Schulzrinne > Sent: Monday, May 09, 2005 10:11 PM > To: Brian Rosen > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] security threats and requirements >=20 > While there are probably definitions that we can come up with=20 > that cleanly differentiate AIP and ISP, I'm a bit worried=20 > that this strays a bit too far into policy and business land=20 > for a standard. What does it mean to "own" infrastructure?=20 > Does leasing count? Do I have to lease it for 10 years to=20 > count as owner? >=20 > I don't see a need to decide and get into business=20 > classification. In most practical cases, both ISP and AIP=20 > have a pretty reliable notion of where the customer gets=20 > service and can provide the customer with a certificate to=20 > that effect. The customer can choose which one(s) it uses and=20 > would presumably have some interest in clearing up any=20 > mistakes ahead of time. Ohio State University has staff to=20 > deal with this and Archie Bunker has a single provider and=20 > doesn't care about the difference between ISP and AIP. >=20 > Henning >=20 > Brian Rosen wrote: > > Henning > >=20 > > Your responses seem very reasonable. I'm not sure if we need more=20 > > than two levels of hierarchy, but I suppose we might as=20 > well make it=20 > > general and allow for it. > >=20 > > One has to differentiate between an AIP and an ISP. One=20 > entity can be=20 > > both, of course. The difference is that the AIP actually owns the=20 > > infrastructure, and actually can determine where you are. =20 > The issue=20 > > is, the AIP may not have any relationship with, and cannot=20 > provide any path to the subscriber. > > The ISP can. > >=20 > > The question becomes, do you just pass through the location=20 > from the=20 > > AIP to the ISP to the subscriber, or do you create a=20 > transitive trust=20 > > relationship so that the AIP tells the ISP and the ISP=20 > tells the subscriber the location. > > It's a question of who signs the location the subscriber=20 > gets, the AIP=20 > > or the ISP. > >=20 > > I like the former, because I really worry how we do the CA=20 > chain. The=20 > > latter is more attractive to the ISP of course. > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 10 10:26:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVhH-0008IA-Nl; Tue, 10 May 2005 10:26:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVhF-0008Hy-FW for ecrit@megatron.ietf.org; Tue, 10 May 2005 10:26:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00863 for ; Tue, 10 May 2005 10:26:51 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVVwZ-0003iA-2u for ecrit@ietf.org; Tue, 10 May 2005 10:42:44 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j4AEPkh3027239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 May 2005 10:25:47 -0400 (EDT) Message-ID: <4280C464.2060706@cs.columbia.edu> Date: Tue, 10 May 2005 10:25:40 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Ecrit] security threats and requirements References: <072C5B76F7CEAB488172C6F64B30B5E31C60BB@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E31C60BB@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I do think there's a real possibility for creating, inadvertently, a mechanism for price-gouging and anti-competitive behavior if we restrict the ability of who can certify locations. For that reason, we need to allow a variety of entities to vouch for location, including non-carriers. Why shouldn't my local Chamber of Commerce certify the location of my small business if I can't get the local carrier to cooperate? The business is unlikely to move frequently, so creating an elaborate dynamic mechanism designed to deal with moves on ten-minute intervals is neither necessary nor expedient. Michael Hammer (mhammer) wrote: > Henning, > > While you don't want to standardize business relationships, you do need > to operate in business environments where there might be adversarial > relationships. What if two companies want to provide telephony service, > a local ISP and a remote SP. The customer may choose the remote SP and > IPSEC or TLS tunnel to it. Does the local ISP charge an exorbitant fee > to make the location determination, whereas that charge would be lower > if the customer had chosen to use it for telephony service in addition > to Internet access? Would it be sufficient for E911 folks, if the user > can just register his location with the remote SP? Could the home > network provider (super-small ISP) sign the location himself as a > capability of his consumer box? > > Mike > > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>On Behalf Of Henning Schulzrinne >>Sent: Monday, May 09, 2005 10:11 PM >>To: Brian Rosen >>Cc: ecrit@ietf.org >>Subject: Re: [Ecrit] security threats and requirements >> >>While there are probably definitions that we can come up with >>that cleanly differentiate AIP and ISP, I'm a bit worried >>that this strays a bit too far into policy and business land >>for a standard. What does it mean to "own" infrastructure? >>Does leasing count? Do I have to lease it for 10 years to >>count as owner? >> >>I don't see a need to decide and get into business >>classification. In most practical cases, both ISP and AIP >>have a pretty reliable notion of where the customer gets >>service and can provide the customer with a certificate to >>that effect. The customer can choose which one(s) it uses and >>would presumably have some interest in clearing up any >>mistakes ahead of time. Ohio State University has staff to >>deal with this and Archie Bunker has a single provider and >>doesn't care about the difference between ISP and AIP. >> >>Henning >> >>Brian Rosen wrote: >> >>>Henning >>> >>>Your responses seem very reasonable. I'm not sure if we need more >>>than two levels of hierarchy, but I suppose we might as >> >>well make it >> >>>general and allow for it. >>> >>>One has to differentiate between an AIP and an ISP. One >> >>entity can be >> >>>both, of course. The difference is that the AIP actually owns the >>>infrastructure, and actually can determine where you are. >> >>The issue >> >>>is, the AIP may not have any relationship with, and cannot >> >>provide any path to the subscriber. >> >>>The ISP can. >>> >>>The question becomes, do you just pass through the location >> >>from the >> >>>AIP to the ISP to the subscriber, or do you create a >> >>transitive trust >> >>>relationship so that the AIP tells the ISP and the ISP >> >>tells the subscriber the location. >> >>>It's a question of who signs the location the subscriber >> >>gets, the AIP >> >>>or the ISP. >>> >>>I like the former, because I really worry how we do the CA >> >>chain. The >> >>>latter is more attractive to the ISP of course. >>> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 10 15:53:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVanN-0005Vj-2F; Tue, 10 May 2005 15:53:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVanL-0005Ve-55 for ecrit@megatron.ietf.org; Tue, 10 May 2005 15:53:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07550 for ; Tue, 10 May 2005 15:53:28 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVb2g-0001b3-RS for ecrit@ietf.org; Tue, 10 May 2005 16:09:24 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j4AJrIve022037; Tue, 10 May 2005 21:53:18 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j4AJrHYu030503; Tue, 10 May 2005 21:53:18 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 10 May 2005 21:53:17 +0200 Message-ID: From: Tschofenig Hannes To: "'Brian Rosen'" , ecrit@ietf.org Subject: AW: [Ecrit] security threats and requirements Date: Tue, 10 May 2005 21:50:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi brian,=20 thanks for your comments. many of them have been addressed by henning. = let me add a few small remarks.=20 > -----Urspr=FCngliche Nachricht----- > Von: Brian Rosen [mailto:br@brianrosen.net]=20 > Gesendet: Montag, 9. Mai 2005 15:38 > An: Tschofenig Hannes; ecrit@ietf.org > Betreff: RE: [Ecrit] security threats and requirements >=20 >=20 > Thanks for working on this. >=20 > On the threat side, I think you have not explicitly covered=20 > corruption of, > or masquerading as the database. There is wording about corruption = of > configuration information, which, depending on how the=20 > database is used, > could be included. If you think of it as a run time lookup=20 > (location in, > URI out) it's not configuration data. There is text in the=20 > Impersonating a > PSAP threat that discusses how corruption of or impersonating=20 > the database > would allow impersonating a PSAP, but those are two threats. =20 the threat about configuration data is not supposed to address your corruption and masquerading of a database.=20 in fact, i guess we should spent more text on the threat for the = database.=20 the problem with these types of threat documents is (and i know it = already from another document) that you have to stay at a pretty high level = because you cannot address specific solutions and protocols AND you cannot = assume that some security protection is already there (since the purpose of = the threat document is defeated partially).=20 i have no good answer how to provide a clear balance between the = threats that are really important and those how are pretty obvious and = addressed in every security related document.=20 >=20 > You have covered denial of service attacks on the database = adequately. >=20 > In the 5.3 location spoofing section, there is some text=20 > talking about the > coverage area of a wireless network. While this is true of=20 > some systems > (geosynchronous satellites, for example), it is less true in=20 > more common > cases, where you may have access to the "tower" location=20 > currently serving > the AIP subscriber. if i understood you correctly then this is also just a variation of the other one and a different party that fetches the location information. = in umts based networks, for example, the network knows the location info = of their subscribers and protocols executed between entities in the = networks (location client and location server) exchange information about the = end host.=20 >=20 > More on that below. >=20 > I can't make any sense of this bullet point: > The recipient of the asserted location information MUST=20 > have a way > to verify that the asserting party is indeed authorized=20 > to create > such an assertion. As such, authentication is=20 > insufficient if not > further authorization decision can be associated to the > authenticated identity. >=20 > The second sentence isn't a sentence, and I'm unable to guess=20 > what you are > talking about. the second sentence is indeed not a sentence. my fault. the whole paragraph was trying to point to the fact that that = authorization needs to be considered.=20 a digital signature is fine and it allows you to determine who signed = it.=20 it does not immediately allow you determine whether this is indeed = someone who is provider that is allowed to assert location information.=20 i don't know whether it makes sense to even say that a particular = provider is allowed to authorize location for a particular area only.=20 (there are certainly a number of problems particularly if we consider = moving networks etc.) >=20 > The discussion which follows seems to me more applicable to identity > spoofing than location spoofing. I guess they are related in that if > someone spoofs location, you'd like to be able to find out=20 > who it was that > did it, but it's a pretty tenuous connection. >=20 > In the section on impersonating a PSAP, you have a discussion about > impersonating the database. These are two independent entities. = Both > threats exist, and must be considered separately. i guess we should describe what we mean by database.=20 i guess you think mostly about your "Master Street Address Guide" = database.=20 > The text=20 > is actually > about impersonating the database. A security requirement to=20 > mitigate the > threat of impersonating the PSAP is to have a way to=20 > authenticate that the > UA answering the call is in fact a legitimate, and duly=20 > authorized PSAP. yes.=20 additionally, one needs to consider the discovery aspect.=20 if your discovery procedure returns you the wrong psap then the = subsequent authentication only ensures that you talk to the psap (but it is still = the wrong one). whether the psap is indeed a legitimate psap is also an authorization = issue. > The number of PSAPs is small enough, and they are already creatures = of > government, so that the idea that we could create a PKI=20 > covering them seems > doable, for example. maybe >=20 >=20 regarding the long paragraph below:=20 i read your long discussion with henning about the access = infrastructure provider, etc.=20 i have no particular good suggestion for the terminology. maybe we can = use the terminology from other places, for example: " ASP Access Service Provider. A network operator that provides direct IP packet forwarding to and from the end host. " taken from section 1.3 of http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-02.txt this definition might not be perfect either but the mobile ip folks are happy with it.=20 > I'd like to explore the issue of location spoofing a little more. > I make the following observation: > There is ALWAYS an Access Infrastructure Provider > In almost every case, the AIP is actually some kind of=20 > carrier. In a very > small number of cases, an enterprise can create a path that=20 > does not use a > carrier (they can use a free space laser for example). >=20 > However, the carrier is not always in a position to supply=20 > accurate enough > information. An easy example is an enterprise PBX where the=20 > enterprise > knows building, room and floor information, but the AIP doesn't. >=20 > This leads me to suggest that we consider always requiring an=20 > AIP provided > location, which may be supplemented by another entity, such as an > enterprise. Since AIPs are local, the local authorities=20 > could reasonably > provide them with a CA path that is verifiable. >=20 > In cases where the AIP is not providing an IP service, but=20 > merely a circuit, > the location would have a very long effective lifetime, and=20 > could be sent > from the AIP to the enterprise via an offline mechanism or email.=20 >=20 > In a typical residential broadband case, the AIP normally=20 > provides location. > A sophisticated home owner could provide room level location=20 > supplementary > to that. >=20 > A typical small enterprise would be the same. >=20 > A medium or large enterprise with a single site would work=20 > the same, but > depending on local ordinance, may be required to provide room level > location. >=20 > A multisite enterprise using IP services from AIPs would get=20 > the location > from the AIP periodically. This would include a branch facility. = The > enterprise may have to select from a portfolio of=20 > authenticated location > objects, one per site, that it obtains from its AIPs, adding its own > building/room/floor data.=20 >=20 > The case of enterprise using a bare bit transport facility with no IP > service would get a long-lived location off line from the AIP of that > facility. >=20 > In the case of an actual private circuit, the local=20 > authorities may sign the > enterprise site cert, which it then uses. >=20 > Brian ciao hannes >=20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf Of > > Tschofenig Hannes > > Sent: Monday, May 09, 2005 5:49 AM > > To: 'ecrit@ietf.org' > > Subject: [Ecrit] security threats and requirements > >=20 > > hi all, > >=20 > > we have not seen much input on the security threats and=20 > requirements so > > far. > >=20 > > hence, we (henning, raj and myself) have tried to work on a=20 > document to > > capture a few aspects: > >=20 > http://www.ietf-ecrit.org/cache/draft-tschofenig-ecrit-securit y-threats- > 00.t > xt >=20 > ciao > hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 10 16:48:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVben-0002XQ-KD; Tue, 10 May 2005 16:48:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVbem-0002XH-Hl for ecrit@megatron.ietf.org; Tue, 10 May 2005 16:48:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19173 for ; Tue, 10 May 2005 16:48:42 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVbu9-00071u-4m for ecrit@ietf.org; Tue, 10 May 2005 17:04:38 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j4AKmfPB021040 for ; Tue, 10 May 2005 22:48:41 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j4AKmfVw004374 for ; Tue, 10 May 2005 22:48:41 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 10 May 2005 22:48:41 +0200 Message-ID: From: Tschofenig Hannes To: "'ecrit@ietf.org'" Date: Tue, 10 May 2005 22:45:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ecrit] interim meeting attendance X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all, i was asked by a few people whether the ecrit/geopriv interim meeting is open for everyone and whether there are some restrictions regarding the attendance. there is no restriction; everyone is allowed to attend the ecrit/geopriv interim meeting. please register for the meeting (please send email to Rosemary Addarich ) to give henning a chance select a room that is large enough for us all. ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 10 17:02:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVbsT-00076m-1Y; Tue, 10 May 2005 17:02:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVbsQ-00076e-PF for ecrit@megatron.ietf.org; Tue, 10 May 2005 17:02:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20263 for ; Tue, 10 May 2005 17:02:48 -0400 (EDT) Message-Id: <200505102102.RAA20263@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVc7o-0007jU-BL for ecrit@ietf.org; Tue, 10 May 2005 17:18:45 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DVbsF-00085r-5j; Tue, 10 May 2005 16:02:39 -0500 From: "Brian Rosen" To: "'Tschofenig Hannes'" , Subject: RE: [Ecrit] security threats and requirements Date: Tue, 10 May 2005 17:02:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcVVmepZdGCMNhtxT322yP4OBLyvUwABha5g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes See inline, edited for brevity > the problem with these types of threat documents is (and i know it already > from another document) that you have to stay at a pretty high level > because > you cannot address specific solutions and protocols AND you cannot assume > that some security protection is already there (since the purpose of the > threat document is defeated partially). > > i have no good answer how to provide a clear balance between the threats > that are really important and those how are pretty obvious and addressed > in > every security related document. I think it is quite clear that you need some kind of database to translate location to PSAP. When you do the translation, how you do it, what the translation results in are not decided, but I don't think there is any other way to determine which PSAP gets the call. Therefore, I think you are quite safe in discussing the database as an entity in this document. > > In the 5.3 location spoofing section, there is some text > > talking about the > > coverage area of a wireless network. While this is true of > > some systems > > (geosynchronous satellites, for example), it is less true in > > more common > > cases, where you may have access to the "tower" location > > currently serving > > the AIP subscriber. > > if i understood you correctly then this is also just a variation of the > other one and a different party that fetches the location information. in > umts based networks, for example, the network knows the location info of > their subscribers and protocols executed between entities in the networks > (location client and location server) exchange information about the end > host. No, this was a reference to the text that says: o Location Information is asserted by the Access Infrastructure Provider. As such, the end host might use GPS but uses a protocol to allow the network to assert the location information. This approach also has its limitations if the coverage area of the wireless network is fairly large. The approach doesn't have limitations with large coverage areas except in cases like satellites. With mobile systems, the coverage area may be large, but it is broken into cells, which are small. You can get gross location from the tower serving the cell, and then (later in time) you get assisted GPS (also using the tower, for the assist signals), and the result could be that the network, not the endpoint, has location. Satellite systems can't assist, and have huge footprints; your statement would be correct in that instance. > > i don't know whether it makes sense to even say that a particular provider > is allowed to authorize location for a particular area only. > (there are certainly a number of problems particularly if we consider > moving > networks etc.) I agree with this. It may be that a PSAP has a list of AIPs that it knows about and treats locations signed by others with more suspicion than those signed by AIPs it knows. > > > > > The discussion which follows seems to me more applicable to identity > > spoofing than location spoofing. I guess they are related in that if > > someone spoofs location, you'd like to be able to find out > > who it was that > > did it, but it's a pretty tenuous connection. > > > > In the section on impersonating a PSAP, you have a discussion about > > impersonating the database. These are two independent entities. Both > > threats exist, and must be considered separately. > > i guess we should describe what we mean by database. > i guess you think mostly about your "Master Street Address Guide" > database. Not really, in the sense that the MSAG is used for validation. A database derived from the MSAG (in the North American case anyway) would be used to make a routing decision, as above. That's the database I meant. There is a threat on the validation database, but it's no where near as sensitive as that of the routing database. It could be that the validation database and the routing database are one and the same. I in fact propose that they are, but for the purposes of this document, I think we only need discuss the routing database. > > > > The text > > is actually > > about impersonating the database. A security requirement to > > mitigate the > > threat of impersonating the PSAP is to have a way to > > authenticate that the > > UA answering the call is in fact a legitimate, and duly > > authorized PSAP. > yes. > > additionally, one needs to consider the discovery aspect. > if your discovery procedure returns you the wrong psap then the subsequent > authentication only ensures that you talk to the psap (but it is still the > wrong one). Yes, that is true. It would be interesting to mitigate that threat. I can think of ways to do that (the route yields a URI, the endpoint could insist on authentication from the PSAP within the domain the URI is directed to, if, for example, the cert for that domain was in the DNS. I think that is a threat worth distinguishing in the document. I think that threat is no where near as significant as impersonating a PSAP at all. It's pretty likely that if, somehow, you get to the wrong PSAP, but you get to a legitimate PSAP, that they can get your call to the correct one. If an attacker wants to prevent you from getting help, they would really want to impersonate a PSAP illegitimately. > > whether the psap is indeed a legitimate psap is also an authorization > issue. Yes > regarding the long paragraph below: > i read your long discussion with henning about the access infrastructure > provider, etc. > > i have no particular good suggestion for the terminology. maybe we can use > the terminology from other places, for example: > > " > ASP > Access Service Provider. A network operator that provides direct > IP packet forwarding to and from the end host. > " > taken from section 1.3 of > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-02.txt > > this definition might not be perfect either but the mobile ip folks are > happy with it. I'd prefer to stick with Access Infrastructure Provider. Consider, for example, a DSL provider like Verizon wholesaling IP services to an ISP like Earthlink. Verizon owns the DSLAM, the BRAS, etc. It is the only entity that knows where you are. It can tell Earthlink, but Earthlink has no other way to determine location. I would say Verizon is the AIP, Earthlink is the ISP. Who is the ASP? Also, ASP=Application Service Provider, a very unfortunate acronym collision. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 12 20:52:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWOPi-0001ul-Gx; Thu, 12 May 2005 20:52:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWOPh-0001ud-DF; Thu, 12 May 2005 20:52:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29793; Thu, 12 May 2005 20:52:23 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWOfV-0004OE-Vd; Thu, 12 May 2005 21:08:47 -0400 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j4D0qLqt005319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 May 2005 20:52:21 -0400 (EDT) Received: from [127.0.0.1] (razor.cs.columbia.edu [128.59.16.8]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j4D0qKPm008225; Thu, 12 May 2005 20:52:21 -0400 Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: <0C322C5E-C046-4FCE-850F-7607BF0A50EF@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ecrit@ietf.org, geopriv@ietf.org From: Henning Schulzrinne Date: Thu, 12 May 2005 20:52:17 -0400 X-Mailer: Apple Mail (2.728) X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_VERSION 0, __MIME_VERSION_APPLEMAIL 0, __MSGID_APPLEMAIL 0, __SANE_MSGID 0, __USER_AGENT_APPLEMAIL 0, __X_MAILER_APPLEMAIL 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: Subject: [Ecrit] Interim meeting - location information X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The interim meeting will be held on Monday and Tuesday in the Columbia "Interschool Lab", on Wednesday in the "CS conference room". You can find directions at http://www.cs.columbia.edu/directions.html The Interschool Lab is on the 7th floor; there are markers on the wall. You do not need to get a badge or other identification. The CS conference room is on the 4th floor of the computer science building. The receptionist in the department office can direct you. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 12 20:56:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWOTH-0002g0-Ll; Thu, 12 May 2005 20:56:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWOTG-0002f9-JS; Thu, 12 May 2005 20:56:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29988; Thu, 12 May 2005 20:56:04 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWOj6-0004VE-61; Thu, 12 May 2005 21:12:28 -0400 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j4D0u3qt005931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 May 2005 20:56:04 -0400 (EDT) Received: from [127.0.0.1] (razor.cs.columbia.edu [128.59.16.8]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j4D0u1kh008233; Thu, 12 May 2005 20:56:03 -0400 Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <83AF2644-3013-470F-B6AA-AD8B5E25848E@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Thu, 12 May 2005 20:55:57 -0400 To: ecrit@ietf.org, geopriv@ietf.org X-Mailer: Apple Mail (2.728) X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_VERSION 0, __MIME_VERSION_APPLEMAIL 0, __MSGID_APPLEMAIL 0, __SANE_MSGID 0, __USER_AGENT_APPLEMAIL 0, __X_MAILER_APPLEMAIL 0' X-Spam-Score: 1.1 (+) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit Cc: kns10@cs.columbia.edu Subject: [Ecrit] Interim meetings at Columbia University X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Please let Kundan Singh (kns10@cs.columbia.edu) know if you intend to participate via a SIP client or PSTN dial-in (sorry, no 800#), so that we can set up the appropriate infrastructure. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 13 17:16:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWhVn-0000bX-Td; Fri, 13 May 2005 17:15:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWhVl-0000aY-M9; Fri, 13 May 2005 17:15:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10372; Fri, 13 May 2005 17:15:54 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWhlk-0005Tt-Nw; Fri, 13 May 2005 17:32:30 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 13 May 2005 14:14:57 -0700 X-IronPort-AV: i="3.93,108,1115017200"; d="scan'208"; a="636212119:sNHT1332810092" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4DLEtPo000310; Fri, 13 May 2005 14:14:55 -0700 (PDT) Received: from jmpolk-wxp.diablo.cisco.com (sjc-vpn1-68.cisco.com [10.21.96.68]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA24619; Fri, 13 May 2005 14:14:54 -0700 (PDT) Message-Id: <4.3.2.7.2.20050513160551.0203ad08@diablo.cisco.com> X-Sender: jmpolk@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 May 2005 16:14:54 -0500 To: Henning Schulzrinne , ecrit@ietf.org, geopriv@ietf.org From: "James M. Polk" Subject: Re: [Ecrit] Interim meeting - location information In-Reply-To: <0C322C5E-C046-4FCE-850F-7607BF0A50EF@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 08:52 PM 5/12/2005 -0400, Henning Schulzrinne wrote: >The interim meeting will be held on Monday and Tuesday in the >Columbia "Interschool Lab", Which building is this "Lab" in? The gif file http://www.columbia.edu/cu/libraries/indiv/map/campus.big_plan.html on the webpage you sent below lists the campus layout from a Library point of view (which is fine), but it doesn't list a "lab" or a "conference room". Is the "Lab" in the Schipiro Center on W. 120th st? If so, which is about the best entrance for us to look for (i.e. "in the middle of the building on 120th st"?). I assume the conference room is in the Computer Science Building just south of the S.W. Mudd Engineering Building on Amsterdam Ave. Correct? If this is correct, is about the best entrance for us just south of 120th st (on Amsterdam Ave) in the middle of that building? Or is the entrance on 120th st itself? going back to school... I don't want to be late for the professor... ;-) thanks for any guidance >on Wednesday in the "CS conference room". >You can find directions at > >http://www.cs.columbia.edu/directions.html > >The Interschool Lab is on the 7th floor; there are markers on the >wall. You do not need to get a badge or other identification. The CS >conference room is on the 4th floor of the computer science building. >The receptionist in the department office can direct you. > >Henning > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit cheers, James ******************* Truth is not to be argued... it is to be presented. Alas, few *truths* exist without the math. ...all else is a matter of perspective _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 13 17:25:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWhfS-0003KA-AG; Fri, 13 May 2005 17:25:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWhfQ-0003JB-B3; Fri, 13 May 2005 17:25:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12141; Fri, 13 May 2005 17:25:52 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWhvN-0005yg-U8; Fri, 13 May 2005 17:42:28 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j4DLPmh3013424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 May 2005 17:25:49 -0400 (EDT) Message-ID: <42851B58.1020302@cs.columbia.edu> Date: Fri, 13 May 2005 17:25:44 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] Interim meeting - location information References: <4.3.2.7.2.20050513160551.0203ad08@diablo.cisco.com> In-Reply-To: <4.3.2.7.2.20050513160551.0203ad08@diablo.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James M. Polk wrote: > At 08:52 PM 5/12/2005 -0400, Henning Schulzrinne wrote: > >> The interim meeting will be held on Monday and Tuesday in the >> Columbia "Interschool Lab", > > > Which building is this "Lab" in? The gif file > http://www.columbia.edu/cu/libraries/indiv/map/campus.big_plan.html > on the webpage you sent below lists the campus layout from a Library > point of view (which is fine), but it doesn't list a "lab" or a > "conference room". The lab is in the Schapiro Center for Engineering and Physical Science Research (CEPSR), as you guessed correctly. > > Is the "Lab" in the Schipiro Center on W. 120th st? If so, which is > about the best entrance for us to look for (i.e. "in the middle of the > building on 120th st"?). If you're taking the subway, best to walk through campus towards the north end. Otherwise, CEPSR does have an entrance on 120th Street, marked with wrought iron gates that you'd need to be Spiderman to climb. (Yes, Spiderman was "born" at Columbia, at least in the movie...) > > I assume the conference room is in the Computer Science Building just > south of the S.W. Mudd Engineering Building on Amsterdam Ave. Correct? Right. > > If this is correct, is about the best entrance for us just south of > 120th st (on Amsterdam Ave) in the middle of that building? Or is the > entrance on 120th st itself? You can either walk through campus or take the "Mudd Building" entrance on 120th Street. We will try to have signs up for those needing extra civic or geo coordinates. > > going back to school... I don't want to be late for the professor... ;-) > > thanks for any guidance > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 14 03:58:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWrXG-00078X-4t; Sat, 14 May 2005 03:58:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWmry-0003br-0t for ecrit@megatron.ietf.org; Fri, 13 May 2005 22:59:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04907 for ; Fri, 13 May 2005 22:59:11 -0400 (EDT) From: h.arai@d9.dion.ne.jp Received: from mail.dion.ne.jp ([211.5.1.96] helo=dsmtp8.dion.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWn7y-00018G-AR for ecrit@ietf.org; Fri, 13 May 2005 23:15:49 -0400 Received: from webmail.dion.ne.jp ([210.196.2.166]) by dsmtp8.dion.ne.jp (8.11.7p1+Sun/8.11.7/050303) with SMTP id j4E2x7320016; Sat, 14 May 2005 11:59:07 +0900 (JST) To: ecrit@ietf.org Date: Sat, 14 May 2005 11:59:07 +0900 Message-Id: <1116039547.26980@222.226.43.29.DIONWebMail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="EGBSE.AT4G6UESMTE.MWEAMV4GBA" X-Mailer: DION Web mail version 1.03 X-Originating-IP: 222.226.43.29(*) X-Spam-Score: 2.5 (++) X-Scan-Signature: 86ad395f4ce8aadfe8db54e84b5d2ed7 X-Mailman-Approved-At: Sat, 14 May 2005 03:58:07 -0400 Subject: [Ecrit] revised Japanese reqs. I-D X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --EGBSE.AT4G6UESMTE.MWEAMV4GBA Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Hi I submitted the revised Japanese requirements I-D, "Emergency Call Requirements for IP Telephony Services In Japan" draft-arai-ecrit-japan-req-01. Major changes are; - listed the requirements in Section 3, and - added Appendix about the Japanese address code. Thank you, Hideki Arai Avaya Labs, Japan In-Region R&D | arai@avaya.com --EGBSE.AT4G6UESMTE.MWEAMV4GBA Content-Type: application/octet-stream; name="draft-arai-ecrit-japan-req-01.txt" Content-Disposition: attachment; filename="draft-arai-ecrit-japan-req-01.txt" Content-Transfer-Encoding: base64 CgoKCmVjcml0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSC4gQXJhaQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXZheWEKRXhwaXJlczogTm92ZW1iZXIgMTQs IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gS2F3YW5pc2hpCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIE9raQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBNYXkgMTMsIDIwMDUKCgogICAgIEVtZXJnZW5jeSBDYWxsIFJlcXVpcmVt ZW50cyBmb3IgSVAgVGVsZXBob255IFNlcnZpY2VzIEluIEphcGFuCiAgICAgICAgICAgICAgICAg ICBkcmFmdC1hcmFpLWVjcml0LWphcGFuLXJlcS0wMS50eHQKClN0YXR1cyBvZiB0aGlzIE1lbW8K CiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVz ZW50cyB0aGF0IGFueQogICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9m IHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9z ZWQsIGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMKICAgYXdhcmUgd2lsbCBiZSBk aXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQIDc5LgoKICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdy b3Vwcy4gIE5vdGUgdGhhdAogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3Jr aW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0KICAgRHJhZnRzLgoKICAgSW50ZXJuZXQtRHJhZnRz IGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAg IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1 bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5l dC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0 aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJu ZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYv MWlkLWFic3RyYWN0cy50eHQuCgogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cg RGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hh ZG93Lmh0bWwuCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE5vdmVtYmVy IDE0LCAyMDA1LgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJu ZXQgU29jaWV0eSAoMjAwNSkuCgpBYnN0cmFjdAoKICAgVGhpcyBtZW1vIGludHJvZHVjZXMgdGhl IHN0YXR1cyBvZiBzdHVkeSBpbiBKYXBhbiByZWdhcmRpbmcgdGhlCiAgIGNvbW11bmljYXRpb24g Zm9yIGVtZXJnZW5jeSByZXBvcnRzIHVzaW5nIHB1YmxpYyBJUCB0ZWxlcGhvbnkKICAgc2Vydmlj ZXMuICBGaXJzdCwgaXQgcHJvdmlkZXMgdGhlIGluZm9ybWF0aW9uIG9uIHRoZSBiYWNrZ3JvdW5k IGFuZAogICBoaXN0b3J5LCBhbmQgdGhlbiBpdCBzdW1tYXJpemVzIHRoZSBmdW5jdGlvbmFsIHJl cXVpcmVtZW50cyBmcm9tIHRoZQogICByZWxldmFudCBhdXRob3JpdGllcy4KCgoKCgpBcmFpICYg S2F3YW5pc2hpICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDE0LCAyMDA1ICAgICAgICAgICAgICAg W1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBFbWVyZ2VuY3kgcmVxLnMgaW4gSmFw YW4gICAgICAgICAgICAgICAgTWF5IDIwMDUKCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gIElu dHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAzCiAgICAgMS4xICAgSVAgdGVsZXBob255IHNlcnZpY2VzIGluIEphcGFuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAgIDEuMiAgIENvbW1pdHRlZSBmb3IgdGhlIEFkdmFu Y2VtZW50IG9mIEVtZXJnZW5jeSBNZXNzYWdlCiAgICAgICAgICAgU3lzdGVtcyAoQ0FFTVMpICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAgIDEuMyAgIEEg YXNzdW1lZCBuZXR3b3JrIG1vZGVsICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDQKICAgMi4gIEVtZXJnZW5jeSBudW1iZXJzIGluIEphcGFuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA1CiAgIDMuICBJUCBUZWxlcGhvbnkgUmVxdWlyZW1lbnRzIGZvciBF bWVyZ2VuY3kgTWVzc2FnZXMgLiAuIC4gLiAuIC4gLiAgNgogICAgIDMuMSAgIEdldHRpbmcgRW1l cmdlbmN5IENhbGwgdG8gQ29ycmVjdCBFbWVyZ2VuY3kgQ2FsbAogICAgICAgICAgIFJlY2VwdGlv biBPZmZpY2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcKICAg ICAzLjIgICBLZWVwaW5nIENvbm5lY3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA3CiAgICAgMy4zICAgUHJlc2VudGluZyBhbmQgQWNxdWlyaW5nIENhbGxpbmcg TGluZSBJZGVudGlmaWNhdGlvbiwKICAgICAgICAgICBhbmQgUHJlc2VudGluZyBJUCBUZWxlY29t bXVuaWNhdGlvbiBQcm92aWRlcgogICAgICAgICAgIElkZW50aWZpY2F0aW9uIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgKICAgICAzLjQgICBQcmVzZW50aW5n IGFuZCBBY3F1aXJpbmcgR2VvZ3JhcGhpY2FsIExvY2F0aW9uCiAgICAgICAgICAgSW5mb3JtYXRp b24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOAogICA0 LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTIKICAgNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzCiAgIEEuICBKYXBhbmVzZSBBZGRyZXNzIENvZGUg Zm9yIExvY2F0aW9uIEluZm9ybWF0aW9uIC4gLiAuIC4gLiAuIC4gLiAxNAogICAgIEEuMSAgIFBy ZWZlY3R1cmUgY29kZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTUKICAgICBBLjIgICBNdW5pY2lwYWxpdHkgY29kZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDE3CiAgICAgICBBLjIuMSAgIFByZWZlY3R1cmUgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNwogICAgICAgQS4yLjIgICBHb3Zlcm5t ZW50LWRlc2lnbmF0ZWQgbWFqb3IgY2l0aWVzIGFuZCB3YXJkcyAuIC4gLiAuIC4gMTgKICAgICAg IEEuMi4zICAgU3BlY2lhbC13YXJkcyBpbiBUb2t5byAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDE4CiAgICAgICBBLjIuNCAgIENpdGllcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOQogICAgICAgQS4yLjUgICBUb3ducyBhbmQgVmlsbGFn ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTkKICAgICBBLjMgICBTZWN0 aW9uIGNvZGUgYW5kIFN1YnNlY3Rpb24gY29kZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIw CiAgICAgQS40ICAgQWRkaW5nIGFuZCBEaXNjb250aW51aW5nIENvZGUgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAyMgogICAgICAgQS40LjEgICBDYXNlcyBvZiBhZGRpbmcgYW5kIGRpc2Nv bnRudWluZyBjb2RlICAuIC4gLiAuIC4gLiAuIC4gMjIKICAgICAgIEEuNC4yICAgQWRkaW5nIENv ZGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyCiAgICAgICBB LjQuMyAgIERpc2NvbnRpbnVpbmcgQ29kZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAyMgogICA2LiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMjIKICAgICAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIzCiAgICAgICBJbnRlbGxlY3R1 YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAyNAoK CgoKCgoKCgoKCgoKCgoKQXJhaSAmIEthd2FuaXNoaSAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAx NCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg RW1lcmdlbmN5IHJlcS5zIGluIEphcGFuICAgICAgICAgICAgICAgIE1heSAyMDA1CgoKMS4gIElu dHJvZHVjdGlvbgoKICAgUHVibGljIElQIHRlbGVwaG9ueSBzZXJ2aWNlcyBpbiBKYXBhbiBiZWNh bWUgcG9wdWxhciBieSB0aGUKICAgYWxsb2NhdGlvbiBvZiB0aGUgZXhjbHVzaXZlIElQIHBob25l IG51bWJlciBiZWd1biBpbiBTZXB0ZW1iZXIgMjAwMi4KICAgVGhlIElQIHRlbGVwaG9uZSBudW1i ZXIgaXMgYW4gZWxldmVuLWRpZ2l0IHRlbGVwaG9uZSBudW1iZXIgaW5jbHVkZXMKICAgIjA1MCIg cHJlZml4IGZvbGxvd2VkIGJ5IHRoZSBjYXJyaWVyIElELiAgQ3VycmVudGx5IG1vcmUgdGhhbiBz ZXZlbgogICBtaWxsaW9uIHVzZXJzIHN1YnNjcmliZSB0aGUgSVAgdGVsZXBob255IHNlcnZpY2Us IGFuZCBmdXJ0aGVyCiAgIHN1YnNjcmlwdGlvbiBpcyBleHBlY3RlZCBpbiB0aGUgbmV4dCBmZXcg eWVhcnMuCgoxLjEgIElQIHRlbGVwaG9ueSBzZXJ2aWNlcyBpbiBKYXBhbgoKICAgVGhlcmUgYXJl IHR3byB0eXBlcyBvZiBwdWJsaWMgSVAgdGVsZXBob255IHNlcnZpY2VzIGluIEphcGFuLiAgT25l IGlzCiAgIHRoZSAnMDUwJyBzZXJ2aWNlIG1lbnRpb25lZCBhYm92ZSwgYW5kIGFub3RoZXIgaXMg dGhlIElQIHRlbGVwaG9ueQogICBzZXJ2aWNlIHVzaW5nIHN0YW5kYXJkIHRlbGVwaG9uZSBudW1i ZXIgb2YgJzBBQi1KJy4gIFRoZSBtaW5pc3RlcmlhbAogICBvcmRpbmFuY2UgcmVxdWlyZXMgc2Vy dmljZSBwcm92aWRlcnMgdG8gYWNoaWV2ZSBhIGNlcnRhaW4gbGV2ZWwgb2YKICAgcmVxdWlyZWQg Y29uZGl0aW9uLgoKICAgVGhlIHJlcXVpcmVtZW50cyB0byB0aGUgJzBBQi1KJyBJUCB0ZWxlcGhv bnkgc2VydmljZSBhcmUgc3VtbWFyaXplZAogICBiZWxvdy4KCiAgIG8gIFByb3ZpZGVzIHZvaWNl IHF1YWxpdHkgZXF1YWwgdG8gUFNUTiB0ZWxlcGhvbmUKCiAgIG8gIEVuYWJsZXMgdGhlIHVzZSBv ZiB0aGUgZW1lcmdlbmN5IGNhbGxzCgogICBvICBJbnN0YWxsZWQgbG9jYXRpb24gb2YgdGhlIElQ IHRlbGVwaG9uZSBkZXZpY2UgaXMgZml4ZWQgYW5kIHRoZQogICAgICBkZXZpY2VzIGFyZSBub3Qg cG9ydGFibGUKCiAgIE9uIHRoZSBvdGhlciBoYW5kLCB0aGUgSVAgdGVsZXBob255IHNlcnZpY2Vz IHdpdGggMDUwIHByZWZpeCBhcmUgbm90CiAgIG5lY2Vzc2FyaWx5IGJvdW5kIGJ5IHRoZXNlIGNv bmRpdGlvbnMuCgogICBUaGVyZSBpcyBhIGdlbmVyYWwgb3BpbmlvbiB0aGF0IGl0IGlzIHByZWZl cmFibGUgZm9yIHRoZSBlbWVyZ2VuY3kKICAgY2FsbHMgdG8gYmUgZW5hYmxlZCBib3RoIG9uIDA1 MCBJUCB0ZWxlcGhvbnkgc2VydmljZXMgb3Igb24gMEFCLUogSVAKICAgdGVsZXBob255IHNlcnZp Y2VzIGFzIGxvbmcgYXMgdGhlIHVzZXJzIGNvbnNpZGVyIHRoZXNlIHNlcnZpY2VzIGFyZQogICBh bHRlcm5hdGl2ZXMgdG8gUFNUTiB0ZWxlcGhvbmUuCgoxLjIgIENvbW1pdHRlZSBmb3IgdGhlIEFk dmFuY2VtZW50IG9mIEVtZXJnZW5jeSBNZXNzYWdlIFN5c3RlbXMgKENBRU1TKQoKICAgSW4gTm92 ZW1iZXIgMjAwMywgdGhlIE1pbmlzdGVyIG9mIEludGVybmFsIEFmZmFpcnMgYW5kIENvbW11bmlj YXRpb25zCiAgIHJlcXVlc3RlZCB0aGUgTWluaXN0cnkgb2YgSW50ZXJuYWwgQWZmYWlycyBhbmQg Q29tbXVuaWNhdGlvbnMgKE1JQykKICAgZm9yIHRoZSBhZHZpY2UgYWJvdXQgdGhlIGFjaGlldmVt ZW50IG9mIHRoZSBlbWVyZ2VuY3kgY2FsbCB3aXRoIHRoZQogICBJUCB0ZWxlcGhvbnkgc2Vydmlj ZXMgcHJvbXB0IGFuZCBlbXBoYXRpY2FsbHkuCgogICBVcG9uIHRoaXMgcmVxdWVzdCwgTUlDIHNl dCB1cCB0aGUgSVAgVGVsZXBob255IFdvcmtpbmcgR3JvdXAgdW5kZXIKICAgdGhlIENvbW1pdHRl ZSBmb3IgdGhlIEFkdmFuY2VtZW50IG9mIEVtZXJnZW5jeSBNZXNzYWdlIFN5c3RlbXMKICAgKENB RU1TKSBmcm9tIE1hcmNoIDIwMDQgdG8gSmFudWFyeSAyMDA1IHRvIGRpc2N1c3MgdGhlIHJlcXVp cmVtZW50cwogICB0byB0aGUgZW1lcmdlbmN5IGNhbGwgc2VjdXJpbmcgaW4gdGhlIElQIG5ldHdv cmsuICBUaGUgc3R1ZHkgZ3JvdXAKICAgd2FzIGNvbXBvc2VkIG9mIHRoZSBlbWVyZ2VuY3kgY2Fs bCBhY2NlcHRhbmNlIG9yZ2FuaXphdGlvbiAoRUNBTyBpbgogICB0aGlzIGRvY3VtZW50KSwgdGhl IHBlb3BsZSBmcm9tIGFjYWRlbWljIGJhY2tncm91bmQsIHRoZQoKCgpBcmFpICYgS2F3YW5pc2hp ICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDE0LCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgM10K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBFbWVyZ2VuY3kgcmVxLnMgaW4gSmFwYW4gICAgICAg ICAgICAgICAgTWF5IDIwMDUKCgogICB0ZWxlY29tbXVuaWNhdGlvbnMgY2FycmllciwgdGhlIElQ IHRlbGVwaG9ueSBlcXVpcG1lbnQgbWFudWZhY3R1cmVyLAogICBhbmQgc28gZm9ydGguCgogICBB cyB0aGUgcmVzdWx0IG9mIHN0dWR5LCBhIGRyYWZ0IHByb3Bvc2FsIHRoYXQgY29uc2lzdHMgb2Yg dGhlCiAgIGF1dGhvcml0eSdzIHNlcnZpY2UgcmVxdWlyZW1lbnRzIGFuZCB0aGUgZnVuY3Rpb25h bCByZXF1aXJlbWVudHMgd2FzCiAgIGNvbXBpbGVkIGFuZCB0aGUgZHJhZnQgaXMgY3VycmVudGx5 IHVuZGVyIHB1YmxpYyByZXZpZXcgW01JQyBkcmFmdAogICByZXBvcnRdLiAgVGhlIGRvY3VtZW50 IGluIEphcGFuZXNlIGlzIGF2YWlsYWJsZSBmcm9tIE1JQyBob21lIHBhZ2UuCiAgIEF0IHRoZSBl bmQgb2YgTWFyY2ggMjAwNSwgdGhlIGZpbmFsIHJlcG9ydCB0aGF0IGluY29ycG9yYXRlcyB0aGUK ICAgcHVibGljIGNvbW1lbnRzIHdpbGwgYmUgc3VibWl0dGVkIHRvIHRoZSBtaW5pc3RlciBvZiBN SUMuCgogICBUaGUgcHVycG9zZSBvZiB0aGlzIHJlcG9ydCBpcyBmb3IgcGFydGllcyBjb25jZXJu ZWQgb2YgdGhlCiAgIHRlbGVjb21tdW5pY2F0aW9ucyBjYXJyaWVyLCB0aGUgZW1lcmdlbmN5IGNh bGwgYWNjZXB0YW5jZQogICBvcmdhbml6YXRpb24sIHRoZSBJUCB0ZWxlcGhvbmUgdGVybWluYWwg bWFrZXIsIGFuZCBzbyBmb3J0aCwgdG8gZml4IGEKICAgZGV0YWlsZWQgc3BlY2lmaWNhdGlvbiwg dG8gYWR2YW5jZSB0aGUgaW50cm9kdWN0aW9uLCBhbmQgdG8gdXNlIGl0CiAgIHdpZGVseS4KCiAg IFRoaXMgbWVtbyBwcm92aWRlcyBpbmZvcm1hdGlvbiBvbiB0aGUgcmVxdWlyZW1lbnRzIGZvciB0 aGUgZW1lcmdlbmN5CiAgIGNhbGwgYWNjZXB0YW5jZSBvbiB0aGUgSVAgbmV0d29yaywgYmFzZWQg b24gdGhlIGFib3ZlLW1lbnRpb25lZCBkcmFmdAogICBwcm9wb3NhbCB1bmRlciB0aGUgcHVibGlj IHJldmlldy4KCjEuMyAgQSBhc3N1bWVkIG5ldHdvcmsgbW9kZWwKCiAgIFRoZSBmb2xsb3dpbmcg cHJlY29uZGl0aW9ucyB3ZXJlIGFzc3VtZWQgZm9yIHRoZSBDQUVNUyBkaXNjdXNzaW9uLgoKICAg SVAgVGVsZXBob255IE5ldHdvcms6CgogICAgICBUaGVyZSB3aWxsIGJlIHR3byB0eXBlcyBvZiBu ZXR3b3JrIGNvbmZpZ3VyYXRpb24KCiAgICAgIEVDQU8gaXMgY29ubmVjdGVkIHRvIElQIG5ldHdv cmsgdmlhIFBTVE4gdXNpbmcgZXhpc3RpbmcgZW1lcmdlbmN5CiAgICAgIGxpbmUKCiAgICAgIEVD QU8gaXMgY29ubmVjdGVkIGRpcmVjdGx5IHRvIElQIHRlbGVwaG9ueSBuZXR3b3JrIHZpYSBhIG5l dyBJUAogICAgICBsaW5lCgogICBUeXBlcyBvZiBJUCB0ZWxlcGhvbnkgc2VydmljZXM6CgogICAg ICBGaXhlZCBJUCB0ZWxlcGhvbmUKCiAgICAgIFBvcnRhYmxlIElQIHRlbGVwaG9uZQoKICAgICAg SVAgdGVsZXBob25lIHdpdGggbW9iaWxlIGNhcGFiaWxpdHkKCgoKCgoKCgoKCkFyYWkgJiBLYXdh bmlzaGkgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMTQsIDIwMDUgICAgICAgICAgICAgICBbUGFn ZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIEVtZXJnZW5jeSByZXEucyBpbiBKYXBhbiAg ICAgICAgICAgICAgICBNYXkgMjAwNQoKCjIuICBFbWVyZ2VuY3kgbnVtYmVycyBpbiBKYXBhbgoK ICAgVGhlcmUgYXJlIHRocmVlIGVtZXJnZW5jeSB0ZWxlcGhvbmUgbnVtYmVycyBpbiBKYXBhbi4g IEl0IGlzIDExMAogICAocG9saWNlKSwgMTE4IChKYXBhbiBDb2FzdCBHdWFyZCksIGFuZCAxMTko ZmlyZSBzdGF0aW9uIGFuZAogICBhbWJ1bGFuY2UpLgoKICAgV2hlbiBkaWFsaW5nIG9uZSBvZiB0 aGVzZSBudW1iZXJzLCB0aGUgZW1lcmdlbmN5IGNhbGwgaXMgZXN0YWJsaXNoZWQKICAgdG93YXJk IHRoZSBlbWVyZ2VuY3kgcmVjZXB0aW9uIGRlc2sgb2YgZWFjaCBvcmdhbml6YXRpb24gdGhhdCBj b3ZlcnMKICAgdGhlIGFyZWEgd2hlcmUgdGhlIHJlcG9ydGVyIGlzIHByZXNlbnQuICBJbiBQU1RO LCB0ZWxlcGhvbnkgY2FycmllcnMKICAgaGF2ZSBhIGRhdGFiYXNlIHdpdGggc3Vic2NyaWJlcidz IG5hbWUsIGFkZHJlc3MsIGFuZCB0ZWxlcGhvbmUKICAgbnVtYmVyLCBhbmQgZWFjaCBlbWVyZ2Vu Y3kgdGVsZXBob25lIG51bWJlciBpcyBjb252ZXJ0ZWQgdG8gdGhlCiAgIHRlbGVwaG9uZSBudW1i ZXIgb2YgZW1lcmdlbmN5IHJlY2VwdGlvbiBkZXNrIG9mIGVhY2ggRUNBTy4KCiAgIEVhY2ggRUNB TyBwbGFjZXMgYW4gZW1lcmdlbmN5IGNhbGwgcmVjZXB0aW9uIGRlc2sgYmFzZWQgb24gdGhlCiAg IGRpc3RyaWN0IG9mIHRoZWlyIGRlZmluaXRpb24uCgogICBQb2xpY2UgKDExMCk6IDUyIGhlYWQg b2ZmaWNlcwoKICAgICAgMSBpbiBlYWNoIDQ3IHByZWZlY3R1cmVzLCBleGNlcHQgMiBpbiBUb2t5 byBhbmQgNSBpbiBIb2trYWlkbwoKICAgSmFwYW4gQ29hc3QgR3VhcmQgKDExOCk6IDExIGp1cmlz ZGljdGlvbnMKCiAgIEZpcmUgc3RhdGlvbiBhbmQgYW1idWxhbmNlICgxMTkpOiBTbGlnaHRseSBs ZXNzIHRoYW4gOTAwIGRpc3RyaWN0cwoKICAgICAgRGVmaW5lZCBsb2NhbGx5IGFsb25nIHdpdGgg dGhlIGRpc3RyaWN0IG9mIGFib3V0IDMwMDAKICAgICAgbXVuaWNpcGFsaXRpZXMKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCkFyYWkgJiBLYXdhbmlzaGkgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIg MTQsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg IEVtZXJnZW5jeSByZXEucyBpbiBKYXBhbiAgICAgICAgICAgICAgICBNYXkgMjAwNQoKCjMuICBJ UCBUZWxlcGhvbnkgUmVxdWlyZW1lbnRzIGZvciBFbWVyZ2VuY3kgTWVzc2FnZXMKCiAgIFRoaXMg c2VjdGlvbiBwcm92aWRlcyBhIGxpc3Qgb2YgaGlnaGx5IGltcG9ydGFudCByZXF1aXJlbWVudHMg aW4KICAgc3VwcG9ydCBvZiB0aGUgZW1lcmdlbmN5IG1lc3NhZ2VzIHdpdGhpbiB0aGUgY29udGV4 dCBvZiBJUCB0ZWxlcGhvbnkKICAgaW4gSmFwYW4uCgogICBNVVNUMTogICBFbWVyZ2VuY3kgY2Fs bCBNVVNUIGJlIGdvdCB0byB0aGUgY29ycmVjdCBFbWVyZ2VuY3kgQ2FsbAogICAgICAgICAgICBS ZWNlcHRpb24gT2ZmaWNlIChFQ1JPKSwgd2hpY2ggY292ZXJzIHdoZXJlIHRoZSByZXBvcnRlciBp cwogICAgICAgICAgICBwcmVzZW50LgoKICAgTVVTVDI6ICAgRW1lcmdlbmN5IGNhbGwgTVVTVCBi ZSByZWRpcmVjdGVkIHRvIGFuIGFsdGVybmF0aXZlIGZhY2lsaXR5CiAgICAgICAgICAgIHRoYXQg dGhlIG9yZ2FuaXphdGlvbiBkZXNpZ25hdGVzIGFzIGFuIGFsdGVybmF0aXZlIHJlY2VwdGlvbgog ICAgICAgICAgICBvZmZpY2UsIGluIGNhc2UgdGhlIG9yaWdpbmFsIEVDUk8gY291bGQgbm90IGRv IGl0cyBkdXR5IGR1ZQogICAgICAgICAgICB0byBhIGRpc2FzdGVyIGV0Yy4KCiAgIE1VU1QzOiAg IEluZm9ybWF0aW9uIGZvciBpZGVudGlmeWluZyB0aGUgb3BlcmF0b3Igd2hvIGNhbiBwcm92aWRl IHRoZQogICAgICAgICAgICByZXBvcnRlcidzIHN1YnNjcmlwdGlvbiBpbmZvcm1hdGlvbiBNVVNU IGJlIHByZXNlbnRlZCB0bwogICAgICAgICAgICBFQ1JPLgoKICAgTVVTVDQ6ICAgRW1lcmdlbmN5 IGNhbGwgTVVTVCBOT1QgYmUgdGVybWluYXRlZCB1bmxlc3MgRUNSTyB0ZXJtaW5hdGVkCiAgICAg ICAgICAgIGl0LCBldmVuIHRob3VnaCB0aGUgcmVwb3J0ZXIgaHVuZyB1cC4gIChLZWVwaW5nIGNv bm5lY3Rpb24pCgogICBNVVNUNTogICBSZXBvcnRlcidzIHRlcm1pbmFsIE1VU1QgYmUgcnVuZyB1 cCBmcm9tIEVDUk8gaWYgRUNSTyBpbnRlZHMKICAgICAgICAgICAgdG8gcmVzdW1lIHRoZSBjb252 ZXJzYXRpb24gd2l0aCB0aGUgcmVwb3J0ZXIgZHVyaW5nICJrZWVwaW5nCiAgICAgICAgICAgIGNv bm5lY3Rpb24iIHdvdWxkIGJlIGFjdGl2YXRlZC4gIChSZXZlcnNpbmcgY2FsbCkKCiAgIE1VU1Q2 OiAgIFJlcG9ydGVyJ3MgY2FsbGVyLUlEIE1VU1QgYmUgcHJlc2VudGVkIHRvIEVDUk8gdW5sZXNz IHRoZQogICAgICAgICAgICByZXBvcnRlciBkaWFscyB0aGUgcmVzdHJpY3Rpb24gY29kZSBmb2xs b3dlZCB3aXRoICIxMXgiCiAgICAgICAgICAgICgxMTAsIDExOCBvciAxMTkpLgoKICAgTVVTVDc6 ICAgRUNSTyBNVVNUIGJlIGFsbG93ZWQgdG8gYWNxdWlyZSB0aGUgY2FsbGVyLUlEIGV2ZW4gdGhv dWdoCiAgICAgICAgICAgIHRoZSByZXBvcnRlciBkaWFsZWQgd2l0aCB0aGUgcmVzdHJpY3Rpb24g Y29kZS4KCiAgIE1VU1Q4OiAgIEdlb2dyYXBoaWNhbCBMb2NhdGlvbiBJbmZvcm1hdGlvbiAoR0xJ KSB0aGF0IHRoZSByZXBvcnRlciBpcwogICAgICAgICAgICBwcmVzZW50IE1VU1QgYmUgcHJlc2Vu dGVkIHRvIEVDUk8uCgogICBNVVNUOTogICBHTEkgTVVTVCBjb25zaXN0IG9mCgogICAgICAgICAg ICAqICBGaXhlZCBJUC1waG9uZTogc3Vic2NyaWJlcidzIG5hbWUsIGFkZHJlc3MsIGFkZHJlc3Mg Y29kZQogICAgICAgICAgICAgICBhbmQgdGVsZXBob25lIG51bWJlcgoKICAgICAgICAgICAgKiAg UG9ydGFibGUvTW9iaWxlIElQLXBob25lOiBzdWJzY3JpYmVyJ3MgbmFtZSwgcGxhY2Ugb2YKICAg ICAgICAgICAgICAgZGlzcGF0Y2ggaW5mb3JtYXRpb24sIHRlbGVwaG9uZSBudW1iZXIsIGFuZCBt b2JpbGUtdXNlIG9yCiAgICAgICAgICAgICAgIG5vdAoKCgoKCgoKQXJhaSAmIEthd2FuaXNoaSAg ICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxNCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDZdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgRW1lcmdlbmN5IHJlcS5zIGluIEphcGFuICAgICAgICAg ICAgICAgIE1heSAyMDA1CgoKICAgTVVTVDEwOiAgRW1lcmdlbmN5IGNhbGwgTVVTVCBoYXZlIHBy aW9yaXR5IG92ZXIgYWxsIG90aGVyIGNhbGxzIGluCiAgICAgICAgICAgIGFueSBjYXNlLgoKICAg TVVTVDExOiAgT3BlcmF0b3IgTVVTVCBwcmV2ZW50IGEgbWFsaWNpb3VzIGNhbGwgcHJldGVuZGlu ZyB0aGUgcGxhY2UKICAgICAgICAgICAgb2YgZGlzcGF0Y2guCgoKMy4xICBHZXR0aW5nIEVtZXJn ZW5jeSBDYWxsIHRvIENvcnJlY3QgRW1lcmdlbmN5IENhbGwgUmVjZXB0aW9uIE9mZmljZQoKICAg QXMgbWVudGlvbmVkIGluIHNlY3Rpb24gMiwgdGhlIGVtZXJnZW5jeSBjYWxsIHRoYXQgd2lsbCBi ZSBkaWFsZWQKICAgMTEwLCAxMTggYW5kIDExOSBtdXN0IGJlIGdvdCB0byB0aGUgY29ycmVjdCBl bWVyZ2VuY3kgY2FsbCByZWNlcHRpb24KICAgb2ZmaWNlIChFQ1JPKSwgd2hpY2ggdGFrZXMgY2hh cmdlIG9mIHBsYWNlIHdoZXJlIHRoZSBjYWxsIHdvdWxkIGJlCiAgIHNlbnQsIGJ5IGxvY2F0aW9u LWJhc2VkIGNhbGwgcm91dGluZy4gIFRoaXMgcmVxdWlyZW1lbnQgbXVzdCBiZSBtZXQKICAgSVAg dGVsZXBob255IGVtZXJnZW5jeSBjYWxsIHNlcnZpY2UsIGluIGNhc2Ugb2Ygbm90IG9ubHkgZml4 ZWQtdXNlIElQCiAgIHRlbGVwaG9uZXMsIGJ1dCBhbHNvIHBvcnRhYmxlIElQIHRlbGVwaG9uZXMg Zm9yIGZpeGVkLXVzZSBhbmQgbW9iaWxlCiAgIElQIHRlbGVwaG9uZXMuCgogICBJbiB0aGlzIGNh c2UsIGNhbGwgY29udHJvbCBub2RlcyBzaG91bGQgaWRlbnRpZnkgZW1lcmdlbmN5IGNhbGxzIGlu CiAgIG9yZGVyIHRvIGVzdGFibGlzaCBhIGNhbGwgZXZlbiB1bmRlciBuZXR3b3JrIGNvbmdlc3Rp b24uICBTb21lCiAgIG5ldHdvcmtzIHVzZSBhbHRlcm5hdGl2ZSB0ZWxlcGhvbmUgbnVtYmVyIG90 aGVyIHRoYW4gZW1lcmdlbmN5IG51bWJlcgogICBvZiAxMTAvMTE4LzExOSBmb3Igcm91dGluZyBw dXJwb3NlLCBhbmQgdGhlcmVmb3JlIHRoZSBlbWVyZ2VuY3kgY2FsbHMKICAgc2hvdWxkIGJlIGlk ZW50aWZpZWQgYnkgYW4gaWRlbnRpZmllciBvdGhlciB0aGFuIGRpYWxlZCBudW1iZXIuCgozLjIg IEtlZXBpbmcgQ29ubmVjdGlvbgoKICAgVGhpcyByZXF1aXJlbWVudCBpcyBmb3IgYWxsb3dpbmcg dGhlIEVDUk8gdG8gc2VjdXJlIHRoZSB0aW1lIG9yIHRoZQogICBjaGFuY2Ugb2YgdGhlIGNvbnZl cnNhdGlvbiB3aXRoIHRoZSByZXBvcnRlciBpZiBuZWNlc3NhcnkuCgogICBJUCB0ZWxlY29tbXVu aWNhdGlvbiBwcm92aWRlcnMgYXJlIHJlcXVpcmVkIHRvIHByb3ZpZGUgdGhlICJrZWVwaW5nCiAg IGNvbm5lY3Rpb24iIGZ1bmN0aW9uYWxpdHkgdGhhdCBrZWVwcyB0aGUgY2FsbCB1bmxlc3MgdGhl IEVDUk8gd291bGQKICAgdGVybWluYXRlIHRoZSBjYWxsLCBldmVuIHRob3VnaCB0aGUgcmVwb3J0 ZXIgd291bGQgaGFuZyB1cC4gIEFuZCB0aGUKICAgcHJvdmlkZXJzIGFyZSBhbHNvIHJlcXVpcmVk IHRvIHByb3ZpZGUgdGhlICJyZXZlcnNpbmcgY2FsbCIKICAgZnVuY3Rpb25hbGl0eSB0aGF0IHJp bmdzIHRoZSByZXBvcnRlcidzIHRlcm1pbmFsIHVwIGJ5IG9wZXJhdGluZyB0aGUKICAgaW5zdHJ1 Y3Rpb24gYm9hcmQgaW4gdGhlIEVDUk8sIGlmIHRoZSBFQ1JPIGludGVuZHMgdG8gcmVzdW1lIHRo ZQogICBjb252ZXJzYXRpb24gd2l0aCB0aGUgcmVwb3J0ZXIgd2hpbGUgdGhlIGVtZXJnZW5jeSBj YWxsIGlzIGtlcHQgYnkKICAgdGhlICJrZWVwaW5nIGNvbm5lY3Rpb24iIGZ1bmN0aW9uYWxpdHku CgogICBGb3IgaW5zdGFuY2UsIGl0IHNob3VsZCBiZSBhY2hpZXZlZCBieSBpbXBsZW1lbnRpbmcg ZWl0aGVyIG9mIHRoIGUKICAgZm9sbG93aW5nIGZ1bmN0aW9uYWxpdGllczoKCiAgICAgIFRoZSBj b25uZWN0aW9uIGJldHdlZW4gdGhlIHJlcG9ydGVyIGFuZCB0aGUgRUNSTywgd2hpY2ggcmVjZWl2 ZWQKICAgICAgdGhlIGVtZXJnZW5jeSBjYWxsIGZyb20gdGhlIHJlcG9ydGVyLCBpcyBlc3RhYmxp c2hlZCByZWdhcmRsZXNzIG9mCiAgICAgIHRoZSByZXBvcnRlcidzIGludGVudGlvbiBldmVuIGlm IHRoZSByZXBvcnRlciBsaWZ0cyB0aGUgcmVjZWl2ZXIKICAgICAgdHJ5aW5nIHRvIGNhbGwgc29t ZXdoZXJlIGFmdGVyIHRoZSByZXBvcnRlciBodW5nIHVwIHRoZSBlbWVyZ2VuY3kKICAgICAgY2Fs bC4KCiAgICAgIFRoZSByZXBvcnRlcidzIHByZXNlbnQgY2FsbCBpcyB0ZXJtaW5hdGVkIG9yIHN1 c3BlbmRlZCBhbmQgdGhlbgogICAgICBhbm90aGVyIG5ldyBjYWxsIGJldHdlZW4gdGhlIHJlcG9y dGVyIGFuZCB0aGUgRUNSTyBpcyBlc3RhYmxpc2hlZAoKCgpBcmFpICYgS2F3YW5pc2hpICAgICAg ICBFeHBpcmVzIE5vdmVtYmVyIDE0LCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgN10KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICBFbWVyZ2VuY3kgcmVxLnMgaW4gSmFwYW4gICAgICAgICAgICAg ICAgTWF5IDIwMDUKCgogICAgICBldmVuIGlmIHRoZSBFQ1JPIGNhbGxzIHRoZSByZXBvcnRlciB1 cCB3aGlsZSB0aGUgcmVwb3J0ZXIgaXMKICAgICAgdGFsa2luZyBvdmVyIGEgbmV3IGNhbGwgYWZ0 ZXIgdGhlIHJlcG9ydGVyIGh1bmcgdXAgdGhlIGVtZXJnZW5jeQogICAgICBjYWxsLgoKCjMuMyAg UHJlc2VudGluZyBhbmQgQWNxdWlyaW5nIENhbGxpbmcgTGluZSBJZGVudGlmaWNhdGlvbiwgYW5k CiAgICAgUHJlc2VudGluZyBJUCBUZWxlY29tbXVuaWNhdGlvbiBQcm92aWRlciBJZGVudGlmaWNh dGlvbgoKICAgVGhlc2UgZnVuY3Rpb25hbGl0aWVzLCBDYWxsaW5nIExpbmUgSWRlbnRpZmljYXRp b24gUHJlc2VudGF0aW9uIGFuZAogICBBY3F1aXNpdGlvbiwgYW5kIElQIFRlbGVjb21tdW5pY2F0 aW9uIFByb3ZpZGVyIElkZW50aWZpY2F0aW9uCiAgIFByZXNlbnRhdGlvbiwgYXJlIHVzZWQgZm9y IGNhbGxpbmcgdGhlIHJlcG9ydGVyIGJhY2sgZnJvbSB0aGUgRUNSTwogICB0aGF0IHJlY2VpdmVk IHRoZSBlbWVyZ2VuY3kgY2FsbCwgaWYgdGhlIEVDUk8gaW50ZW5kcyB0byByZXN1bWUgdGhlCiAg IGNvbnZlcnNhdGlvbiB3aXRoIHRoZSByZXBvcnRlciBhZnRlciB0aGUgY2FsbCBlbmRzLgoKICAg SW4gZ2VuZXJhbCwgSVAgdGVsZWNvbW11bmljYXRpb24gcHJvdmlkZXJzIGluIEphcGFuIHByb3Zp ZGUgQ2FsbGluZwogICBMaW5lIElkZW50aWZpY2F0aW9uIFByZXNlbnRhdGlvbiBhbmQgUmVzdHJp Y3Rpb24gKENMSVAgYW5kIENMSVIpCiAgIHNlcnZpY2U7IHRoZSBzZWxlY3Rpb24gb2Ygd2hldGhl ciB0aGUgaWRlbnRpZmljYXRpb24gaXMgcHJlc2VudGVkIGlzCiAgIGVpdGhlciBieSB0aGUgc3Vi c2NyaXB0aW9uIGNvbnRyYWN0IG9yIGJ5IHNwZWNpZnlpbmcgdGhlIHNlcnZpY2UKICAgbnVtYmVy ICh3aGljaCBpcyAxODQgb3IgMTg2KSBiZWZvcmUgdGhlIHRlbGVwaG9uZSBudW1iZXIgeW91IHdv dWxkCiAgIGRpYWwuICBUaGUgbGF0dGVyIGhhcyBwcmVjZWRlbmNlIG92ZXIgdGhlIGZvcm1lci4g IFRoYXQgaXMsIGlmIHlvdQogICBzcGVjaWZ5IHRoZSBzZXJ2aWNlIG51bWJlciBmb3IgQ0xJUiBi ZWZvcmUgdGhlIHRlbGVwaG9uZSBudW1iZXIgeW91CiAgIGRpYWwsIHRoZSByZXBvcnRlcidzIHRl bGVwaG9uZSBudW1iZXIgd29uJ3QgYmUgZGlzcGxheWVkIG9uIHRoZQogICBjYWxsZWQgc2l0ZSBl dmVuIHRob3VnaCB0aGUgcmVwb3J0ZXIgc3Vic2NyaWJlcyBhcyBDTElQLiAgT24gdGhlCiAgIG90 aGVyIGhhbmQsIGlmIHlvdSBzcGVjaWZ5IENMSVAsIHRoZSByZXBvcnRlcidzIHRlbGVwaG9uZSBu dW1iZXIgd2lsbAogICBiZSBkaXNwbGF5ZWQgZXZlbiB0aG91Z2ggdGhlIHJlcG9ydGVyIHN1YnNj cmliZXMgYXMgQ0xJUi4KCiAgIEZvciB0aGUgZW1lcmdlbmN5IGNhbGwsIHRoZSByZXBvcnRlcidz IHRlbGVwaG9uZSBudW1iZXIgbXVzdCBiZQogICBwcmVzZW50ZWQgdG8gdGhlIEVDUk8gcmVnYXJk bGVzcyBvZiB0aGUgc3Vic2NyaXB0aW9uIG9mIHRoZSByZXBvcnRlciwKICAgdW5sZXNzIHRoZSBy ZXBvcnRlciBzcGVjaWZpZXMgQ0xJUiBleHBsaWNpdGx5LgoKICAgRnVydGhlcm1vcmUsIGV2ZW4g aWYgdGhlIHJlcG9ydGVyIHNwZWNpZmllcyBDTElSLCB0aGUgRUNSTyBtdXN0IGJlCiAgIGFibGUg dG8gYWNxdWlyZSB0aGUgcmVwb3J0ZXIncyB0ZWxlcGhvbmUgbnVtYmVyIG92ZXIgdGhlIGNhbGwg b3IgdGhlCiAgICJrZWVwaW5nIGNvbm5lY3Rpb24iIGNvbmRpdGlvbi4gIEJlY2F1c2UsIGZvciBl eGFtcGxlLCBpbiBjYXNlIHRoZQogICByZXBvcnRlciBmYWNlcyBhIGNyaXNpcyB0aGF0IGlzIGEg bWF0dGVyIG9mIGxpZmUgYW5kIGRlYXRoLCBldmVuIGlmCiAgIHRoZSByZXBvcnRlciBkb2Vzbid0 IHdhbnQgdG8gcHJlc2VudCBoaXMvaGVyIHRlbGVwaG9uZSBudW1iZXIgdG8gdGhlCiAgIEVDUk8s IHRoZSBFQ1JPIGhhcyB0byBrbm93IHRoZSByZXBvcnRlcidzIHRlbGVwaG9uZSBudW1iZXIgaW4g b3JkZXIKICAgdG8gc2V0dGxlIHRoZSBjaXJjdW1zdGFuY2UuICBUaGlzIG9wZXJhdGlvbiBjb25m b3JtcyB0byAiVGhlCiAgIEd1aWRlbGluZXMgb24gdGhlIFByb3RlY3Rpb24gb2YgUGVyc29uYWwg SW5mb3JtYXRpb24gaW4gdGhlCiAgIFRlbGVjb21tdW5pY2F0aW9ucyBCdXNpbmVzcyIgKE1JQyBB bm5vdW5jZW1lbnQgTm8uIDY5NSBvZiAyMDA0KS4KCiAgIEFsc28gaXQgaXMgbmVjZXNzYXJ5IGZv ciB0aGUgRUNSTyB0byBpZGVudGlmeSBwZXIgY2FsbCB0aGUgSVAKICAgdGVsZWNvbW11bmljYXRp b24gcHJvdmlkZXIgdG8gd2hpY2ggdGhlIHJlcG9ydGVyIHN1YnNjcmliZXMuICBUaGlzCiAgIGZ1 bmN0aW9uYWxpdHkgYWxsb3dzIHRoZSBFQ1JPIHRoYXQgcmVjZWl2ZXMgdGhlIGVtZXJnZW5jeSBj YWxsIHRvCiAgIGlucXVpcmUgc3Vic2NyaWJlciBpbmZvcm1hdGlvbiBmb3IgdGhlIElQIHRlbGVj b21tdW5pY2F0aW9uIHByb3ZpZGVyCiAgIGV2ZW4gaWYgdGhlIEVDUk8gY291bGRuJ3QgYWNxdWly ZSByZXBvcnRlcidzIGluZm9ybWF0aW9uIG9uIHRoZQogICB0ZWxlcGhvbmUgbnVtYmVyIG9yIHRo ZSBnZW9ncmFwaGljYWwgbG9jYXRpb24gZXRjLgoKCgoKCkFyYWkgJiBLYXdhbmlzaGkgICAgICAg IEV4cGlyZXMgTm92ZW1iZXIgMTQsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA4XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgIEVtZXJnZW5jeSByZXEucyBpbiBKYXBhbiAgICAgICAgICAgICAg ICBNYXkgMjAwNQoKCjMuNCAgUHJlc2VudGluZyBhbmQgQWNxdWlyaW5nIEdlb2dyYXBoaWNhbCBM b2NhdGlvbiBJbmZvcm1hdGlvbgoKICAgR2VvZ3JhcGhpY2FsIGxvY2F0aW9uIGluZm9ybWF0aW9u IG9mIHRoZSByZXBvcnRlciBtdXN0IGJlIHByZXNlbnRlZAogICB0byB0aGUgRUNSTyB0aGF0IHJl Y2VpdmVzIHRoZSBjYWxsIHdoZW4gdGhlIEVDUk8gcmVjZWl2ZXMgdGhlIGNhbGwKICAgYW5kIHRo ZSBFQ1JPIGRlbWFuZHMgaW5mb3JtYXRpb24gZnJvbSB0aGUgSVAgdGVsZWNvbW11bmljYXRpb24K ICAgcHJvdmlkZXIuCgogICBUbyBjb25zaWRlciBhcHBseWluZyB0aGUgZXhpc3RpbmcgZ2VvZ3Jh cGhpY2FsIGxvY2F0aW9uIGluZm9ybWF0aW9uCiAgIHN5c3RlbSwgdGhlcmUgYXJlIHR3byBjb25m aWd1cmF0aW9uczsgb25lIGlzIHRoYXQgdHdvIGNvbm5lY3Rpb25zIGFyZQogICB1c2VkIGZvciB2 b2ljZSBhbmQgdGhlIGdlb2dyYXBoaWNhbCBsb2NhdGlvbiBzeXN0ZW0gaW5kaXZpZHVhbGx5LCBh bmQKICAgdGhlIG90aGVyIHByb3ZpZGVzIG9uZSBjb25uZWN0aW9uIGZvciB0aGVtLgoKICAgSFRU UCAoSHlwZXIgVGV4dCBUcmFuc2ZlciBQcm90b2NvbCkgaXMgdXNlZCBmb3IgdHJhbnNmZXJyaW5n CiAgIEdlb2dyYXBoaWNhbCBsb2NhdGlvbiBpbmZvcm1hdGlvbiB0aGF0IGlzIGZvcm1hdHRlZCBi eSBYTUwKICAgKGVYdGVuc2libGUgTWFya3VwIExhbmd1YWdlKS4KCiAgIFRoZSBjb250ZW50IG9m IHRoZSBsb2NhdGlvbiBpbmZvcm1hdGlvbiBtdXN0IGJlIGFjY3VyYXRlIHNvIHRoYXQgdGhlCiAg IGZpcmUgZGVwYXJ0bWVudCwgdGhlIHBvbGljZSBkZXBhcnRtZW50IGV0Yy4gbWF5IGRlYWwgd2l0 aCB0aGUgcHJvYmxlbQogICBwcm9tcHRseS4KCiAgIFRoZSBmb2xsb3dpbmcgc2hvd3MgdGhlIGNv bnRlbnRzIG9mIHRoZSBsb2NhdGlvbiBpbmZvcm1hdGlvbi4KCgogICBlbGVtZW50ICAgICAgICAg ICB0YWcgICAgICAgICAgcmVtYXJrcwogICAtLS0tLS0tLS0tLS0tLS0gICAtLS0tLS0tLS0tLSAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KICAgQ2FsbGVyIElEICAgICAgICAg cmVwb190ZWxlICAgIHJlcG9ydGVyJ3MgdGVsZXBob25lIG51bWJlcgoKICAgQXJlYSBvZiBhZGRy ZXNzICAgYWRkX2FyZWEgICAgIGFyZWEgb2YgcmVwb3J0ZXIncyBhZGRyZXNzCiAgICAgWmlwIGNv ZGUgICAgICAgIGFkZF9wb3N0ICAgICBwb3N0YWwgY29kZSBudW1iZXIKICAgICBBZGRyZXNzIGNv ZGUgICAgYWRkX2NvZGUgICAgIEpJUyhKYXBhbmVzZSBJbmR1c3RyaWFsIFN0YW5kYXJkKQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWRkcmVzcyBjb2RlCiAgICAgQWRkcmVzcyBu YW1lICAgIGFkZF9uYW1lICAgICBsaXRlcmFsIGluZm9ybWF0aW9uIGNvcnJlc3BvbmRpbmcKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRvIGFkZHJlc3MgY29kZSAobmFtZSBvZiBw cmVmZWN0dXJlLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2l0eSBvciBjb3Vu dHksIGV0Yy4pCiAgICAgQWRkcmVzcyBudW1iZXIgIGFkZF9udW0gICAgICBob3VzZSBudW1iZXIs IHN0cmVldCBudW1iZXIgZXRjLgogICAgIE90aGVycyAgICAgICAgICBhZGRfb3RoZXJzICAgaG91 c2UgbmFtZSwgYnVpbGRpbmcgbnVtYmVyLCByb29tCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBudW1iZXIsIG9yIGJ1aWxkaW5nIG5hbWUgYW5kIGZsb29yCgogICBBcmVhIG9mICAg ICAgICAgICBuYW1lX2FyZWEgICAgYXJlYSBvZiByZXBvcnRlcidzIG5hbWUKICAgcmVwb3J0ZXIn cyBuYW1lCiAgICAgTmFtZSBpbiBrYW5hICAgIG5hbWVfa2FuYSAgICBwcm9udW5jaWF0aW9uIG9m IHJlcG9ydGVyJ3MgbmFtZQogICAgIE5hbWUgaW4ga2FuamkgICBuYW1lX2thbmppICAgcmVwb3J0 ZXIncyBuYW1lIGluIGthbmppIGxldHRlcnMKICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKCiAgICAgICBGaWd1cmUg MTogVGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uIGZvciB0aGUgZml4ZWQgSVAgdGVsZXBob25lCgoK CgoKQXJhaSAmIEthd2FuaXNoaSAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxNCwgMjAwNSAgICAg ICAgICAgICAgIFtQYWdlIDldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgRW1lcmdlbmN5IHJl cS5zIGluIEphcGFuICAgICAgICAgICAgICAgIE1heSAyMDA1CgoKICAgZWxlbWVudCAgICAgICAg ICAgdGFnICAgICAgICAgIHJlbWFya3MKICAgLS0tLS0tLS0tLS0tLS0tICAgLS0tLS0tLS0tLS0g IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogICBDYWxsZXIgSUQgICAgICAg ICByZXBvX3RlbGUgICAgcmVwb3J0ZXIncyB0ZWxlcGhvbmUgbnVtYmVyCgogICBBcmVhIG9mIGxv Y2F0aW9uICBsb2NfYXJlYSAgICAgYXJlYSBvZiByZXBvcnRlcidzIGdlb2dyYXBoaWNhbAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbG9jYXRpb24gaW5mb3JtYXRpb24KICAgICBa aXAgY29kZSAgICAgICAgbG9jX3Bvc3QgICAgIHBvc3RhbCBjb2RlIG51bWJlcgogICAgIEFkZHJl c3MgY29kZSAgICBsb2NfY29kZSAgICAgSklTKEphcGFuZXNlIEluZHVzdHJpYWwgU3RhbmRhcmQp CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhZGRyZXNzIGNvZGUKICAgICBBZGRy ZXNzIG5hbWUgICAgbG9jX25hbWUgICAgIGxpdGVyYWwgaW5mb3JtYXRpb24gY29ycmVzcG9uZGlu ZwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8gYWRkcmVzcyBjb2RlIChuYW1l IG9mIHByZWZlY3R1cmUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjaXR5IG9y IGNvdW50eSwgZXRjLikKICAgICBBZGRyZXNzIG51bWJlciAgbG9jX251bSAgICAgIGhvdXNlIG51 bWJlciwgc3RyZWV0IG51bWJlciBldGMuCiAgICAgT3RoZXJzICAgICAgICAgIGxvY19vdGhlcnMg ICBob3VzZSBuYW1lLCBidWlsZGluZyBudW1iZXIsIHJvb20KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIG51bWJlciwgb3IgYnVpbGRpbmcgbmFtZSBhbmQgZmxvb3IKCiAgIEFyZWEg b2YgICAgICAgICAgIG5hbWVfYXJlYSAgICBhcmVhIG9mIHJlcG9ydGVyJ3MgbmFtZQogICByZXBv cnRlcidzIG5hbWUKICAgICBOYW1lIGluIGthbmEgICAgbmFtZV9rYW5hICAgIHByb251bmNpYXRp b24gb2YgcmVwb3J0ZXIncyBuYW1lCiAgICAgTmFtZSBpbiBrYW5qaSAgIG5hbWVfa2FuamkgICBy ZXBvcnRlcidzIG5hbWUgaW4ga2FuamkgbGV0dGVycwogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgoKICAgICBGaWd1 cmUgMjogVGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uIGZvciB0aGUgcG9ydGFibGUgSVAgdGVsZXBo b25lCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkFyYWkgJiBLYXdhbmlzaGkgICAgICAgIEV4 cGlyZXMgTm92ZW1iZXIgMTQsIDIwMDUgICAgICAgICAgICAgIFtQYWdlIDEwXQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgIEVtZXJnZW5jeSByZXEucyBpbiBKYXBhbiAgICAgICAgICAgICAgICBN YXkgMjAwNQoKCiAgIGVsZW1lbnQgICAgICAgICAgIHRhZyAgICAgICAgICByZW1hcmtzCiAgIC0t LS0tLS0tLS0tLS0tLSAgIC0tLS0tLS0tLS0tICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tCiAgIENhbGxlciBJRCAgICAgICAgIHJlcG9fdGVsZSAgICByZXBvcnRlcidzIHRl bGVwaG9uZSBudW1iZXIKICAgVGVybWluYWwgdHlwZSAgICAgdGVybV90eXBlICAgIHdoZXRoZXIg cmVwb3J0ZXIncyB0ZXJtaW5hbCBpcyBmaXhlZC0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHVzZSBvciBtb2JpbGUtdXNlCiAgIExvY2F0aW9uIHR5cGUgICAgIGxvY190eXBlICAg ICBpbmRpY2F0aW5nIGVpdGhlciBwbGFjZSBvZiBkaXNwYXRjaAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaW5mb3JtYXRpb24gb3IgcHJlc2VudCBwbGFjZQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgaW5mb3JtYXRpb24gKHNlZSAqMSkKICAgQXJlYSBvZiBsb2Nh dGlvbiAgbG9jX2FyZWEgICAgIGFyZWEgb2YgcmVwb3J0ZXIncyBnZW9ncmFwaGljYWwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxvY2F0aW9uIGluZm9ybWF0aW9uCiAgICAgWmlw IGNvZGUgICAgICAgIGxvY19wb3N0ICAgICBwb3N0YWwgY29kZSBudW1iZXIKICAgICBBZGRyZXNz IGNvZGUgICAgbG9jX2NvZGUgICAgIEpJUyhKYXBhbmVzZSBJbmR1c3RyaWFsIFN0YW5kYXJkKQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWRkcmVzcyBjb2RlCiAgICAgQWRkcmVz cyBuYW1lICAgIGxvY19uYW1lICAgICBsaXRlcmFsIGluZm9ybWF0aW9uIGNvcnJlc3BvbmRpbmcK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRvIGFkZHJlc3MgY29kZSAobmFtZSBv ZiBwcmVmZWN0dXJlLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2l0eSBvciBj b3VudHksIGFuZCBzbyBvbikKICAgICBBZGRyZXNzIG51bWJlciAgbG9jX251bSAgICAgIGhvdXNl IG51bWJlciwgc3RyZWV0IG51bWJlciBldGMuCiAgICAgT3RoZXJzICAgICAgICAgIGxvY19vdGhl cnMgICBob3VzZSBuYW1lLCBidWlsZGluZyBudW1iZXIsIHJvb20KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIG51bWJlciwgb3IgYnVpbGRpbmcgbmFtZSBhbmQgZmxvb3IKCiAgIEFy ZWEgb2YgICAgICAgICAgIENpcmN1bGFyQXJlYSBjaXJjdWxhciBhcmVhIGluY2x1ZGluZyBtZWFz dXJlZAogICBtZWFzdXJlZCBwb3NpdGlvbiAgICAgICAgICAgICAgcG9zaXRpb24KICAgICBMYXRp dHVkZSAgICAgICAgWCAgICAgICAgICAgIGxhdGl0dWRlIG9mIGNlbnRlciBvZiBDaXJjdWxhckFy ZWEKICAgICBMb25naXR1ZGUgICAgICAgWSAgICAgICAgICAgIGxvbmdpdHVkZSBvZiBjZW50ZXIg b2YgQ2lyY3VsYXJBcmVhCiAgICAgUmFkaXVzICAgICAgICAgIFJhZGl1cyAgICAgICByYWRpdXMg b2YgQ2lyY3VsYXJBcmVhCiAgICAgQWx0aXR1ZGUgICAgICAgIEFsdCAgICAgICAgICBhbHRpdHVk ZSBvZiByZXBvcnRlcidzIGxvY2F0aW9uCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAob3B0aW9uYWwpCiAgICAgUHJlY2lzaW9uIG9mIEFsdCAgYWx0X2FjYyAgICBwcmVjaXNpb24g b2YgQWx0IChvcHRpb25hbCkKCiAgIEFyZWEgb2YgICAgICAgICAgIG5hbWVfYXJlYSAgICBhcmVh IG9mIHJlcG9ydGVyJ3MgbmFtZQogICByZXBvcnRlcidzIG5hbWUKICAgICBOYW1lIGluIGthbmEg ICAgbmFtZV9rYW5hICAgIHByb251bmNpYXRpb24gb2YgcmVwb3J0ZXIncyBuYW1lCiAgICAgTmFt ZSBpbiBrYW5qaSAgIG5hbWVfa2FuamkgICByZXBvcnRlcidzIG5hbWUgaW4ga2FuamkgbGV0dGVy cwogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCgoKICAgICAgRmlndXJlIDM6IFRoZSBsb2NhdGlvbiBpbmZvcm1hdGlv biBmb3IgdGhlIG1vYmlsZSBJUCB0ZWxlcGhvbmUKCiAgICgqMSk6ICJQbGFjZSBvZiBkaXNwYXRj aCBpbmZvcm1hdGlvbiIgbWVhbnMgaW5mb3JtYXRpb24gb24gdGhlIHBsYWNlCiAgIHdoZXJlIHRo ZSByZXBvcnRlciBtYWtlcyB0aGUgZW1lcmdlbmN5IGNhbGwuICAiUHJlc2VudCBwbGFjZQogICBp bmZvcm1hdGlvbiIgbWVhbnMgaW5mb3JtYXRpb24gb24gdGhlIHBsYWNlIHdoZXJlIHRoZSByZXBv cnRlciBpcwogICB3aGVuIHRoZSBsb2NhdGlvbiBpbmZvcm1hdGlvbiBpcyBzZW50LgoKCgoKCgoK CgpBcmFpICYgS2F3YW5pc2hpICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDE0LCAyMDA1ICAgICAg ICAgICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBFbWVyZ2VuY3kgcmVx LnMgaW4gSmFwYW4gICAgICAgICAgICAgICAgTWF5IDIwMDUKCgo0LiAgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMKCiAgIFRCRAoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgpBcmFpICYgS2F3YW5pc2hpICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDE0LCAyMDA1 ICAgICAgICAgICAgICBbUGFnZSAxMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBFbWVyZ2Vu Y3kgcmVxLnMgaW4gSmFwYW4gICAgICAgICAgICAgICAgTWF5IDIwMDUKCgo1LiAgSUFOQSBDb25z aWRlcmF0aW9ucwoKICAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBjb250YWluIElBTkEgY29uc2lk ZXJhdGlvbnMuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CkFyYWkgJiBLYXdhbmlzaGkgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMTQsIDIwMDUgICAgICAg ICAgICAgIFtQYWdlIDEzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIEVtZXJnZW5jeSByZXEu cyBpbiBKYXBhbiAgICAgICAgICAgICAgICBNYXkgMjAwNQoKCkFwcGVuZGl4IEEuICBKYXBhbmVz ZSBBZGRyZXNzIENvZGUgZm9yIExvY2F0aW9uIEluZm9ybWF0aW9uCgogICBUaGUgYWRkcmVzcyBj b2RlIFtMQVNERUNdIGlzIHVzZWQgYXMgb25lIGVsZW1lbnQgb2YgdGhlIGxvY2F0aW9uCiAgIGlu Zm9ybWF0aW9uIHRoYXQgaXMgdHJhbnNmZXJyZWQgYXMgYSBnZW9ncmFwaGljYWwgbG9jYXRpb24K ICAgaW5mb3JtYXRpb24gdG8gYW4gZW1lcmdlbmN5IGNhbGwgcmVjZXB0aW9uIG9mZmljZSBpbiBT ZWN0aW9uIDMuNC4KCiAgIEl0IGlzIDExLWRpZ2l0IGNvZGUsIHdoaWNoIGNvbnNpc3RzIG9mIDIt ZGlnaXQgcHJlZmVjdHVyZSBjb2RlLAogICAzLWRpZ2l0IG11bmljaXBhbGl0eSBjb2RlLCAzLWRp Z2l0IHNlY3Rpb24gY29kZSBhbmQgMy1kaWdpdAogICBzdWJzZWN0aW9uIGNvZGUuICBDdXJyZW50 bGx5LCBhcHByb3hpbWF0ZWx5IDUwMDAwMCBjb2RlcyBhcmUKICAgcmVnaXN0ZXJlZC4KCiAgICst LS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKwogICB8IGRpZ2l0IHwgbmFtZSBvZiBjb2RlICB8IHZhbHVlICAgICAgfCByZW1h cmtzICAgICAgICAgICAgICAgICAgICAgIHwKICAgKy0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgIHwgMSYyICAgfCBw cmVmZWN0dXJlICAgIHwgMDEtIDQ3ICAgICB8IHByZWZlY3R1cmUgICAgICAgICAgICAgICAgICAg fAogICB8ICAgICAgIHwgY29kZSAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgMy01ICAgfCBtdW5pY2lwYWxp dHkgIHwgMTAwLTE5OSAgICB8IHdhcmQgKGluIGFuICAgICAgICAgICAgICAgICAgfAogICB8ICAg ICAgIHwgY29kZSAgICAgICAgICB8ICAgICAgICAgICAgfCBvcmRpbmFuY2UtZGVzaWduYXRlZCBj aXR5KSAgIHwKICAgfCAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgIHwgYW5kIHNw ZWNpYWwtd2FyZCAgICAgICAgICAgICB8CiAgIHwgICAgICAgfCAgICAgICAgICAgICAgIHwgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgIHwgICAg ICAgICAgICAgICB8IDIwMS0yOTkgICAgfCBjaXR5IG90aGVyIHRoYW4gYWJvdmUgICAgICAgIHwK ICAgfCAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgIHwgICAgICAgfCAgICAgICAgICAgICAgIHwgMzAxLTc5OSAgICB8 IHRvd24gYW5kIHZpbGxhZ2UgKGluIGEgICAgICAgfAogICB8ICAgICAgIHwgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgfCBkaXN0cmljdCkgICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAg ICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgIHwgNi04ICAgfCBzZWN0aW9uIGNvZGUgIHwgMDAxLTk5OSAgICB8IHNlY3Rpb24g b2YgYSBtdW5pY2lwYWxpdHkgICAgfAogICB8ICAgICAgIHwgICAgICAgICAgICAgICB8IDEwQS05 OVkoKikgfCBhbmQgYnktbmFtZSBvZiBhbiBhcmVhICAgICAgIHwKICAgfCAgICAgICB8ICAgICAg ICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAg IHwgOS0xMSAgfCBzdWJzZWN0aW9uICAgIHwgMDAxLTA5OSAgICB8ICJDaG9tZSIgdGhhdCBkZXZp ZGVzIGEgICAgICAgfAogICB8ICAgICAgIHwgY29kZSAgICAgICAgICB8ICAgICAgICAgICAgfCBz ZWN0aW9uICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICB8ICAgICAgICAgICAgICAg fCAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAg fCAgICAgICAgICAgICAgIHwgMTAxLTg0OSAgICB8IGJ5LW5hbWUgb2YgYW4gYXJlYSAgICAgICAg ICAgfAogICB8ICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICB8ICAgICAgICAgICAgICAgfCA4NTEtODk5 ICAgIHwgaXQgaXMgdXNlZCB3aGVuIGFyZWFzIHRoYXQgICB8CiAgIHwgICAgICAgfCAgICAgICAg ICAgICAgIHwgICAgICAgICAgICB8IGFyZSBzaG93biBpbiB0aGUgc2FtZSBwbGFjZSAgfAogICB8 ICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgfCBuYW1lIGhhdmUgZGlmZmVyZW50 IHBvc3RhbCAgIHwKICAgfCAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgIHwgY29k ZXMgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgfCAgICAgICAgICAgICAgIHwg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgIHwg ICAgICAgICAgICAgICB8IDkwMS05OTkgICAgfCBmb3IgYWRkcmVzcyBuYW1lIG9mIEt5b3RvICAg IHwKICAgfCAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgIHwgQ2l0eSAgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgICstLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKICAgKCopOlRoZSBjYXBpdGFsIGxl dHRlcnMgb2YgdGhlIFJvbWFuIGFscGhhYmV0IGFyZSBhbHNvIHVzZWQgb24gOHRoCiAgIGRpZ2l0 LiAgSW4gb3JkZXIgdG8gcHJldmVudCBtaXNyZWFkaW5nIHRoZW0gYXMgbnVtZXJhbHMsICdPJywg J0knLAogICAnUycgYW5kICdaJyBtdXN0IG5vdCBiZSB1c2VkIHRoZXJlLgoKICAgICAgICAgICAg ICAgICAgICBUYWJsZSAxOiBTdHJ1Y3R1cmUgb2YgQWRkcmVzcyBDb2RlCgoKCkFyYWkgJiBLYXdh bmlzaGkgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMTQsIDIwMDUgICAgICAgICAgICAgIFtQYWdl IDE0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIEVtZXJnZW5jeSByZXEucyBpbiBKYXBhbiAg ICAgICAgICAgICAgICBNYXkgMjAwNQoKCkFwcGVuZGl4IEEuMSAgUHJlZmVjdHVyZSBjb2RlCgog ICBUaGlzIGlzIHRoZSB0b3AgbGV2ZWwgb2YgdGhlIGFkZHJlc3MgY29kZSBhbmQgY29uc2lzdHMg b2YgMi1kaWdpdAogICBiZXR3ZWVuIDAxIGFuZCA0NyBpbiB0aGUgZGVjaW1hbCBzeXN0ZW0uICBK YXBhbiBjb25zaXN0cyBvZiA0NwogICBwcmVmZWN0dXJlcyBhcyB5b3UgY2FuIHJlZmVyIGZyb20g dGhlIGZvbGxvd2luZyBVUkwuCgogICBodHRwOi8vdXBsb2FkLndpa2ltZWRpYS5vcmcvd2lraXBl ZGlhL2phL2YvZmQvSmFwYW5fcHJlZmVjdHVyZXMucG5nCgogICAgICBudW1iZXJzOiBlcXVhbCB0 byBwcmVmZWN0dXJlIGNvZGUKCiAgICAgIHJlZCBsaW5lczogdGhlIGJvdW5kYXJpZXMgb2YgZWFj aCBwcmVmZWN0dXJlCgogICAgICBibHVlIGxpbmVzOiBjb2FzdGxpbmVzLCBvciB0aGUgYm91bmRh cmllcyBvZiBhbiBhcmVhIG9mIGEgcml2ZXIgb3IKICAgICAgICAgYSBsYWtlCgogICBUaGlzIGNv ZGUgaXMgZGVmaW5lZCBieSBbSklTIFggMDQwMV0uICBBbmQgYWxzbyBbSVNPIDMxNjYtMl0gZGVm aW5lcwogICB0aGUgc2ltaWxhciBjb2RlLgoKICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgIHwgSklTIFggMDQw MSAgICAgIHwgSVNPIDMxNjYtMiAgICAgIHwgTmFtZSBvZiBwcmVmZWN0dXJlICAgICAgICAgICAg fAogICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsKICAgfCAwMSAgICAgICAgICAgICAgfCBKUC0wMSAgICAgICAgICAg fCBIb2trYWlkbyAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDAy ICAgICAgICAgICAgICB8IEpQLTAyICAgICAgICAgICB8IEFvbW9yaSAgICAgICAgICAgICAgICAg ICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgMDMgICAgICAgICAgICAgIHwgSlAtMDMgICAg ICAgICAgIHwgSXdhdGUgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgfCAwNCAgICAgICAgICAgICAgfCBKUC0wNCAgICAgICAgICAgfCBNaXlhZ2kgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDA1ICAgICAgICAgICAgICB8IEpQ LTA1ICAgICAgICAgICB8IEFraXRhICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgIHwgMDYgICAgICAgICAgICAgIHwgSlAtMDYgICAgICAgICAgIHwgWWFtYWdhdGEg ICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAwNyAgICAgICAgICAg ICAgfCBKUC0wNyAgICAgICAgICAgfCBGdWt1c2hpbWEgICAgICAgICAgICAgICAgICAgICB8CiAg IHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICB8IDA4ICAgICAgICAgICAgICB8IEpQLTA4ICAgICAgICAgICB8IEli YXJha2kgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgMDkgICAg ICAgICAgICAgIHwgSlAtMDkgICAgICAgICAgIHwgVG9jaGlnaSAgICAgICAgICAgICAgICAgICAg ICAgfAogICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwKICAgfCAxMCAgICAgICAgICAgICAgfCBKUC0xMCAgICAgICAg ICAgfCBHdW1tYSAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8 IDExICAgICAgICAgICAgICB8IEpQLTExICAgICAgICAgICB8IFNhaXRhbWEgICAgICAgICAgICAg ICAgICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgMTIgICAgICAgICAgICAgIHwgSlAtMTIg ICAgICAgICAgIHwgQ2hpYmEgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgfCAxMyAgICAgICAgICAgICAgfCBKUC0xMyAgICAgICAgICAgfCBUb2t5byAgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDE0ICAgICAgICAgICAgICB8 IEpQLTE0ICAgICAgICAgICB8IEthbmFnYXdhICAgICAgICAgICAgICAgICAgICAgIHwKCgoKQXJh aSAmIEthd2FuaXNoaSAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxNCwgMjAwNSAgICAgICAgICAg ICAgW1BhZ2UgMTVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgRW1lcmdlbmN5IHJlcS5zIGlu IEphcGFuICAgICAgICAgICAgICAgIE1heSAyMDA1CgoKICAgfCAxNSAgICAgICAgICAgICAgfCBK UC0xNSAgICAgICAgICAgfCBOaWlnYXRhICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICB8IDE2ICAgICAgICAgICAgICB8IEpQLTE2ICAgICAgICAgICB8IFRveWFtYSAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgMTcgICAgICAgICAg ICAgIHwgSlAtMTcgICAgICAgICAgIHwgSXNoaWthd2EgICAgICAgICAgICAgICAgICAgICAgfAog ICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwKICAgfCAxOCAgICAgICAgICAgICAgfCBKUC0xOCAgICAgICAgICAgfCBG dWt1aSAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDE5ICAg ICAgICAgICAgICB8IEpQLTE5ICAgICAgICAgICB8IFlhbWFuYXNoaSAgICAgICAgICAgICAgICAg ICAgIHwKICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8CiAgIHwgMjAgICAgICAgICAgICAgIHwgSlAtMjAgICAgICAg ICAgIHwgTmFnYW5vICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg fCAyMSAgICAgICAgICAgICAgfCBKUC0yMSAgICAgICAgICAgfCBHaWZ1ICAgICAgICAgICAgICAg ICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDIyICAgICAgICAgICAgICB8IEpQLTIy ICAgICAgICAgICB8IFNoaXp1b2thICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgIHwgMjMgICAgICAgICAgICAgIHwgSlAtMjMgICAgICAgICAgIHwgQWljaGkgICAgICAg ICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAyNCAgICAgICAgICAgICAg fCBKUC0yNCAgICAgICAgICAgfCBNaWUgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICB8IDI1ICAgICAgICAgICAgICB8IEpQLTI1ICAgICAgICAgICB8IFNoaWdh ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgMjYgICAgICAg ICAgICAgIHwgSlAtMjYgICAgICAgICAgIHwgS3lvdG8gICAgICAgICAgICAgICAgICAgICAgICAg fAogICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgfCAyNyAgICAgICAgICAgICAgfCBKUC0yNyAgICAgICAgICAg fCBPc2FrYSAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDI4 ICAgICAgICAgICAgICB8IEpQLTI4ICAgICAgICAgICB8IEh5b2dvICAgICAgICAgICAgICAgICAg ICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgMjkgICAgICAgICAgICAgIHwgSlAtMjkgICAg ICAgICAgIHwgTmFyYSAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgfCAzMCAgICAgICAgICAgICAgfCBKUC0zMCAgICAgICAgICAgfCBXYWtheWFtYSAgICAgICAg ICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDMxICAgICAgICAgICAgICB8IEpQ LTMxICAgICAgICAgICB8IFRvdHRvcmkgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgIHwgMzIgICAgICAgICAgICAgIHwgSlAtMzIgICAgICAgICAgIHwgU2hpbWFuZSAg ICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAzMyAgICAgICAgICAg ICAgfCBKUC0zMyAgICAgICAgICAgfCBPa2F5YW1hICAgICAgICAgICAgICAgICAgICAgICB8CiAg IHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICB8IDM0ICAgICAgICAgICAgICB8IEpQLTM0ICAgICAgICAgICB8IEhp cm9zaGltYSAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgMzUgICAg ICAgICAgICAgIHwgSlAtMzUgICAgICAgICAgIHwgWWFtYWd1Y2hpICAgICAgICAgICAgICAgICAg ICAgfAogICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwKICAgfCAzNiAgICAgICAgICAgICAgfCBKUC0zNiAgICAgICAg ICAgfCBUb2t1c2hpbWEgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8 IDM3ICAgICAgICAgICAgICB8IEpQLTM3ICAgICAgICAgICB8IEthZ2F3YSAgICAgICAgICAgICAg ICAgICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgMzggICAgICAgICAgICAgIHwgSlAtMzgg ICAgICAgICAgIHwgRWhpbWUgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKCgoKQXJhaSAmIEthd2FuaXNoaSAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxNCwgMjAwNSAg ICAgICAgICAgICAgW1BhZ2UgMTZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgRW1lcmdlbmN5 IHJlcS5zIGluIEphcGFuICAgICAgICAgICAgICAgIE1heSAyMDA1CgoKICAgfCAzOSAgICAgICAg ICAgICAgfCBKUC0zOSAgICAgICAgICAgfCBLb2NoaSAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfAogICB8IDQwICAgICAgICAgICAgICB8IEpQLTQwICAgICAgICAgICB8 IEZ1a3Vva2EgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgNDEg ICAgICAgICAgICAgIHwgSlAtNDEgICAgICAgICAgIHwgU2FnYSAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCA0MiAgICAgICAgICAgICAgfCBKUC00MiAgICAg ICAgICAgfCBOYWdhc2FraSAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog ICB8IDQzICAgICAgICAgICAgICB8IEpQLTQzICAgICAgICAgICB8IEt1bWFtb3RvICAgICAgICAg ICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgNDQgICAgICAgICAgICAgIHwgSlAt NDQgICAgICAgICAgIHwgT2l0YSAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwKICAgfCA0NSAgICAgICAgICAgICAgfCBKUC00NSAgICAgICAgICAgfCBNaXlhemFraSAg ICAgICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDQ2ICAgICAgICAgICAg ICB8IEpQLTQ2ICAgICAgICAgICB8IEthZ29zaGltYSAgICAgICAgICAgICAgICAgICAgIHwKICAg fCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8CiAgIHwgNDcgICAgICAgICAgICAgIHwgSlAtNDcgICAgICAgICAgIHwgT2tp bmF3YSAgICAgICAgICAgICAgICAgICAgICAgfAogICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKCiAgICAgICAgICAg ICAgICAgICAgICAgICBUYWJsZSAyOiBQcmVmZWN0dXJlIGNvZGUKCgpBcHBlbmRpeCBBLjIgIE11 bmljaXBhbGl0eSBjb2RlCgogICBUaGlzIGZvbGxvd3MgdGhlIFByZWZlY3R1cmUgY29kZSBhbmQg Y29uc2lzdHMgb2YgMy1kaWdpdCBpbiB0aGUKICAgZGVjaW1hbCBzeXN0ZW0uICBUaGlzIGNvZGUg c2hvd3MgYSBzcGVjaWFsLXdhcmQsIGEgd2FyZCBpbiBhbgogICBnb3Zlcm5tZW50LWRlc2lnbmF0 ZWQgbWFqb3IgY2l0eSwgYSBjaXR5LCBvciBhIHRvd24gb3IgYSB2aWxsYWdlIGluIGEKICAgZGlz dHJpY3QuICBUaGUgZm9sbG93aW5nIFVSTCBzaG93cyB0aGUgZGl2aXNpb24uICBUaGVyZSBhcmUg MjMKICAgc3BlY2lhbC13YXJkcyAoaW4gVG9reW8pLCA3MjYgY2l0aWVzLCAxNTU5IHRvd25zIGFu ZCA0MDAgdmlsbGFnZXMgYXMKICAgb2YgMTQgTWFyLiAyMDA1LgoKICAgaHR0cDovL3VwbG9hZC53 aWtpbWVkaWEub3JnL3dpa2lwZWRpYS9qYS83LzdiL0phcGFuX21hcC5wbmcKCiAgICAgIGJsYWNr IGxpbmVzOiB0aGUgYm91bmRhcmllcyBvZiBlYWNoIG11bmljaXBhbGl0eQoKICAgICAgcmVkIGxp bmVzOiB0aGUgYm91bmRhcmllcyBvZiBlYWNoIHByZWZlY3R1cmUKCiAgICAgIGJsdWUgbGluZXM6 IGNvYXN0bGluZXMsIG9yIHRoZSBib3VuZGFyaWVzIG9mIGFuIGFyZWEgb2YgYSByaXZlciBvcgog ICAgICAgICBhIGxha2UKCiAgIFRoaXMgY29kZSBpcyBkZWZpbmVkIGJ5IFtKSVMgWCAwNDAyXS4K CkFwcGVuZGl4IEEuMi4xICBQcmVmZWN0dXJlCgogICAwMDAgaXMgdXNlZCBmb3IgYSBwcmVmZWN0 dXJlLiAgRm9yIGV4YW1wbGUsIEhva2thaWRvIGlzIDAxMDAwLgoKCgoKCgpBcmFpICYgS2F3YW5p c2hpICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDE0LCAyMDA1ICAgICAgICAgICAgICBbUGFnZSAx N10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBFbWVyZ2VuY3kgcmVxLnMgaW4gSmFwYW4gICAg ICAgICAgICAgICAgTWF5IDIwMDUKCgpBcHBlbmRpeCBBLjIuMiAgR292ZXJubWVudC1kZXNpZ25h dGVkIG1ham9yIGNpdGllcyBhbmQgd2FyZHMKCiAgIEEgZ292ZXJubWVudC1kZXNpZ25hdGVkIG1h am9yIGNpdHkgaXMgYSBjaXR5IG9mIDUwMDAwMCBvciBtb3JlLAogICBncmFudGVkIHNwZWNpYWwg cmlnaHRzIGJ5IGdvdmVybm1lbnQgb3JkaW5hbmNlLgoKICAgVGhlIGNvZGUgZm9yIGEgZ292ZXJu bWVudC1kZXNpZ25hdGVkIG1ham9yIGNpdHkgaXMgdXNlZCB0aGUgbnVtYmVyCiAgIHN0YXJ0aW5n IGZyb20gMTAwIGV2ZXJ5IDMwIGluIG9yZGVyIHRoYXQgdGhlIG9yZGluYW5jZS1kZXNpZ25hdGVk CiAgIGNpdHkgaXMgZW5mb3JjZWQgaW4gYSBwcmVmZWN0dXJlLCBlLmcuIDEwMCwgMTMwLCAxNjAu ICBBbmQgZWFjaCB3YXJkCiAgIGluIHRoZSBjaXRpZXMgaXMgc2VxdWVudGlhbGx5IG51bWJlcmVk IGZyb20gMTAxLCAxMzEsIDE2MS4KCiAgIEZvciBleGFtcGxlLCBpbiBjYXNlIG9mIFlva29oYW1h IENpdHkgYW5kIEthd2FzYWtpIENpdHkgdGhhdCBhcmUKICAgZ292ZXJtZW50LWRlc2lnbmF0ZWQg bWFqb3IgY2l0aWVzIGluIEthbmFnYXdhIHByZWZlY3R1cmUgKHdoaWNoCiAgIHByZWZlY3R1cmUg Y29kZSBpcyAxNCk7CgogICAgICBZb2tvaGFtYSBDaXR5OiAxNDEwMAoKICAgICAgICAgVHN1cnVt aSBXYXJkOiAxNDEwMQoKICAgICAgICAgS2FuYWdhd2EgV2FyZDogMTQxMDIKCiAgICAgICAgIC4u LgoKICAgICAgS2F3YXNha2kgQ2l0eTogMTQxMzAKCiAgICAgICAgIEthd2FzYWtpIFdhcmQ6IDE0 MTMxCgogICAgICAgICBTYWl3YWkgV2FyZDogMTQxMzIKCiAgICAgICAgIC4uLgoKCkFwcGVuZGl4 IEEuMi4zICBTcGVjaWFsLXdhcmRzIGluIFRva3lvCgogICAxMDAgaXMgYXNzaWduZWQgZm9yICJT cGVjaWFsLXdhcmQiIGFzIHdlbGwgYXMgdGhlIGdvdmVybm1lbnQtCiAgIGRlc2lnbmF0ZWQgbWFq b3IgY2l0eS4gIEFuZCBlYWNoIHdhcmQgaW4gVG9reW8gKHdoaWNoIHByZWZlY3R1cmUgY29kZQog ICBpcyAxMykgaXMgc2VxdWVudGlhbGx5IG51bWJlcmVkIGZyb20gMTAxLgoKICAgRm9yIGV4YW1w bGU7CgogICAgICBTcGVjaWFsLXdhcmQ6IDEzMTAwCgogICAgICBDaGl5b2RhIHdhcmQ6IDEzMTAx CgogICAgICBDaHVvIHdhcmQ6IDEzMTAyCgoKCgoKCgpBcmFpICYgS2F3YW5pc2hpICAgICAgICBF eHBpcmVzIE5vdmVtYmVyIDE0LCAyMDA1ICAgICAgICAgICAgICBbUGFnZSAxOF0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICBFbWVyZ2VuY3kgcmVxLnMgaW4gSmFwYW4gICAgICAgICAgICAgICAg TWF5IDIwMDUKCgogICAgICAuLi4KCgpBcHBlbmRpeCBBLjIuNCAgQ2l0aWVzCgogICBFYWNoIGNp dHkgZXhjZXB0aW5nIEdvdmVybm1lbnQtZGVzaWduYXRlZCBtYWpvciBjaXRpZXMgaXMKICAgc2Vx dWVudGlhbGx5IG51bWJlcmVkIGZyb20gMjAxLiAgVXN1YWxseSB0aGUgbnVtYmVyIGlzIGFzc2ln bmVkIGluCiAgIG9yZGVyIG9mIHRoZSBtdW5pY2lwYWwgb3JnYW5pemF0aW9uIGVuZm9yY2VtZW50 LgoKICAgRm9yIGV4YW1wbGUsIGluIGNhc2Ugb2YgVG9reW8gcHJlZmVjdHVyZTsKCiAgICAgIEhh Y2hpb2ppIENpdHk6IDEzMjAxCgogICAgICBUYWNoaWthd2EgQ2l0eTogMTMyMDIKCiAgICAgIE11 c2FzaGlubyBDaXR5OiAxMzIwMwoKICAgICAgLi4uCgoKQXBwZW5kaXggQS4yLjUgIFRvd25zIGFu ZCBWaWxsYWdlcwoKICAgVGhlIG51bWJlciBmcm9tIDMwMSBpcyBhc3NpZ25lZCBmb3IgZWFjaCB0 b3duIGFuZCB2aWxsYWdlLiAgVGhlIHRvd24KICAgYW5kIHZpbGxhZ2UgaXMgbWFkZSBhIGdyb3Vw IGluIGVhY2ggZGlzdHJpY3QsIGFuZCB0aGUgbnVtYmVyIG9mIGV2ZXJ5CiAgIDIwIGlzIGdpdmVu IHNlcXVlbnRpYWxseSBhcyAzMDEsIDMyMSwgMzQxLgoKICAgRm9yIGV4YW1wbGUsIGluIGNhc2Ug b2YgSGlnYXNoaS1Uc3VnYXJ1IERpc3RyaWN0IGFuZCBOaXNoaS1Uc3VnYXJ1CiAgIERpc3RyaWN0 IG9mIEFvbW9yaSBwcmVmZWN0dXJlICh3aGljaCBjb2RlIGlzIDAyKTsKCiAgICAgIEhpZ2FzaGkt VHN1Z2FydSBEaXN0cmljdAoKICAgICAgICAgSGlyYW5haSBUb3duOiAwMjMwMQoKICAgICAgICAg S2FuaXRhIFRvd246IDAyMzAyCgogICAgICAgICBJbWFiZXRzdSBUb3duOiAwMjMwMwoKICAgICAg ICAgLi4uCgogICAgICBOaXNoaS1Uc3VnYXJ1IERpc3RyaWN0CgogICAgICAgICBBamlnYXNhd2Eg VG93bjogMDIzMjEKCiAgICAgICAgIEZ1a2F1cmEgVG93bjogMDIzMjMKCgoKCgoKCkFyYWkgJiBL YXdhbmlzaGkgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMTQsIDIwMDUgICAgICAgICAgICAgIFtQ YWdlIDE5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIEVtZXJnZW5jeSByZXEucyBpbiBKYXBh biAgICAgICAgICAgICAgICBNYXkgMjAwNQoKCiAgICAgICAgIEl3YXNha2kgVmlsbGFnZTogMDIz MjUKCiAgICAgICAgIC4uLgoKICAgICAgICAgTm90ZSB0aGF0IDAyMzIyLCAwMjMyNCBhcmUgbWlz c2luZyBudW1iZXIgZHVlIHRvIG11bmljaXBhbAogICAgICAgICBtZXJnZXJzLgoKICAgRXhjZXB0 aW9uYWxseSwgU2hpbWFqaXJpIERpc3RyaWN0IG9mIE9raW5hd2EgUHJlZmVjdHVyZSBpcyBhc3Np Z25lZAogICBiZXR3ZWVuIDM0MSBhbmQgMzY5LCBhbmQgTWl5YWtvIERpc3RyaWN0IGlzIGFzc2ln bmVkIGJldHdlZW4gMzcxIGFuZAogICAzNzksIGJlY2F1c2UgU2hpbWFqaXJpIERpc3RyaWN0IGNv bnNpc3RlZCBvZiBtb3JlIHRoYW4gMjAgdG93bnMgYW5kCiAgIHZpbGxhZ2VzLgoKICAgSW4gdGhl IGNhc2Ugb2YgSG9ra2FpZG8sIGVhY2ggYnJhbmNoIGFkbWluaXN0cmF0aXZlIG9mZmljZSBpcyBt YWRlIGEKICAgZ3JvdXAsIGFuZCB0aGUgbnVtYmVyIGlzIGdpdmVuIGF0IGludGVydmFscyBvZiAz MCBzdWNoIGFzIDMwMSwgMzMxLAogICAzNjEuICBBbmQgYWxzbyBpbiB0aGUgY2FzZSBvZiBzb2xp dGFyeSBpc2xhbmRzIG9mIFRva3lvIHByZWZlY3R1cmUKICAgYW5kIFRzdXNoaW1hIGlzbGFuZHMg b2YgTmFnYXNha2kgcHJlZmVjdHVyZSwgZWFjaCBicmFuY2gKICAgYWRtaW5pc3RyYXRpdmUgb2Zm aWNlIGlzIG1hZGUgYSBncm91cCwgYW5kIHRoZSBudW1iZXIgZm9sbG93aW5nIHRoZQogICBtYWlu bGFuZCBpcyBnaXZlbiBhdCBpbnRlcnZhbHMgb2YgMjAuCgoKQXBwZW5kaXggQS4zICBTZWN0aW9u IGNvZGUgYW5kIFN1YnNlY3Rpb24gY29kZQoKICAgU2VjdGlvbiBjb2RlIGFuZCBTdWJzZWN0aW9u IGNvZGUgYXJlIGRlZmluZWQgYnkgdHdvIHB1YmxpYwogICBjb3Jwb3JhdGlvbnMgdW5kZXIgdGhl IGp1cmlzZGljdGlvbiBvZiB0aGUgTWluaXN0cnkgb2YgSW50ZXJuYWwKICAgQWZmYWlycyBhbmQg Q29tbXVuaWNhdGlvbnMsIHdoaWNoIGFyZSBMQVNERUMgKExvY2FsIEF1dGhvcml0aWVzCiAgIFN5 c3RlbXMgRGV2ZWxvcG1lbnQgQ2VudGVyLCBodHRwOi8vd3d3Lmxhc2RlYy5uaXBwb24tbmV0Lm5l LmpwLykgYW5kCiAgIEpHREMgKEphcGFuIEdlb2dyYXBoaWMgRGF0YSBDZW50ZXIsIGh0dHA6Ly93 d3cua29rdWRvLm9yLmpwLykuICBUaGVzZQogICBhcmUgdXNlZCBmb3IgcmVwcmVzZW50aW5nIG9m ZmljaWFsIGFkZHJlc3MgbmFtZXMgYW5kIHBvcHVsYXIgbmFtZXMuCiAgIEFzIHBvcHVsYXIgbmFt ZXMsIHRoZXJlIGFyZSB0aGUgbmFtZSBvZiBhbiBhcmNoaXRlY3R1cmUsIHRoZSBudW1iZXIKICAg b2YgZmxvb3IgYW5kIHNvIG9uLgoKKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsKfCBjb2RlICAgICAgICB8IFByZWZl Y3R1cmUgfCBNdW5pY2lwYWxpdHkgfCBTZWN0aW9uICAgICAgfCBTdWJzZWN0aW9uIHwKKy0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLSsKfCAxMzEwNDExMjAwMCB8IFRva3lvICAgICAgfCBTaGluanVrdSAgICAgfCBJc2xh bmQtVG93ZXIgfCAgICAgICAgICAgIHwKfCAgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgIHwKfCAxMzEwNDExMjEwMSB8IFRv a3lvICAgICAgfCBTaGluanVrdSAgICAgfCBJc2xhbmQtVG93ZXIgfCAxc3QgZmxvb3IgIHwKfCAg ICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAg ICAgICAgICAgIHwKfCAxMzEwNDExMjEwMiB8IFRva3lvICAgICAgfCBTaGluanVrdSAgICAgfCBJ c2xhbmQtVG93ZSAgfCAybmQgZmxvb3IgIHwKKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsKCiAgICAgICAgICAgICAg IFRhYmxlIDM6IEV4YW1wbGU6IGFkZHJlc3MgY29kZSBvZiBhIGJ1aWxkaW5nCgogICAxMyBpcyB0 aGUgY29kZSBvZiBUb2t5byBwcmVmZWN0dXJlLCAxMDQgaXMgU2hpbmp1a3UgV2FyZCwgMTEyIGlz CiAgIElzbGFuZC1Ub3dlciBidWlsZGluZy4gIEFuZCB0aGUgbnVtYmVyIG9mIGZsb29yIGlzIGEg a2luZCBvZiBwdXBsYXIKICAgbmFtZXMsIHNvIDEwMSBhbmQgMTAyIGFyZSBhc3NpZ25lZC4KCiAg IEFuZCBJc2xhbmQtVG93ZXIgaXMgaW4gTmlzaGktU2hpbmp1a3UsIFNoaW5qdWt1IFdhcmQsIFRv a3lvCgoKCkFyYWkgJiBLYXdhbmlzaGkgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMTQsIDIwMDUg ICAgICAgICAgICAgIFtQYWdlIDIwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIEVtZXJnZW5j eSByZXEucyBpbiBKYXBhbiAgICAgICAgICAgICAgICBNYXkgMjAwNQoKCiAgIHByZWZlY3R1cmUu ICBUaGUgY29kZXMgb2YgdGhhdCBhcmVhIGFyZSB0aGUgZm9sbG93aW5nOwoKICAgKy0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0rCiAgIHwgY29kZSAgICAgICAgfCBQcmVmZWN0dXJlICB8IE11bmljaXBhbGl0eSB8IFNlY3Rp b24gIHwgU3Vic2VjdGlvbiAgfAogICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSsKICAgfCAxMzEwNDA3MDAwMSB8IFRv a3lvICAgICAgIHwgU2hpbmp1a3UgICAgIHwgTmlzaGktICAgfCAxLUNob21lICAgICB8CiAgIHwg ICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8IFNoaW5qdWt1IHwgICAg ICAgICAgICAgfAogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAg fCAgICAgICAgICB8ICAgICAgICAgICAgIHwKICAgfCAxMzEwNDA3MDAwMiB8IFRva3lvICAgICAg IHwgU2hpbmp1a3UgICAgIHwgTmlzaGktICAgfCAyLUNob21lICAgICB8CiAgIHwgICAgICAgICAg ICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8IFNoaW5qdWt1IHwgICAgICAgICAgICAg fAogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAg ICB8ICAgICAgICAgICAgIHwKICAgfCAxMzEwNDA3MDAwMyB8IFRva3lvICAgICAgIHwgU2hpbmp1 a3UgICAgIHwgTmlzaGktICAgfCAzLUNob21lICAgICB8CiAgIHwgICAgICAgICAgICAgfCAgICAg ICAgICAgICB8ICAgICAgICAgICAgICB8IFNoaW5qdWt1IHwgICAgICAgICAgICAgfAogICB8ICAg ICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAg ICAgICAgIHwKICAgfCAxMzEwNDA3MDAwNCB8IFRva3lvICAgICAgIHwgU2hpbmp1a3UgICAgIHwg TmlzaGktICAgfCA0LUNob21lICAgICB8CiAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8 ICAgICAgICAgICAgICB8IFNoaW5qdWt1IHwgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAg IHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgIHwK ICAgfCAxMzEwNDA3MDAwNSB8IFRva3lvICAgICAgIHwgU2hpbmp1a3UgICAgIHwgTmlzaGktICAg fCA1LUNob21lICAgICB8CiAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAg ICAgICB8IFNoaW5qdWt1IHwgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgIHwgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgIHwKICAgfCAxMzEw NDA3MDAwNiB8IFRva3lvICAgICAgIHwgU2hpbmp1a3UgICAgIHwgTmlzaGktICAgfCA2LUNob21l ICAgICB8CiAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8IFNo aW5qdWt1IHwgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgIHwKICAgfCAxMzEwNDA3MDAwNyB8 IFRva3lvICAgICAgIHwgU2hpbmp1a3UgICAgIHwgTmlzaGktICAgfCA3LUNob21lICAgICB8CiAg IHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8IFNoaW5qdWt1IHwg ICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgfCAgICAgICAgICB8ICAgICAgICAgICAgIHwKICAgfCAxMzEwNDA3MDAwOCB8IFRva3lvICAg ICAgIHwgU2hpbmp1a3UgICAgIHwgTmlzaGktICAgfCA4LUNob21lICAgICB8CiAgIHwgICAgICAg ICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8IFNoaW5qdWt1IHwgICAgICAgICAg ICAgfAogICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLSsKCiAgICAgICAgICAgICAgICAgIFRhYmxlIDQ6IEV4YW1wbGU6 IGFkZHJlc3MgY29kZSBvZiBDaG9tZQoKICAgMDcwIGF0IDYtOCBkaWdpdCBpcyBhc3NpZ25lZCBm b3IgTmlzaGktU2hpbmp1a3UsIGFuZCAwMDEgdGhydSAwMDggYXQKICAgOS0xMSBkaWdpdCBhcmUg ZWFjaCAiQ2hvbWUiLgoKICAgKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0t LS0tLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0rCiAgIHwgY29kZSAgICAgICAgfCBQcmVmZWMg IHwgTXVuaWNpcGEgfCBTZWN0aW9uICB8IFN1YiAgICAgIHwgUG9zdGFsICAgfAogICB8ICAgICAg ICAgICAgIHwgdHVyZSAgICB8IGxpdHkgICAgIHwgICAgICAgICAgfCBzZWN0aW9uICB8IENvZGUg ICAgIHwKICAgKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLSst LS0tLS0tLS0tKy0tLS0tLS0tLS0rCiAgIHwgMTMxMDQwOTkwMDMgfCBUb2t5byAgIHwgU2hpbmp1 a3UgfCBUb3lhbWEgICB8IDMtQ2hvbWUgIHwgMTYyLTAwNTIgfAogICB8ICAgICAgICAgICAgIHwg ICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwKICAg fCAxMzEwNDA5OTg1MSB8IFRva3lvICAgfCBTaGluanVrdSB8IFRveWFtYSAgIHwgMy1DaG9tZSAg fCAxNjktMDA1MiB8CiAgICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tKy0tLS0t LS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tKwoKICAgICAgICAgIFRhYmxlIDU6IEV4YW1wbGU6 IGFkZHJlc3MgY29kZSBvZiBkaWZmZXJlbnQgcG9zdGFsIGNvZGUKCiAgIDMtQ2hvbWUsIFRveWFt YSwgU2hpbmp1a3UtV2FyZCwgVG9reW8gaXMgYXNzaWduZWQgbW9yZSB0aGFuIG9uZQogICBwb3N0 YWwgY29kZSBudW1iZXIuICBTbywgMTMxMDQwOTkwMDMgKDEzOiBUb2t5bywgMTA0OiBTaGluanVr dSwgMDk5OgoKCgpBcmFpICYgS2F3YW5pc2hpICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDE0LCAy MDA1ICAgICAgICAgICAgICBbUGFnZSAyMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBFbWVy Z2VuY3kgcmVxLnMgaW4gSmFwYW4gICAgICAgICAgICAgICAgTWF5IDIwMDUKCgogICBUb3lhbWEs IDAwMzogMy1DaG9tZSkgaXMgYXNzaWduZWQgYXMgdGhlIHByaW5jaXBhbCBjb2RlLCAxMzEwNDA5 OTg1MQogICBpcyBhcyB0aGUgc3VwcGxpbWVudGFyeSBjb2RlLgoKQXBwZW5kaXggQS40ICBBZGRp bmcgYW5kIERpc2NvbnRpbnVpbmcgQ29kZQoKQXBwZW5kaXggQS40LjEgIENhc2VzIG9mIGFkZGlu ZyBhbmQgZGlzY29udG51aW5nIGNvZGUKCiAgIG8gIHJlYWRqdXN0bWVudCBvZiB0aGUgZGl2aXRp b24gb2YgbGFuZAoKICAgbyAgZW5mb3JjZW1lbnQgb2YgdGhlIHdhcmQgc3lzdGVtCgogICBvICBl bmZvcmNlbWVudCBvZiB0aGUgY2l0eSBzeXN0ZW0KCiAgIG8gIG11bmljaXBhbCBtZXJnZXIKCiAg IG8gIHJlbnVtYmVyaW5nIG9mIGxvdHMsIGV0Yy4KCgpBcHBlbmRpeCBBLjQuMiAgQWRkaW5nIENv ZGUKCiAgIEEgbmV3IGFkZHJlc3MgY29kZSBpcyBhc3NpZ25lZCB0byB0aGUgbmV3IGFkZHJlc3Ms IHdoaWNoIGlzIGJyb3VnaHQKICAgYWRtaW5pc3RyYXRpdmVseS4gIEhvd2V2ZXIgbm8gbmV3IGNv ZGUgaXMgYXNzaWduZWQgaW4gdGhlIGZvbGxvd2luZwogICBjYXNlczsKCiAgIG8gIGNoYW5naW5n IG9ubHkgdGhlIG5hbWUgb2YgY2l0eSwgd2FyZCwgdG93biBvciB2aWxsYWdlCgogICBvICBzaGlm dGluZyB2aWxsYWdlIHRvIHRvd24KCiAgIG8gIGluIGNhc2Ugb2YgbXVuaWNpcGFsIG1lcmdlciwg YW5kIG9uZSBvZiB0aGVpciBuYW1lIGlzIHJldXNlZCBmb3IKICAgICAgdGhlIG1lcmdlZCBtdW5p Y2lwYWxpdHkKCgpBcHBlbmRpeCBBLjQuMyAgRGlzY29udGludWluZyBDb2RlCgogICBJbiBjYXNl IGEgYWRkcmVzcyB3YXMgYWJvbGlzaGVkLCB0aGUgY29ycmVzcG9uZGluZyBjb2RlIHRvIHRoZQog ICBhZGRyZXNzIHdvdWxkIHJlbWFpbiBidXQgbmV2ZXIgYmUgdXNlZC4KCjYuICBJbmZvcm1hdGl2 ZSBSZWZlcmVuY2VzCgogICBbSVNPIDMxNjYtMl0KICAgICAgICAgICAgICBJbnRlcm5hdGlvbmFs IE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiQ29kZXMgZm9yCiAgICAgICAgICAg ICAgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIGNvdW50cmllcyBhbmQgdGhlaXIKICAg ICAgICAgICAgICBzdWJkaXZpc2lvbnMgLS0gUGFydCAyOiBDb3VudHJ5IHN1YmRpdmlzaW9uIGNv ZGUiLCAxOTk4LgoKICAgW0pJUyBYIDA0MDFdCiAgICAgICAgICAgICAgSmFwYW4gSW5kdXN0cmlh bCBTdGFuZGFyZCwgIlRvLURvLUZ1LUtlbiAoUHJlZmVjdHVyZSkKICAgICAgICAgICAgICBJZGVu dGlmaWNhdGlvbiBDb2RlIiwgQXByaWwgMTk3My4KCgoKCkFyYWkgJiBLYXdhbmlzaGkgICAgICAg IEV4cGlyZXMgTm92ZW1iZXIgMTQsIDIwMDUgICAgICAgICAgICAgIFtQYWdlIDIyXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgIEVtZXJnZW5jeSByZXEucyBpbiBKYXBhbiAgICAgICAgICAgICAg ICBNYXkgMjAwNQoKCiAgIFtKSVMgWCAwNDAyXQogICAgICAgICAgICAgIEphcGFuIEluZHVzdHJp YWwgU3RhbmRhcmQsICJJZGVudGlmaWNhdGlvbiBjb2RlIGZvcgogICAgICAgICAgICAgIGNpdGll cywgdG93bnMgYW5kIHZpbGxhZ2VzIiwgRGVjZW1iZXIgMjAwMy4KCiAgIFtMQVNERUNdICAgTG9j YWwgQXV0aG9yaXRpZXMgU3lzdGVtcyBEZXZlbG9wbWVudCBDZW50ZXIsCiAgICAgICAgICAgICAg IkNoYXJhY3RlcmlzdGljcyBvZiBaZW5rb2t1IE1hY2hpLUF6YSBGaWxlIi4KCiAgIFtNSUMgZHJh ZnQgcmVwb3J0XQogICAgICAgICAgICAgIFRoZSBNaW5pc3RyeSBvZiBJbnRlcm5hbCBBZmZhaXJz IGFuZCBDb21tdW5pY2F0aW9ucywKICAgICAgICAgICAgICAiZHJhZnQgcmVwb3J0IGNvbmNlcm5p bmcgTWVhc3VyZXMgZm9yIFByZXNlcnZpbmcgSW1wb3J0YW50CiAgICAgICAgICAgICAgQ29tbXVu aWNhdGlvbnMgU3VjaCBhcyBFbWVyZ2VuY3kgTWVzc2FnZXMgb24gSVAgTmV0d29ya3MiLAogICAg ICAgICAgICAgIEphbnVhcnkgMjAwNS4KCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIEhpZGVraSBB cmFpCiAgIEF2YXlhIEphcGFuIEx0ZC4KICAgMi0xNy03IEFrYXNha2EKICAgTWluYXRvLWt1LCBU b2t5byAgMTA3LTAwNTIKICAgSmFwYW4KCiAgIEVtYWlsOiBhcmFpQGF2YXlhLmNvbQoKCiAgIE1v dG9oYXJ1IEthd2FuaXNoaQogICBPa2kgRWxlY3RyaWMgSW5kdXN0cnkgQ28uLCBMdGQuCiAgIDQt MTAtMTYgU2hpYmF1cmEKICAgTWluYXRvLWt1LCBUb2t5byAgMTA4LTg1NTEKICAgSmFwYW4KCiAg IEVtYWlsOiBrYXdhbmlzaGkzODFAb2tpLmNvbQoKCgoKCgoKCgoKCgoKCgoKCgoKQXJhaSAmIEth d2FuaXNoaSAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxNCwgMjAwNSAgICAgICAgICAgICAgW1Bh Z2UgMjNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgRW1lcmdlbmN5IHJlcS5zIGluIEphcGFu ICAgICAgICAgICAgICAgIE1heSAyMDA1CgoKSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVu dAoKICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBv ciBzY29wZSBvZiBhbnkKICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciBy aWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVu dGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4KICAgdGhpcyBkb2N1 bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRz CiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2Vu dCB0aGF0IGl0IGhhcwogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkg YW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCBy ZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQogICBmb3VuZCBpbiBCQ1Ag NzggYW5kIEJDUCA3OS4KCiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUg SUVURiBTZWNyZXRhcmlhdCBhbmQgYW55CiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUg bWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4KICAgYXR0ZW1wdCBtYWRlIHRvIG9i dGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mCiAgIHN1 Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzCiAg IHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIg cmVwb3NpdG9yeSBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4KCiAgIFRoZSBJRVRGIGlu dml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkK ICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBw cm9wcmlldGFyeQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBi ZSByZXF1aXJlZCB0byBpbXBsZW1lbnQKICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNz IHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdAogICBpZXRmLWlwckBpZXRmLm9yZy4KCgpE aXNjbGFpbWVyIG9mIFZhbGlkaXR5CgogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4KICAgIkFTIElTIiBiYXNpcyBh bmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTCiAg IE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRI RSBJTlRFUk5FVAogICBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5U SUVTLCBFWFBSRVNTIE9SIElNUExJRUQsCiAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8g QU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUKICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJ TEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQKICAgV0FSUkFOVElFUyBP RiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuCgoK Q29weXJpZ2h0IFN0YXRlbWVudAoKICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0 eSAoMjAwNSkuICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QKICAgdG8gdGhlIHJpZ2h0cywgbGlj ZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQKICAgZXhjZXB0 IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0 cy4KCgpBY2tub3dsZWRnbWVudAoKICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rp b24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQogICBJbnRlcm5ldCBTb2NpZXR5LgoKCgoK QXJhaSAmIEthd2FuaXNoaSAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxNCwgMjAwNSAgICAgICAg ICAgICAgW1BhZ2UgMjRdCgwKCg== --EGBSE.AT4G6UESMTE.MWEAMV4GBA Content-Type: application/octet-stream; name="draft-arai-ecrit-japan-req-01.html" Content-Disposition: attachment; filename="draft-arai-ecrit-japan-req-01.html" Content-Transfer-Encoding: base64 CjwhRE9DVFlQRSBIVE1MIFBVQkxJQyAiLS8vVzNDLy9EVEQgSFRNTCA0LjAxIFRyYW5zaXRpb25h bC8vRU4iICJodHRwOi8vd3d3LnczLm9yZy9UUi9odG1sNC9sb29zZS5kdGQiPgo8aHRtbCBsYW5n PSJlbiI+PGhlYWQ+PHRpdGxlPkVtZXJnZW5jeSBDYWxsIFJlcXVpcmVtZW50cyBmb3IgSVAgVGVs ZXBob255IFNlcnZpY2VzIEluIEphcGFuPC90aXRsZT4KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPgo8bWV0YSBuYW1lPSJk ZXNjcmlwdGlvbiIgY29udGVudD0iRW1lcmdlbmN5IENhbGwgUmVxdWlyZW1lbnRzIGZvciBJUCBU ZWxlcGhvbnkgU2VydmljZXMgSW4gSmFwYW4iPgo8bWV0YSBuYW1lPSJrZXl3b3JkcyIgY29udGVu dD0iSW50ZXJuZXQtRHJhZnQiPgo8bWV0YSBuYW1lPSJnZW5lcmF0b3IiIGNvbnRlbnQ9InhtbDJy ZmMgdjEuMjkgKGh0dHA6Ly94bWwucmVzb3VyY2Uub3JnLykiPgo8c3R5bGUgdHlwZT0ndGV4dC9j c3MnPgo8IS0tCiAgICBib2R5IHsKICAgICAgICBmb250LWZhbWlseTogdmVyZGFuYSwgY2hhcmNv YWwsIGhlbHZldGljYSwgYXJpYWwsIHNhbnMtc2VyaWY7CiAgICAgICAgbWFyZ2luOiAyZW07CiAg ICAgICAgZm9udC1zaXplOiBzbWFsbCA7IGNvbG9yOiAjMDAwMDAwIDsgYmFja2dyb3VuZC1jb2xv cjogI2ZmZmZmZiA7IH0KICAgIC50aXRsZSB7IGNvbG9yOiAjOTkwMDAwOyBmb250LXNpemU6IHgt bGFyZ2UgOwogICAgICAgIGZvbnQtd2VpZ2h0OiBib2xkOyB0ZXh0LWFsaWduOiByaWdodDsKICAg ICAgICBmb250LWZhbWlseTogaGVsdmV0aWNhLCBtb25hY28sICJNUyBTYW5zIFNlcmlmIiwgYXJp YWwsIHNhbnMtc2VyaWY7CiAgICAgICAgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IH0K ICAgIC5maWxlbmFtZSB7IGNvbG9yOiAjNjY2NjY2OyBmb250LXNpemU6IDE4cHg7IGxpbmUtaGVp Z2h0OiAyOHB4OwogICAgICAgIGZvbnQtd2VpZ2h0OiBib2xkOyB0ZXh0LWFsaWduOiByaWdodDsK ICAgICAgICBmb250LWZhbWlseTogaGVsdmV0aWNhLCBhcmlhbCwgc2Fucy1zZXJpZjsKICAgICAg ICBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgfQogICAgdGQucmZjYnVnIHsgYmFja2dy b3VuZC1jb2xvcjogIzAwMDAwMCA7IHdpZHRoOiAzMHB4IDsgaGVpZ2h0OiAzMHB4IDsKICAgICAg ICB0ZXh0LWFsaWduOiBqdXN0aWZ5OyB2ZXJ0aWNhbC1hbGlnbjogbWlkZGxlIDsgcGFkZGluZy10 b3A6IDJweCA7IH0KICAgIHRkLnJmY2J1ZyBzcGFuLlJGQyB7IGNvbG9yOiAjNjY2NjY2OyBmb250 LXdlaWdodDogYm9sZDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOwogICAgICAgIGJhY2tncm91bmQt Y29sb3I6ICMwMDAwMDAgOwogICAgICAgIGZvbnQtZmFtaWx5OiBtb25hY28sIGNoYXJjb2FsLCBn ZW5ldmEsICJNUyBTYW5zIFNlcmlmIiwgaGVsdmV0aWNhLCB2ZXJkYW5hLCBzYW5zLXNlcmlmOwog ICAgICAgIGZvbnQtc2l6ZTogeC1zbWFsbCA7IH0KICAgIHRkLnJmY2J1ZyBzcGFuLmhvdFRleHQg eyBjb2xvcjogI2ZmZmZmZjsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBu b25lOwogICAgICAgIHRleHQtYWxpZ246IGNlbnRlciA7CiAgICAgICAgZm9udC1mYW1pbHk6IGNo YXJjb2FsLCBtb25hY28sIGdlbmV2YSwgIk1TIFNhbnMgU2VyaWYiLCBoZWx2ZXRpY2EsIHZlcmRh bmEsIHNhbnMtc2VyaWY7CiAgICAgICAgZm9udC1zaXplOiB4LXNtYWxsIDsgYmFja2dyb3VuZC1j b2xvcjogIzAwMDAwMDsgfQovKiBpbmZvIGNvZGUgZnJvbSBTYW50YUtsYXVzcyBhdCBodHRwOi8v d3d3Lm1hZGFib3V0c3R5bGUuY29tL3Rvb2x0aXAyLmh0bWwgKi8KICAgIGRpdiNjb3VudGVye21h cmdpbi10b3A6IDEwMHB4fQoKICAgIGEuaW5mb3sKICAgICAgICBwb3NpdGlvbjpyZWxhdGl2ZTsg Lyp0aGlzIGlzIHRoZSBrZXkqLwogICAgICAgIHotaW5kZXg6MjQ7CiAgICAgICAgdGV4dC1kZWNv cmF0aW9uOm5vbmV9CgogICAgYS5pbmZvOmhvdmVye3otaW5kZXg6MjU7IGJhY2tncm91bmQtY29s b3I6Izk5MDAwMCA7IGNvbG9yOiAjZmZmZmZmIDt9CgogICAgYS5pbmZvIHNwYW57ZGlzcGxheTog bm9uZX0KCiAgICBhLmluZm86aG92ZXIgc3Bhbi5pbmZveyAvKnRoZSBzcGFuIHdpbGwgZGlzcGxh eSBqdXN0IG9uIDpob3ZlciBzdGF0ZSovCiAgICAgICAgZGlzcGxheTpibG9jazsKICAgICAgICBw b3NpdGlvbjphYnNvbHV0ZTsKICAgICAgICBmb250LXNpemU6IHNtYWxsZXIgOwogICAgICAgIHRv cDoyZW07IGxlZnQ6MmVtOyB3aWR0aDoxNWVtOwogICAgICAgIHBhZGRpbmc6IDJweCA7CiAgICAg ICAgYm9yZGVyOjFweCBzb2xpZCAjMzMzMzMzOwogICAgICAgIGJhY2tncm91bmQtY29sb3I6I2Vl ZWVlZTsgY29sb3I6Izk5MDAwMDsKICAgICAgICB0ZXh0LWFsaWduOiBsZWZ0IDt9CgogICAgIEEg eyBmb250LXdlaWdodDogYm9sZDsgfQogICAgIEE6bGluayB7IGNvbG9yOiAjOTkwMDAwOyBiYWNr Z3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudCA7IH0KICAgICBBOnZpc2l0ZWQgeyBjb2xvcjogIzMz MzMzMzsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQgOyB9CiAgICAgQTphY3RpdmUgeyBj b2xvcjogIzMzMzMzMzsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQgOyB9CgogICAgcCB7 IG1hcmdpbi1sZWZ0OiAyZW07IG1hcmdpbi1yaWdodDogMmVtOyB9CiAgICBwLmNvcHlyaWdodCB7 IGZvbnQtc2l6ZTogeC1zbWFsbCA7IH0KICAgIHAudG9jIHsgZm9udC1zaXplOiBzbWFsbCA7IGZv bnQtd2VpZ2h0OiBib2xkIDsgbWFyZ2luLWxlZnQ6IDNlbSA7fQoKICAgIHNwYW4uZW1waCB7IGZv bnQtc3R5bGU6IGl0YWxpYzsgfQogICAgc3Bhbi5zdHJvbmcgeyBmb250LXdlaWdodDogYm9sZDsg fQogICAgc3Bhbi52ZXJiLCBzcGFuLnZiYXJlIHsgZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyIs IENvdXJpZXIsIG1vbm9zcGFjZSA7IH0KCiAgICBzcGFuLnZlbXBoIHsgZm9udC1zdHlsZTogaXRh bGljOyBmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IiwgQ291cmllciwgbW9ub3NwYWNlIDsgfQog ICAgc3Bhbi52c3Ryb25nIHsgZm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtZmFtaWx5OiAiQ291cmll ciBOZXciLCBDb3VyaWVyLCBtb25vc3BhY2UgOyB9CiAgICBzcGFuLnZkZWx1eGUgeyBmb250LXdl aWdodDogYm9sZDsgZm9udC1zdHlsZTogaXRhbGljOyBmb250LWZhbWlseTogIkNvdXJpZXIgTmV3 IiwgQ291cmllciwgbW9ub3NwYWNlIDsgfQoKICAgIG9sLnRleHQgeyBtYXJnaW4tbGVmdDogMmVt OyBtYXJnaW4tcmlnaHQ6IDJlbTsgfQogICAgdWwudGV4dCB7IG1hcmdpbi1sZWZ0OiAyZW07IG1h cmdpbi1yaWdodDogMmVtOyB9CiAgICBsaSB7IG1hcmdpbi1sZWZ0OiAzZW07ICB9CgogICAgcHJl IHsgbWFyZ2luLWxlZnQ6IDNlbTsgY29sb3I6ICMzMzMzMzM7ICBiYWNrZ3JvdW5kLWNvbG9yOiB0 cmFuc3BhcmVudDsKICAgICAgICBmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IiwgQ291cmllciwg bW9ub3NwYWNlIDsgZm9udC1zaXplOiBzbWFsbCA7CiAgICAgICAgdGV4dC1hbGlnbjogbGVmdDsK ICAgICAgICB9CgogICAgaDMgeyBjb2xvcjogIzMzMzMzMzsgZm9udC1zaXplOiBtZWRpdW0gOwog ICAgICAgIGZvbnQtZmFtaWx5OiBoZWx2ZXRpY2EsIGFyaWFsLCBzYW5zLXNlcmlmIDsKICAgICAg ICBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgfQogICAgaDQgeyBmb250LXNpemU6IHNt YWxsOyBmb250LWZhbWlseTogaGVsdmV0aWNhLCBhcmlhbCwgc2Fucy1zZXJpZiA7IH0KCiAgICB0 YWJsZS5idWcgeyB3aWR0aDogMzBweCA7IGhlaWdodDogMTVweCA7IH0KICAgIHRkLmJ1ZyB7IGNv bG9yOiAjZmZmZmZmIDsgYmFja2dyb3VuZC1jb2xvcjogIzk5MDAwMCA7CiAgICAgICAgdGV4dC1h bGlnbjogY2VudGVyIDsgd2lkdGg6IDMwcHggOyBoZWlnaHQ6IDE1cHggOwogICAgICAgICB9CiAg ICB0ZC5idWcgQS5saW5rMiB7IGNvbG9yOiAjZmZmZmZmIDsgZm9udC13ZWlnaHQ6IGJvbGQ7CiAg ICAgICAgdGV4dC1kZWNvcmF0aW9uOiBub25lOwogICAgICAgIGZvbnQtZmFtaWx5OiBtb25hY28s IGNoYXJjb2FsLCBnZW5ldmEsICJNUyBTYW5zIFNlcmlmIiwgaGVsdmV0aWNhLCBzYW5zLXNlcmlm OwogICAgICAgIGZvbnQtc2l6ZTogeC1zbWFsbCA7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFy ZW50IH0KCiAgICB0ZC5oZWFkZXIgeyBjb2xvcjogI2ZmZmZmZjsgZm9udC1zaXplOiB4LXNtYWxs IDsKICAgICAgICBmb250LWZhbWlseTogYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsgdmVy dGljYWwtYWxpZ246IHRvcDsKICAgICAgICBiYWNrZ3JvdW5kLWNvbG9yOiAjNjY2NjY2IDsgd2lk dGg6IDMzJSA7IH0KICAgIHRkLmF1dGhvciB7IGZvbnQtd2VpZ2h0OiBib2xkOyBtYXJnaW4tbGVm dDogNGVtOyBmb250LXNpemU6IHgtc21hbGwgOyB9CiAgICB0ZC5hdXRob3ItdGV4dCB7IGZvbnQt c2l6ZTogeC1zbWFsbDsgfQogICAgdGFibGUuZGF0YSB7IHZlcnRpY2FsLWFsaWduOiB0b3AgOyBi b3JkZXItY29sbGFwc2U6IGNvbGxhcHNlIDsKICAgICAgICBib3JkZXItc3R5bGU6IHNvbGlkIHNv bGlkIHNvbGlkIHNvbGlkIDsKICAgICAgICBib3JkZXItY29sb3I6IGJsYWNrIGJsYWNrIGJsYWNr IGJsYWNrIDsKICAgICAgICBmb250LXNpemU6IHNtYWxsIDsgdGV4dC1hbGlnbjogY2VudGVyIDsg fQogICAgdGFibGUuZGF0YSB0aCB7IGZvbnQtd2VpZ2h0OiBib2xkIDsKICAgICAgICBib3JkZXIt c3R5bGU6IHNvbGlkIHNvbGlkIHNvbGlkIHNvbGlkIDsKICAgICAgICBib3JkZXItY29sb3I6IGJs YWNrIGJsYWNrIGJsYWNrIGJsYWNrIDsgfQogICAgdGFibGUuZGF0YSB0ZCB7CiAgICAgICAgYm9y ZGVyLXN0eWxlOiBzb2xpZCBzb2xpZCBzb2xpZCBzb2xpZCA7CiAgICAgICAgYm9yZGVyLWNvbG9y OiAjMzMzMzMzICMzMzMzMzMgIzMzMzMzMyAjMzMzMzMzIDsgfQoKICAgIGhyIHsgaGVpZ2h0OiAx cHggfQotLT4KPC9zdHlsZT4KPC9oZWFkPgo8Ym9keT4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iYnVnIiBhbGlnbj0icmlnaHQi Pjx0cj48dGQgY2xhc3M9ImJ1ZyI+PGEgaHJlZj0iI3RvYyIgY2xhc3M9ImxpbmsyIj4mbmJzcDtU T0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIHdp ZHRoPSI2NiUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj48dHI+ PHRkPjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIHdpZHRoPSIxMDAlIiBib3JkZXI9IjAiIGNlbGxw YWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMSI+Cjx0cj48dGQgY2xhc3M9ImhlYWRlciI+ZWNyaXQ8 L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5ILiBBcmFpPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJo ZWFkZXIiPkludGVybmV0LURyYWZ0PC90ZD48dGQgY2xhc3M9ImhlYWRlciI+QXZheWE8L3RkPjwv dHI+Cjx0cj48dGQgY2xhc3M9ImhlYWRlciI+RXhwaXJlczogTm92ZW1iZXIgMTQsIDIwMDU8L3Rk Pjx0ZCBjbGFzcz0iaGVhZGVyIj5NLiBLYXdhbmlzaGk8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9 ImhlYWRlciI+Jm5ic3A7PC90ZD48dGQgY2xhc3M9ImhlYWRlciI+T2tpPC90ZD48L3RyPgo8dHI+ PHRkIGNsYXNzPSJoZWFkZXIiPiZuYnNwOzwvdGQ+PHRkIGNsYXNzPSJoZWFkZXIiPk1heSAxMywg MjAwNTwvdGQ+PC90cj4KPC90YWJsZT48L3RkPjwvdHI+PC90YWJsZT4KPGRpdiBhbGlnbj0icmln aHQiPjxzcGFuIGNsYXNzPSJ0aXRsZSI+PGJyIC8+RW1lcmdlbmN5IENhbGwgUmVxdWlyZW1lbnRz IGZvciBJUCBUZWxlcGhvbnkgU2VydmljZXMgSW4gSmFwYW48L3NwYW4+PC9kaXY+CjxkaXYgYWxp Z249InJpZ2h0Ij48c3BhbiBjbGFzcz0idGl0bGUiPjxiciAvPmRyYWZ0LWFyYWktZWNyaXQtamFw YW4tcmVxLTAxLnR4dDwvc3Bhbj48L2Rpdj4KCjxoMz5TdGF0dXMgb2YgdGhpcyBNZW1vPC9oMz4K PHA+CkJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwKZWFjaCBhdXRob3IgcmVwcmVz ZW50cyB0aGF0IGFueSBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdo aWNoCmhlIG9yIHNoZSBpcyBhd2FyZSBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsCmFu ZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQs CmluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uJm5ic3A7NiBvZiBCQ1AmbmJzcDs3OS48L3A+Cjxw PgpJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBF bmdpbmVlcmluZwpUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcg Z3JvdXBzLgpOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2lu ZyBkb2N1bWVudHMgYXMKSW50ZXJuZXQtRHJhZnRzLjwvcD4KPHA+CkludGVybmV0LURyYWZ0cyBh cmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwphbmQg bWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRz IGF0IGFueSB0aW1lLgpJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMg YXMgcmVmZXJlbmNlIG1hdGVyaWFsIG9yIHRvIGNpdGUKdGhlbSBvdGhlciB0aGFuIGFzICZsZHF1 bzt3b3JrIGluIHByb2dyZXNzLiZyZHF1bzs8L3A+CjxwPgpUaGUgbGlzdCBvZiBjdXJyZW50IElu dGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQKPGEgaHJlZj0naHR0cDovL3d3dy5pZXRm Lm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Jz5odHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlk LWFic3RyYWN0cy50eHQ8L2E+LjwvcD4KPHA+ClRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNo YWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQKPGEgaHJlZj0naHR0cDovL3d3dy5p ZXRmLm9yZy9zaGFkb3cuaHRtbCc+aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbDwvYT4u PC9wPgo8cD4KVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBOb3ZlbWJlciAxNCwg MjAwNS48L3A+Cgo8aDM+Q29weXJpZ2h0IE5vdGljZTwvaDM+CjxwPgpDb3B5cmlnaHQgJmNvcHk7 IFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA1KS48L3A+Cgo8aDM+QWJzdHJhY3Q8L2gzPgoKPHA+ VGhpcyBtZW1vIGludHJvZHVjZXMgdGhlIHN0YXR1cyBvZiBzdHVkeSBpbiBKYXBhbiByZWdhcmRp bmcgdGhlIGNvbW11bmljYXRpb24gZm9yIGVtZXJnZW5jeSByZXBvcnRzIHVzaW5nIHB1YmxpYyBJ UCB0ZWxlcGhvbnkgc2VydmljZXMuICBGaXJzdCwgaXQgcHJvdmlkZXMgdGhlIGluZm9ybWF0aW9u IG9uIHRoZSBiYWNrZ3JvdW5kIGFuZCBoaXN0b3J5LCBhbmQgdGhlbiBpdCBzdW1tYXJpemVzIHRo ZSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50cyBmcm9tIHRoZSByZWxldmFudCBhdXRob3JpdGllcy4g CjwvcD48YSBuYW1lPSJ0b2MiPjwvYT48YnIgLz48aHIgLz4KPGgzPlRhYmxlIG9mIENvbnRlbnRz PC9oMz4KPHAgY2xhc3M9InRvYyI+CjxhIGhyZWY9IiNpbnRybyI+MS48L2E+Jm5ic3A7CkludHJv ZHVjdGlvbjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjaXAgdGVsZXBo b255Ij4xLjE8L2E+Jm5ic3A7CklQIHRlbGVwaG9ueSBzZXJ2aWNlcyBpbiBKYXBhbjxiciAvPgom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjY2FlbXMiPjEuMjwvYT4mbmJzcDsKQ29t bWl0dGVlIGZvciB0aGUgQWR2YW5jZW1lbnQgb2YgRW1lcmdlbmN5IE1lc3NhZ2UgU3lzdGVtcyAo Q0FFTVMpPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNtb2RlbCI+MS4z PC9hPiZuYnNwOwpBIGFzc3VtZWQgbmV0d29yayBtb2RlbDxiciAvPgo8YSBocmVmPSIjbnVtYmVy cyI+Mi48L2E+Jm5ic3A7CkVtZXJnZW5jeSBudW1iZXJzIGluIEphcGFuPGJyIC8+CjxhIGhyZWY9 IiNyZXF1aXJlbWVudHMiPjMuPC9hPiZuYnNwOwpJUCBUZWxlcGhvbnkgUmVxdWlyZW1lbnRzIGZv ciBFbWVyZ2VuY3kgTWVzc2FnZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJl Zj0iI3JvdXRpbmcgcmVxdWlyZW1lbnRzIj4zLjE8L2E+Jm5ic3A7CkdldHRpbmcgRW1lcmdlbmN5 IENhbGwgdG8gQ29ycmVjdCBFbWVyZ2VuY3kgQ2FsbCBSZWNlcHRpb24gT2ZmaWNlPGJyIC8+CiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNLZWVwaW5nIENvbm5lY3Rpb24iPjMuMjwv YT4mbmJzcDsKS2VlcGluZyBDb25uZWN0aW9uPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxhIGhyZWY9IiNDTEkiPjMuMzwvYT4mbmJzcDsKUHJlc2VudGluZyBhbmQgQWNxdWlyaW5nIENh bGxpbmcgTGluZSBJZGVudGlmaWNhdGlvbiwgYW5kIFByZXNlbnRpbmcgSVAgVGVsZWNvbW11bmlj YXRpb24gUHJvdmlkZXIgSWRlbnRpZmljYXRpb248YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PGEgaHJlZj0iI2dlbyBsb2NhaXRvbiI+My40PC9hPiZuYnNwOwpQcmVzZW50aW5nIGFuZCBB Y3F1aXJpbmcgR2VvZ3JhcGhpY2FsIExvY2F0aW9uIEluZm9ybWF0aW9uPGJyIC8+CjxhIGhyZWY9 IiNzZWN1cml0eSI+NC48L2E+Jm5ic3A7ClNlY3VyaXR5IENvbnNpZGVyYXRpb25zPGJyIC8+Cjxh IGhyZWY9IiNpYW5hIj41LjwvYT4mbmJzcDsKSUFOQSBDb25zaWRlcmF0aW9uczxiciAvPgo8YSBo cmVmPSIjYWRkcmVzcyBjb2RlIj5BLjwvYT4mbmJzcDsKSmFwYW5lc2UgQWRkcmVzcyBDb2RlIGZv ciBMb2NhdGlvbiBJbmZvcm1hdGlvbjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBo cmVmPSIjYS1jIHByZWYiPkEuMTwvYT4mbmJzcDsKUHJlZmVjdHVyZSBjb2RlPGJyIC8+CiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhLWMgbXVuaSI+QS4yPC9hPiZuYnNwOwpNdW5p Y2lwYWxpdHkgY29kZTxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8YSBocmVmPSIjcHJlZmVjdHVyZXMiPkEuMi4xPC9hPiZuYnNwOwpQcmVmZWN0 dXJlPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxhIGhyZWY9IiN3YXJkIj5BLjIuMjwvYT4mbmJzcDsKR292ZXJubWVudC1kZXNpZ25hdGVkIG1h am9yIGNpdGllcyBhbmQgd2FyZHM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3Mtd2FyZCI+QS4yLjM8L2E+Jm5ic3A7ClNwZWNp YWwtd2FyZHMgaW4gVG9reW88YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2NpdGllcyI+QS4yLjQ8L2E+Jm5ic3A7CkNpdGllczxi ciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBo cmVmPSIjdG93biI+QS4yLjU8L2E+Jm5ic3A7ClRvd25zIGFuZCBWaWxsYWdlczxiciAvPgombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYS1jIHNlYyI+QS4zPC9hPiZuYnNwOwpTZWN0 aW9uIGNvZGUgYW5kIFN1YnNlY3Rpb24gY29kZTxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8YSBocmVmPSIjYWRkLWRpc2MiPkEuNDwvYT4mbmJzcDsKQWRkaW5nIGFuZCBEaXNjb250aW51 aW5nIENvZGU8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PGEgaHJlZj0iI2Nhc2UtYWRkLWRpc2NvbiI+QS40LjE8L2E+Jm5ic3A7CkNhc2VzIG9m IGFkZGluZyBhbmQgZGlzY29udG51aW5nIGNvZGU8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FkZGNvZGUiPkEuNC4yPC9hPiZu YnNwOwpBZGRpbmcgQ29kZTxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjZGlzY2NvZGUiPkEuNC4zPC9hPiZuYnNwOwpEaXNjb250 aW51aW5nIENvZGU8YnIgLz4KPGEgaHJlZj0iI3JmYy5yZWZlcmVuY2VzMSI+Ni48L2E+Jm5ic3A7 CkluZm9ybWF0aXZlIFJlZmVyZW5jZXM8YnIgLz4KPGEgaHJlZj0iI3JmYy5hdXRob3JzIj4mIzE2 Nzs8L2E+Jm5ic3A7CkF1dGhvcnMnIEFkZHJlc3NlczxiciAvPgo8YSBocmVmPSIjcmZjLmNvcHly aWdodCI+JiMxNjc7PC9hPiZuYnNwOwpJbnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdo dCBTdGF0ZW1lbnRzPGJyIC8+CjwvcD4KPGJyIGNsZWFyPSJhbGwiIC8+Cgo8YSBuYW1lPSJpbnRy byI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0i MCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFz cz0iYnVnIj48YSBocmVmPSIjdG9jIiBjbGFzcz0ibGluazIiPiZuYnNwO1RPQyZuYnNwOzwvYT48 L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMSI+PC9hPjxoMz4xLiZuYnNw O0ludHJvZHVjdGlvbjwvaDM+Cgo8cD5QdWJsaWMgSVAgdGVsZXBob255IHNlcnZpY2VzIGluIEph cGFuIGJlY2FtZSBwb3B1bGFyIGJ5IHRoZSBhbGxvY2F0aW9uIG9mIHRoZSBleGNsdXNpdmUgSVAg cGhvbmUgbnVtYmVyIGJlZ3VuIGluIFNlcHRlbWJlciAyMDAyLiAgVGhlIElQIHRlbGVwaG9uZSBu dW1iZXIgaXMgYW4gZWxldmVuLWRpZ2l0IHRlbGVwaG9uZSBudW1iZXIgaW5jbHVkZXMgIjA1MCIg cHJlZml4IGZvbGxvd2VkIGJ5IHRoZSBjYXJyaWVyIElELiBDdXJyZW50bHkgbW9yZSB0aGFuIHNl dmVuIG1pbGxpb24gdXNlcnMgc3Vic2NyaWJlIHRoZSBJUCB0ZWxlcGhvbnkgc2VydmljZSwgYW5k IGZ1cnRoZXIgc3Vic2NyaXB0aW9uIGlzIGV4cGVjdGVkIGluIHRoZSBuZXh0IGZldyB5ZWFycy4g CgkgICAgCjwvcD4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMS4xIj48L2E+PGg0PjxhIG5hbWU9Imlw IHRlbGVwaG9ueSI+MS4xPC9hPiZuYnNwO0lQIHRlbGVwaG9ueSBzZXJ2aWNlcyBpbiBKYXBhbjwv aDQ+Cgo8cD5UaGVyZSBhcmUgdHdvIHR5cGVzIG9mIHB1YmxpYyBJUCB0ZWxlcGhvbnkgc2Vydmlj ZXMgaW4gSmFwYW4uIE9uZSBpcyB0aGUgJzA1MCcgc2VydmljZSBtZW50aW9uZWQgYWJvdmUsIGFu ZCBhbm90aGVyIGlzIHRoZSBJUCB0ZWxlcGhvbnkgc2VydmljZSB1c2luZyBzdGFuZGFyZCB0ZWxl cGhvbmUgbnVtYmVyIG9mICcwQUItSicuICBUaGUgbWluaXN0ZXJpYWwgb3JkaW5hbmNlIHJlcXVp cmVzIHNlcnZpY2UgcHJvdmlkZXJzIHRvIGFjaGlldmUgYSBjZXJ0YWluIGxldmVsIG9mIHJlcXVp cmVkIGNvbmRpdGlvbi4gCgkJCjwvcD4KPHA+VGhlIHJlcXVpcmVtZW50cyB0byB0aGUgJzBBQi1K JyBJUCB0ZWxlcGhvbnkgc2VydmljZSBhcmUgc3VtbWFyaXplZCBiZWxvdy4gCjwvcD4KPHA+CiAg ICAgICAgICAgICAgICAJPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+UHJvdmlkZXMgdm9pY2Ug cXVhbGl0eSBlcXVhbCB0byBQU1ROIHRlbGVwaG9uZQo8L2xpPgo8bGk+RW5hYmxlcyB0aGUgdXNl IG9mIHRoZSBlbWVyZ2VuY3kgY2FsbHMKPC9saT4KPGxpPkluc3RhbGxlZCBsb2NhdGlvbiBvZiB0 aGUgSVAgdGVsZXBob25lIGRldmljZSBpcyBmaXhlZCBhbmQgdGhlIGRldmljZXMgYXJlIG5vdCBw b3J0YWJsZQo8L2xpPgo8L3VsPjxwPgoJCQo8L3A+CjxwPk9uIHRoZSBvdGhlciBoYW5kLCB0aGUg SVAgdGVsZXBob255IHNlcnZpY2VzIHdpdGggMDUwIHByZWZpeCBhcmUgbm90IG5lY2Vzc2FyaWx5 IGJvdW5kIGJ5IHRoZXNlIGNvbmRpdGlvbnMuCQo8L3A+CjxwPlRoZXJlIGlzIGEgZ2VuZXJhbCBv cGluaW9uIHRoYXQgaXQgaXMgcHJlZmVyYWJsZSBmb3IgdGhlIGVtZXJnZW5jeSBjYWxscyB0byBi ZSBlbmFibGVkIGJvdGggb24gMDUwIElQIHRlbGVwaG9ueSBzZXJ2aWNlcyBvciBvbiAwQUItSiBJ UCB0ZWxlcGhvbnkgc2VydmljZXMgYXMgbG9uZyBhcyB0aGUgdXNlcnMgY29uc2lkZXIgdGhlc2Ug c2VydmljZXMgYXJlIGFsdGVybmF0aXZlcyB0byBQU1ROIHRlbGVwaG9uZS4gCQo8L3A+CjxhIG5h bWU9InJmYy5zZWN0aW9uLjEuMiI+PC9hPjxoND48YSBuYW1lPSJjYWVtcyI+MS4yPC9hPiZuYnNw O0NvbW1pdHRlZSBmb3IgdGhlIEFkdmFuY2VtZW50IG9mIEVtZXJnZW5jeSBNZXNzYWdlIFN5c3Rl bXMgKENBRU1TKTwvaDQ+Cgo8cD5JbiBOb3ZlbWJlciAyMDAzLCB0aGUgTWluaXN0ZXIgb2YgSW50 ZXJuYWwgQWZmYWlycyBhbmQgQ29tbXVuaWNhdGlvbnMgcmVxdWVzdGVkIHRoZSBNaW5pc3RyeSBv ZiBJbnRlcm5hbCBBZmZhaXJzIGFuZCBDb21tdW5pY2F0aW9ucyAoTUlDKSBmb3IgdGhlIGFkdmlj ZSBhYm91dCB0aGUgYWNoaWV2ZW1lbnQgb2YgdGhlIGVtZXJnZW5jeSBjYWxsIHdpdGggdGhlIElQ IHRlbGVwaG9ueSBzZXJ2aWNlcyBwcm9tcHQgYW5kIGVtcGhhdGljYWxseS4KPC9wPgo8cD5VcG9u IHRoaXMgcmVxdWVzdCwgTUlDIHNldCB1cCB0aGUgSVAgVGVsZXBob255IFdvcmtpbmcgR3JvdXAg dW5kZXIgdGhlIENvbW1pdHRlZSBmb3IgdGhlIEFkdmFuY2VtZW50IG9mIEVtZXJnZW5jeSBNZXNz YWdlIFN5c3RlbXMgKENBRU1TKSBmcm9tIE1hcmNoIDIwMDQgdG8gSmFudWFyeSAyMDA1IHRvIGRp c2N1c3MgdGhlIHJlcXVpcmVtZW50cyB0byB0aGUgZW1lcmdlbmN5IGNhbGwgc2VjdXJpbmcgaW4g dGhlIElQIG5ldHdvcmsuIFRoZSBzdHVkeSBncm91cCB3YXMgY29tcG9zZWQgb2YgdGhlIGVtZXJn ZW5jeSBjYWxsIGFjY2VwdGFuY2Ugb3JnYW5pemF0aW9uIChFQ0FPIGluIHRoaXMgZG9jdW1lbnQp LCB0aGUgcGVvcGxlIGZyb20gYWNhZGVtaWMgYmFja2dyb3VuZCwgdGhlIHRlbGVjb21tdW5pY2F0 aW9ucyBjYXJyaWVyLCB0aGUgSVAgdGVsZXBob255IGVxdWlwbWVudCBtYW51ZmFjdHVyZXIsIGFu ZCBzbyBmb3J0aC4gCjwvcD4KPHA+QXMgdGhlIHJlc3VsdCBvZiBzdHVkeSwgYSBkcmFmdCBwcm9w b3NhbCB0aGF0IGNvbnNpc3RzIG9mIHRoZSBhdXRob3JpdHkncyBzZXJ2aWNlIHJlcXVpcmVtZW50 cyBhbmQgdGhlIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRzIHdhcyBjb21waWxlZCBhbmQgdGhlIGRy YWZ0IGlzIGN1cnJlbnRseSB1bmRlciBwdWJsaWMgcmV2aWV3IDxhIGNsYXNzPSJpbmZvIiBocmVm PSIjTUlDIGRyYWZ0IHJlcG9ydCI+W01JQyBkcmFmdCByZXBvcnRdPHNwYW4+ICg8L3NwYW4+PHNw YW4gY2xhc3M9ImluZm8iPlRoZSBNaW5pc3RyeSBvZiBJbnRlcm5hbCBBZmZhaXJzIGFuZCBDb21t dW5pY2F0aW9ucywgJmxkcXVvO2RyYWZ0IHJlcG9ydCBjb25jZXJuaW5nIE1lYXN1cmVzIGZvciBQ cmVzZXJ2aW5nIEltcG9ydGFudCBDb21tdW5pY2F0aW9ucyBTdWNoIGFzIEVtZXJnZW5jeSBNZXNz YWdlcyBvbiBJUCBOZXR3b3JrcywmcmRxdW87IEphbnVhcnkmbmJzcDsyMDA1Ljwvc3Bhbj48c3Bh bj4pPC9zcGFuPjwvYT4uICBUaGUgZG9jdW1lbnQgaW4gSmFwYW5lc2UgaXMgYXZhaWxhYmxlIGZy b20gTUlDIGhvbWUgcGFnZS4gIEF0IHRoZSBlbmQgb2YgTWFyY2ggMjAwNSwgdGhlIGZpbmFsIHJl cG9ydCB0aGF0IGluY29ycG9yYXRlcyB0aGUgcHVibGljIGNvbW1lbnRzIHdpbGwgYmUgc3VibWl0 dGVkIHRvIHRoZSBtaW5pc3RlciBvZiBNSUMuCjwvcD4KPHA+VGhlIHB1cnBvc2Ugb2YgdGhpcyBy ZXBvcnQgaXMgZm9yIHBhcnRpZXMgY29uY2VybmVkIG9mIHRoZSB0ZWxlY29tbXVuaWNhdGlvbnMg Y2FycmllciwgdGhlIGVtZXJnZW5jeSBjYWxsIGFjY2VwdGFuY2Ugb3JnYW5pemF0aW9uLCB0aGUg SVAgdGVsZXBob25lIHRlcm1pbmFsIG1ha2VyLCBhbmQgc28gZm9ydGgsIHRvIGZpeCBhIGRldGFp bGVkIHNwZWNpZmljYXRpb24sIHRvIGFkdmFuY2UgdGhlIGludHJvZHVjdGlvbiwgYW5kIHRvIHVz ZSBpdCB3aWRlbHkuCjwvcD4KPHA+VGhpcyBtZW1vIHByb3ZpZGVzIGluZm9ybWF0aW9uIG9uIHRo ZSByZXF1aXJlbWVudHMgZm9yIHRoZSBlbWVyZ2VuY3kgY2FsbCBhY2NlcHRhbmNlIG9uIHRoZSBJ UCBuZXR3b3JrLCBiYXNlZCBvbiB0aGUgYWJvdmUtbWVudGlvbmVkIGRyYWZ0IHByb3Bvc2FsIHVu ZGVyIHRoZSBwdWJsaWMgcmV2aWV3LiAKPC9wPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xLjMiPjwv YT48aDQ+PGEgbmFtZT0ibW9kZWwiPjEuMzwvYT4mbmJzcDtBIGFzc3VtZWQgbmV0d29yayBtb2Rl bDwvaDQ+Cgo8cD5UaGUgZm9sbG93aW5nIHByZWNvbmRpdGlvbnMgd2VyZSBhc3N1bWVkIGZvciB0 aGUgQ0FFTVMgZGlzY3Vzc2lvbi4gCjwvcD4KPHA+SVAgVGVsZXBob255IE5ldHdvcms6CiAgICAg ICAgICAgICAgICAgICAgPC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+CjxwPlRoZXJlIHdp bGwgYmUgdHdvIHR5cGVzIG9mIG5ldHdvcmsgY29uZmlndXJhdGlvbgo8L3A+CjxwPkVDQU8gaXMg Y29ubmVjdGVkIHRvIElQIG5ldHdvcmsgdmlhIFBTVE4gdXNpbmcgZXhpc3RpbmcgZW1lcmdlbmN5 IGxpbmUKPC9wPgo8cD5FQ0FPIGlzIGNvbm5lY3RlZCBkaXJlY3RseSB0byBJUCB0ZWxlcGhvbnkg bmV0d29yayB2aWEgYSBuZXcgSVAgbGluZQo8L3A+CjwvYmxvY2txdW90ZT48cD4KICAgICAgICAg ICAgICAgIAo8L3A+CjxwPlR5cGVzIG9mIElQIHRlbGVwaG9ueSBzZXJ2aWNlczoKICAgICAgICAg ICAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij4KPHA+Rml4ZWQgSVAgdGVs ZXBob25lCjwvcD4KPHA+UG9ydGFibGUgSVAgdGVsZXBob25lCjwvcD4KPHA+SVAgdGVsZXBob25l IHdpdGggbW9iaWxlIGNhcGFiaWxpdHkKPC9wPgo8L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgICAg ICAgICAKPC9wPgo8YSBuYW1lPSJudW1iZXJzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1t YXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9ImJ1ZyIg YWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJidWciPjxhIGhyZWY9IiN0b2MiIGNsYXNzPSJs aW5rMiI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMu c2VjdGlvbi4yIj48L2E+PGgzPjIuJm5ic3A7RW1lcmdlbmN5IG51bWJlcnMgaW4gSmFwYW48L2gz PgoKPHA+VGhlcmUgYXJlIHRocmVlIGVtZXJnZW5jeSB0ZWxlcGhvbmUgbnVtYmVycyBpbiBKYXBh bi4gSXQgaXMgMTEwIChwb2xpY2UpLCAxMTggKEphcGFuIENvYXN0IEd1YXJkKSwgYW5kIDExOShm aXJlIHN0YXRpb24gYW5kIGFtYnVsYW5jZSkuCjwvcD4KPHA+V2hlbiBkaWFsaW5nIG9uZSBvZiB0 aGVzZSBudW1iZXJzLCB0aGUgZW1lcmdlbmN5IGNhbGwgaXMgZXN0YWJsaXNoZWQgdG93YXJkIHRo ZSBlbWVyZ2VuY3kgcmVjZXB0aW9uIGRlc2sgb2YgZWFjaCBvcmdhbml6YXRpb24gdGhhdCBjb3Zl cnMgdGhlIGFyZWEgd2hlcmUgdGhlIHJlcG9ydGVyIGlzIHByZXNlbnQuCkluIFBTVE4sIHRlbGVw aG9ueSBjYXJyaWVycyBoYXZlIGEgZGF0YWJhc2Ugd2l0aCBzdWJzY3JpYmVyJ3MgbmFtZSwgYWRk cmVzcywgYW5kIHRlbGVwaG9uZSBudW1iZXIsIGFuZCBlYWNoIGVtZXJnZW5jeSB0ZWxlcGhvbmUg bnVtYmVyIGlzIGNvbnZlcnRlZCB0byB0aGUgdGVsZXBob25lIG51bWJlciBvZiBlbWVyZ2VuY3kg cmVjZXB0aW9uIGRlc2sgb2YgZWFjaCBFQ0FPLiAKPC9wPgo8cD5FYWNoIEVDQU8gcGxhY2VzIGFu IGVtZXJnZW5jeSBjYWxsIHJlY2VwdGlvbiBkZXNrIGJhc2VkIG9uIHRoZSBkaXN0cmljdCBvZiB0 aGVpciBkZWZpbml0aW9uLiAgCjwvcD4KPHA+UG9saWNlICgxMTApOiA1MiBoZWFkIG9mZmljZXMK ICAgICAgICAgICAgICAgICAgPC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+CjxwPjEgaW4g ZWFjaCA0NyBwcmVmZWN0dXJlcywgZXhjZXB0IDIgaW4gVG9reW8gYW5kIDUgaW4gSG9ra2FpZG8K PC9wPgo8L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgICAgICAgICAKPC9wPgo8cD5KYXBhbiBDb2Fz dCBHdWFyZCAoMTE4KTogMTEganVyaXNkaWN0aW9ucwo8L3A+CjxwPkZpcmUgc3RhdGlvbiBhbmQg YW1idWxhbmNlICgxMTkpOiBTbGlnaHRseSBsZXNzIHRoYW4gOTAwIGRpc3RyaWN0cwogICAgICAg ICAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij4KPHA+RGVmaW5lZCBsb2Nh bGx5IGFsb25nIHdpdGggdGhlIGRpc3RyaWN0IG9mIGFib3V0IDMwMDAgbXVuaWNpcGFsaXRpZXMK PC9wPgo8L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJyZXF1 aXJlbWVudHMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBh ZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48 dGQgY2xhc3M9ImJ1ZyI+PGEgaHJlZj0iI3RvYyIgY2xhc3M9ImxpbmsyIj4mbmJzcDtUT0MmbmJz cDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjMiPjwvYT48aDM+ My4mbmJzcDtJUCBUZWxlcGhvbnkgUmVxdWlyZW1lbnRzIGZvciBFbWVyZ2VuY3kgTWVzc2FnZXM8 L2gzPgoKPHA+VGhpcyBzZWN0aW9uIHByb3ZpZGVzIGEgbGlzdCBvZiBoaWdobHkgaW1wb3J0YW50 IHJlcXVpcmVtZW50cyBpbiBzdXBwb3J0IG9mIHRoZSBlbWVyZ2VuY3kgbWVzc2FnZXMgd2l0aGlu IHRoZSBjb250ZXh0IG9mIElQIHRlbGVwaG9ueSBpbiBKYXBhbi4KPC9wPgo8cD4KICAgICAgICAg ICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPgo8ZHQ+TVVTVDE6IDwvZHQ+Cjxk ZD5FbWVyZ2VuY3kgY2FsbCBNVVNUIGJlIGdvdCB0byB0aGUgY29ycmVjdCBFbWVyZ2VuY3kgQ2Fs bCBSZWNlcHRpb24gT2ZmaWNlIChFQ1JPKSwgd2hpY2ggY292ZXJzIHdoZXJlIHRoZSByZXBvcnRl ciBpcyBwcmVzZW50Lgo8L2RkPgo8ZHQ+TVVTVDI6IDwvZHQ+CjxkZD5FbWVyZ2VuY3kgY2FsbCBN VVNUIGJlIHJlZGlyZWN0ZWQgdG8gYW4gYWx0ZXJuYXRpdmUgZmFjaWxpdHkgdGhhdCB0aGUgb3Jn YW5pemF0aW9uIGRlc2lnbmF0ZXMgYXMgYW4gYWx0ZXJuYXRpdmUgcmVjZXB0aW9uIG9mZmljZSwg aW4gY2FzZSB0aGUgb3JpZ2luYWwgRUNSTyBjb3VsZCBub3QgZG8gaXRzIGR1dHkgZHVlIHRvIGEg ZGlzYXN0ZXIgZXRjLgo8L2RkPgo8ZHQ+TVVTVDM6IDwvZHQ+CjxkZD5JbmZvcm1hdGlvbiBmb3Ig aWRlbnRpZnlpbmcgdGhlIG9wZXJhdG9yIHdobyBjYW4gcHJvdmlkZSB0aGUgcmVwb3J0ZXIncyBz dWJzY3JpcHRpb24gaW5mb3JtYXRpb24gTVVTVCBiZSBwcmVzZW50ZWQgdG8gRUNSTy4KPC9kZD4K PGR0Pk1VU1Q0OiA8L2R0Pgo8ZGQ+RW1lcmdlbmN5IGNhbGwgTVVTVCBOT1QgYmUgdGVybWluYXRl ZCB1bmxlc3MgRUNSTyB0ZXJtaW5hdGVkIGl0LCBldmVuIHRob3VnaCB0aGUgcmVwb3J0ZXIgaHVu ZyB1cC4gKEtlZXBpbmcgY29ubmVjdGlvbikKPC9kZD4KPGR0Pk1VU1Q1OiA8L2R0Pgo8ZGQ+UmVw b3J0ZXIncyB0ZXJtaW5hbCBNVVNUIGJlIHJ1bmcgdXAgZnJvbSBFQ1JPIGlmIEVDUk8gaW50ZWRz IHRvIHJlc3VtZSB0aGUgY29udmVyc2F0aW9uIHdpdGggdGhlIHJlcG9ydGVyIGR1cmluZyAia2Vl cGluZyBjb25uZWN0aW9uIiB3b3VsZCBiZSBhY3RpdmF0ZWQuIChSZXZlcnNpbmcgY2FsbCkKPC9k ZD4KPGR0Pk1VU1Q2OiA8L2R0Pgo8ZGQ+UmVwb3J0ZXIncyBjYWxsZXItSUQgTVVTVCBiZSBwcmVz ZW50ZWQgdG8gRUNSTyB1bmxlc3MgdGhlIHJlcG9ydGVyIGRpYWxzIHRoZSByZXN0cmljdGlvbiBj b2RlIGZvbGxvd2VkIHdpdGggIjExeCIgKDExMCwgMTE4IG9yIDExOSkuCjwvZGQ+CjxkdD5NVVNU NzogPC9kdD4KPGRkPkVDUk8gTVVTVCBiZSBhbGxvd2VkIHRvIGFjcXVpcmUgdGhlIGNhbGxlci1J RCBldmVuIHRob3VnaCB0aGUgcmVwb3J0ZXIgZGlhbGVkIHdpdGggdGhlIHJlc3RyaWN0aW9uIGNv ZGUuCjwvZGQ+CjxkdD5NVVNUODogPC9kdD4KPGRkPkdlb2dyYXBoaWNhbCBMb2NhdGlvbiBJbmZv cm1hdGlvbiAoR0xJKSB0aGF0IHRoZSByZXBvcnRlciBpcyBwcmVzZW50IE1VU1QgYmUgcHJlc2Vu dGVkIHRvIEVDUk8uCjwvZGQ+CjxkdD5NVVNUOTogPC9kdD4KPGRkPkdMSSBNVVNUIGNvbnNpc3Qg b2YKICAgICAgICAgICAgICAgICAgICAgICAgCjx1bCBjbGFzcz0idGV4dCI+CjxsaT5GaXhlZCBJ UC1waG9uZTogc3Vic2NyaWJlcidzIG5hbWUsIGFkZHJlc3MsIGFkZHJlc3MgY29kZSBhbmQgdGVs ZXBob25lIG51bWJlcgo8L2xpPgo8bGk+UG9ydGFibGUvTW9iaWxlIElQLXBob25lOiBzdWJzY3Jp YmVyJ3MgbmFtZSwgcGxhY2Ugb2YgZGlzcGF0Y2ggaW5mb3JtYXRpb24sIHRlbGVwaG9uZSBudW1i ZXIsIGFuZCBtb2JpbGUtdXNlIG9yIG5vdAo8L2xpPgo8L3VsPjxwPgogICAgICAgICAgICAgICAg ICAgIAo8L2RkPgo8ZHQ+TVVTVDEwOiA8L2R0Pgo8ZGQ+RW1lcmdlbmN5IGNhbGwgTVVTVCBoYXZl IHByaW9yaXR5IG92ZXIgYWxsIG90aGVyIGNhbGxzIGluIGFueSBjYXNlLgo8L2RkPgo8ZHQ+TVVT VDExOiA8L2R0Pgo8ZGQ+T3BlcmF0b3IgTVVTVCBwcmV2ZW50IGEgbWFsaWNpb3VzIGNhbGwgcHJl dGVuZGluZyB0aGUgcGxhY2Ugb2YgZGlzcGF0Y2guCjwvZGQ+CjwvYmxvY2txdW90ZT48cD4KICAg ICAgICAgICAgCjwvcD4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMy4xIj48L2E+PGg0PjxhIG5hbWU9 InJvdXRpbmcgcmVxdWlyZW1lbnRzIj4zLjE8L2E+Jm5ic3A7R2V0dGluZyBFbWVyZ2VuY3kgQ2Fs bCB0byBDb3JyZWN0IEVtZXJnZW5jeSBDYWxsIFJlY2VwdGlvbiBPZmZpY2U8L2g0PgoKPHA+QXMg bWVudGlvbmVkIGluIHNlY3Rpb24gMiwgdGhlIGVtZXJnZW5jeSBjYWxsIHRoYXQgd2lsbCBiZSBk aWFsZWQgMTEwLCAxMTggYW5kIDExOSBtdXN0IGJlIGdvdCB0byB0aGUgY29ycmVjdCBlbWVyZ2Vu Y3kgY2FsbCByZWNlcHRpb24gb2ZmaWNlIChFQ1JPKSwgd2hpY2ggdGFrZXMgY2hhcmdlIG9mIHBs YWNlIHdoZXJlIHRoZSBjYWxsIHdvdWxkIGJlIHNlbnQsIGJ5IGxvY2F0aW9uLWJhc2VkIGNhbGwg cm91dGluZy4gIFRoaXMgcmVxdWlyZW1lbnQgbXVzdCBiZSBtZXQgSVAgdGVsZXBob255IGVtZXJn ZW5jeSBjYWxsIHNlcnZpY2UsIGluIGNhc2Ugb2Ygbm90IG9ubHkgZml4ZWQtdXNlIElQIHRlbGVw aG9uZXMsIGJ1dCBhbHNvIHBvcnRhYmxlIElQIHRlbGVwaG9uZXMgZm9yIGZpeGVkLXVzZSBhbmQg bW9iaWxlIElQIHRlbGVwaG9uZXMuCjwvcD4KPHA+SW4gdGhpcyBjYXNlLCBjYWxsIGNvbnRyb2wg bm9kZXMgc2hvdWxkIGlkZW50aWZ5IGVtZXJnZW5jeSBjYWxscyBpbiBvcmRlciB0byBlc3RhYmxp c2ggYSBjYWxsIGV2ZW4gdW5kZXIgbmV0d29yayBjb25nZXN0aW9uLiBTb21lIG5ldHdvcmtzIHVz ZSBhbHRlcm5hdGl2ZSB0ZWxlcGhvbmUgbnVtYmVyIG90aGVyIHRoYW4gZW1lcmdlbmN5IG51bWJl ciBvZiAxMTAvMTE4LzExOSBmb3Igcm91dGluZyBwdXJwb3NlLCBhbmQgdGhlcmVmb3JlIHRoZSBl bWVyZ2VuY3kgY2FsbHMgc2hvdWxkIGJlIGlkZW50aWZpZWQgYnkgYW4gaWRlbnRpZmllciBvdGhl ciB0aGFuIGRpYWxlZCBudW1iZXIuIAo8L3A+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjMuMiI+PC9h PjxoND48YSBuYW1lPSJLZWVwaW5nIENvbm5lY3Rpb24iPjMuMjwvYT4mbmJzcDtLZWVwaW5nIENv bm5lY3Rpb248L2g0PgoKPHA+VGhpcyByZXF1aXJlbWVudCBpcyBmb3IgYWxsb3dpbmcgdGhlIEVD Uk8gdG8gc2VjdXJlIHRoZSB0aW1lIG9yIHRoZSBjaGFuY2Ugb2YgdGhlIGNvbnZlcnNhdGlvbiB3 aXRoIHRoZSByZXBvcnRlciBpZiBuZWNlc3NhcnkuCjwvcD4KPHA+SVAgdGVsZWNvbW11bmljYXRp b24gcHJvdmlkZXJzIGFyZSByZXF1aXJlZCB0byBwcm92aWRlIHRoZSAia2VlcGluZyBjb25uZWN0 aW9uIiBmdW5jdGlvbmFsaXR5IHRoYXQga2VlcHMgdGhlIGNhbGwgdW5sZXNzIHRoZSBFQ1JPIHdv dWxkIHRlcm1pbmF0ZSB0aGUgY2FsbCwgZXZlbiB0aG91Z2ggdGhlIHJlcG9ydGVyIHdvdWxkIGhh bmcgdXAuICBBbmQgdGhlIHByb3ZpZGVycyBhcmUgYWxzbyByZXF1aXJlZCB0byBwcm92aWRlIHRo ZSAicmV2ZXJzaW5nIGNhbGwiIGZ1bmN0aW9uYWxpdHkgdGhhdCByaW5ncyB0aGUgcmVwb3J0ZXIn cyB0ZXJtaW5hbCB1cCBieSBvcGVyYXRpbmcgdGhlIGluc3RydWN0aW9uIGJvYXJkIGluIHRoZSBF Q1JPLCBpZiB0aGUgRUNSTyBpbnRlbmRzIHRvIHJlc3VtZSB0aGUgY29udmVyc2F0aW9uIHdpdGgg dGhlIHJlcG9ydGVyIHdoaWxlIHRoZSBlbWVyZ2VuY3kgY2FsbCBpcyBrZXB0IGJ5IHRoZSAia2Vl cGluZyBjb25uZWN0aW9uIiBmdW5jdGlvbmFsaXR5Lgo8L3A+CjxwPkZvciBpbnN0YW5jZSwgaXQg c2hvdWxkIGJlIGFjaGlldmVkIGJ5IGltcGxlbWVudGluZyBlaXRoZXIgb2YgdGggZSBmb2xsb3dp bmcgZnVuY3Rpb25hbGl0aWVzOgogICAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0 ZXh0Ij4KPHA+VGhlIGNvbm5lY3Rpb24gYmV0d2VlbiB0aGUgcmVwb3J0ZXIgYW5kIHRoZSBFQ1JP LCB3aGljaCByZWNlaXZlZCB0aGUgZW1lcmdlbmN5IGNhbGwgZnJvbSB0aGUgcmVwb3J0ZXIsIGlz IGVzdGFibGlzaGVkIHJlZ2FyZGxlc3Mgb2YgdGhlIHJlcG9ydGVyJ3MgaW50ZW50aW9uIGV2ZW4g aWYgdGhlIHJlcG9ydGVyIGxpZnRzIHRoZSByZWNlaXZlciB0cnlpbmcgdG8gY2FsbCBzb21ld2hl cmUgYWZ0ZXIgdGhlIHJlcG9ydGVyIGh1bmcgdXAgdGhlIGVtZXJnZW5jeSBjYWxsLgo8L3A+Cjxw PlRoZSByZXBvcnRlcidzIHByZXNlbnQgY2FsbCBpcyB0ZXJtaW5hdGVkIG9yIHN1c3BlbmRlZCBh bmQgdGhlbiBhbm90aGVyIG5ldyBjYWxsIGJldHdlZW4gdGhlIHJlcG9ydGVyIGFuZCB0aGUgRUNS TyBpcyBlc3RhYmxpc2hlZCBldmVuIGlmIHRoZSBFQ1JPIGNhbGxzIHRoZSByZXBvcnRlciB1cCB3 aGlsZSB0aGUgcmVwb3J0ZXIgaXMgdGFsa2luZyBvdmVyIGEgbmV3IGNhbGwgYWZ0ZXIgdGhlIHJl cG9ydGVyIGh1bmcgdXAgdGhlIGVtZXJnZW5jeSBjYWxsLgo8L3A+CjwvYmxvY2txdW90ZT4KCjxh IG5hbWU9InJmYy5zZWN0aW9uLjMuMyI+PC9hPjxoND48YSBuYW1lPSJDTEkiPjMuMzwvYT4mbmJz cDtQcmVzZW50aW5nIGFuZCBBY3F1aXJpbmcgQ2FsbGluZyBMaW5lIElkZW50aWZpY2F0aW9uLCBh bmQgUHJlc2VudGluZyBJUCBUZWxlY29tbXVuaWNhdGlvbiBQcm92aWRlciBJZGVudGlmaWNhdGlv bjwvaDQ+Cgo8cD5UaGVzZSBmdW5jdGlvbmFsaXRpZXMsIENhbGxpbmcgTGluZSBJZGVudGlmaWNh dGlvbiBQcmVzZW50YXRpb24gYW5kIEFjcXVpc2l0aW9uLCBhbmQgSVAgVGVsZWNvbW11bmljYXRp b24gUHJvdmlkZXIgSWRlbnRpZmljYXRpb24gUHJlc2VudGF0aW9uLCBhcmUgdXNlZCBmb3IgY2Fs bGluZyB0aGUgcmVwb3J0ZXIgYmFjayBmcm9tIHRoZSBFQ1JPIHRoYXQgcmVjZWl2ZWQgdGhlIGVt ZXJnZW5jeSBjYWxsLCBpZiB0aGUgRUNSTyBpbnRlbmRzIHRvIHJlc3VtZSB0aGUgY29udmVyc2F0 aW9uIHdpdGggdGhlIHJlcG9ydGVyIGFmdGVyIHRoZSBjYWxsIGVuZHMuCjwvcD4KPHA+SW4gZ2Vu ZXJhbCwgSVAgdGVsZWNvbW11bmljYXRpb24gcHJvdmlkZXJzIGluIEphcGFuIHByb3ZpZGUgQ2Fs bGluZyBMaW5lIElkZW50aWZpY2F0aW9uIFByZXNlbnRhdGlvbiBhbmQgUmVzdHJpY3Rpb24gKENM SVAgYW5kIENMSVIpIHNlcnZpY2U7IHRoZSBzZWxlY3Rpb24gb2Ygd2hldGhlciB0aGUgaWRlbnRp ZmljYXRpb24gaXMgcHJlc2VudGVkIGlzIGVpdGhlciBieSB0aGUgc3Vic2NyaXB0aW9uIGNvbnRy YWN0IG9yIGJ5IHNwZWNpZnlpbmcgdGhlIHNlcnZpY2UgbnVtYmVyICh3aGljaCBpcyAxODQgb3Ig MTg2KSBiZWZvcmUgdGhlIHRlbGVwaG9uZSBudW1iZXIgeW91IHdvdWxkIGRpYWwuICBUaGUgbGF0 dGVyIGhhcyBwcmVjZWRlbmNlIG92ZXIgdGhlIGZvcm1lci4gIFRoYXQgaXMsIGlmIHlvdSBzcGVj aWZ5IHRoZSBzZXJ2aWNlIG51bWJlciBmb3IgQ0xJUiBiZWZvcmUgdGhlIHRlbGVwaG9uZSBudW1i ZXIgeW91IGRpYWwsIHRoZSByZXBvcnRlcidzIHRlbGVwaG9uZSBudW1iZXIgd29uJ3QgYmUgZGlz cGxheWVkIG9uIHRoZSBjYWxsZWQgc2l0ZSBldmVuIHRob3VnaCB0aGUgcmVwb3J0ZXIgc3Vic2Ny aWJlcyBhcyBDTElQLiAgT24gdGhlIG90aGVyIGhhbmQsIGlmIHlvdSBzcGVjaWZ5IENMSVAsIHRo ZSByZXBvcnRlcidzIHRlbGVwaG9uZSBudW1iZXIgd2lsbCBiZSBkaXNwbGF5ZWQgZXZlbiB0aG91 Z2ggdGhlIHJlcG9ydGVyIHN1YnNjcmliZXMgYXMgQ0xJUi4KPC9wPgo8cD5Gb3IgdGhlIGVtZXJn ZW5jeSBjYWxsLCB0aGUgcmVwb3J0ZXIncyB0ZWxlcGhvbmUgbnVtYmVyIG11c3QgYmUgcHJlc2Vu dGVkIHRvIHRoZSBFQ1JPIHJlZ2FyZGxlc3Mgb2YgdGhlIHN1YnNjcmlwdGlvbiBvZiB0aGUgcmVw b3J0ZXIsIHVubGVzcyB0aGUgcmVwb3J0ZXIgc3BlY2lmaWVzIENMSVIgZXhwbGljaXRseS4KCjwv cD4KPHA+RnVydGhlcm1vcmUsIGV2ZW4gaWYgdGhlIHJlcG9ydGVyIHNwZWNpZmllcyBDTElSLCB0 aGUgRUNSTyBtdXN0IGJlIGFibGUgdG8gYWNxdWlyZSB0aGUgcmVwb3J0ZXIncyB0ZWxlcGhvbmUg bnVtYmVyIG92ZXIgdGhlIGNhbGwgb3IgdGhlICJrZWVwaW5nIGNvbm5lY3Rpb24iIGNvbmRpdGlv bi4gIEJlY2F1c2UsIGZvciBleGFtcGxlLCBpbiBjYXNlIHRoZSByZXBvcnRlciBmYWNlcyBhIGNy aXNpcyB0aGF0IGlzIGEgbWF0dGVyIG9mIGxpZmUgYW5kIGRlYXRoLCBldmVuIGlmIHRoZSByZXBv cnRlciBkb2Vzbid0IHdhbnQgdG8gcHJlc2VudCBoaXMvaGVyIHRlbGVwaG9uZSBudW1iZXIgdG8g dGhlIEVDUk8sIHRoZSBFQ1JPIGhhcyB0byBrbm93IHRoZSByZXBvcnRlcidzIHRlbGVwaG9uZSBu dW1iZXIgaW4gb3JkZXIgdG8gc2V0dGxlIHRoZSBjaXJjdW1zdGFuY2UuICBUaGlzIG9wZXJhdGlv biBjb25mb3JtcyB0byAiVGhlIEd1aWRlbGluZXMgb24gdGhlIFByb3RlY3Rpb24gb2YgUGVyc29u YWwgSW5mb3JtYXRpb24gaW4gdGhlIFRlbGVjb21tdW5pY2F0aW9ucyBCdXNpbmVzcyIgKE1JQyBB bm5vdW5jZW1lbnQgTm8uIDY5NSBvZiAyMDA0KS4KPC9wPgo8cD5BbHNvIGl0IGlzIG5lY2Vzc2Fy eSBmb3IgdGhlIEVDUk8gdG8gaWRlbnRpZnkgcGVyIGNhbGwgdGhlIElQIHRlbGVjb21tdW5pY2F0 aW9uIHByb3ZpZGVyIHRvIHdoaWNoIHRoZSByZXBvcnRlciBzdWJzY3JpYmVzLiAgVGhpcyBmdW5j dGlvbmFsaXR5IGFsbG93cyB0aGUgRUNSTyB0aGF0IHJlY2VpdmVzIHRoZSBlbWVyZ2VuY3kgY2Fs bCB0byBpbnF1aXJlIHN1YnNjcmliZXIgaW5mb3JtYXRpb24gZm9yIHRoZSBJUCB0ZWxlY29tbXVu aWNhdGlvbiBwcm92aWRlciBldmVuIGlmIHRoZSBFQ1JPIGNvdWxkbid0IGFjcXVpcmUgcmVwb3J0 ZXIncyBpbmZvcm1hdGlvbiBvbiB0aGUgdGVsZXBob25lIG51bWJlciBvciB0aGUgZ2VvZ3JhcGhp Y2FsIGxvY2F0aW9uIGV0Yy4KPC9wPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4zLjQiPjwvYT48aDQ+ PGEgbmFtZT0iZ2VvIGxvY2FpdG9uIj4zLjQ8L2E+Jm5ic3A7UHJlc2VudGluZyBhbmQgQWNxdWly aW5nIEdlb2dyYXBoaWNhbCBMb2NhdGlvbiBJbmZvcm1hdGlvbjwvaDQ+Cgo8cD5HZW9ncmFwaGlj YWwgbG9jYXRpb24gaW5mb3JtYXRpb24gb2YgdGhlIHJlcG9ydGVyIG11c3QgYmUgcHJlc2VudGVk IHRvIHRoZSBFQ1JPIHRoYXQgcmVjZWl2ZXMgdGhlIGNhbGwgd2hlbiB0aGUgRUNSTyByZWNlaXZl cyB0aGUgY2FsbCBhbmQgdGhlIEVDUk8gZGVtYW5kcyBpbmZvcm1hdGlvbiBmcm9tIHRoZSBJUCB0 ZWxlY29tbXVuaWNhdGlvbiBwcm92aWRlci4KCjwvcD4KPHA+VG8gY29uc2lkZXIgYXBwbHlpbmcg dGhlIGV4aXN0aW5nIGdlb2dyYXBoaWNhbCBsb2NhdGlvbiBpbmZvcm1hdGlvbiBzeXN0ZW0sIHRo ZXJlIGFyZSB0d28gY29uZmlndXJhdGlvbnM7IG9uZSBpcyB0aGF0IHR3byBjb25uZWN0aW9ucyBh cmUgdXNlZCBmb3Igdm9pY2UgYW5kIHRoZSBnZW9ncmFwaGljYWwgbG9jYXRpb24gc3lzdGVtIGlu ZGl2aWR1YWxseSwgYW5kIHRoZSBvdGhlciBwcm92aWRlcyBvbmUgY29ubmVjdGlvbiBmb3IgdGhl bS4KCjwvcD4KPHA+SFRUUCAoSHlwZXIgVGV4dCBUcmFuc2ZlciBQcm90b2NvbCkgaXMgdXNlZCBm b3IgdHJhbnNmZXJyaW5nIEdlb2dyYXBoaWNhbCBsb2NhdGlvbiBpbmZvcm1hdGlvbiB0aGF0IGlz IGZvcm1hdHRlZCBieSBYTUwgKGVYdGVuc2libGUgTWFya3VwIExhbmd1YWdlKS4KCjwvcD4KPHA+ VGhlIGNvbnRlbnQgb2YgdGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uIG11c3QgYmUgYWNjdXJhdGUg c28gdGhhdCB0aGUgZmlyZSBkZXBhcnRtZW50LCB0aGUgcG9saWNlIGRlcGFydG1lbnQgZXRjLiBt YXkgZGVhbCB3aXRoIHRoZSBwcm9ibGVtIHByb21wdGx5LgoKPC9wPgo8cD5UaGUgZm9sbG93aW5n IHNob3dzIHRoZSBjb250ZW50cyBvZiB0aGUgbG9jYXRpb24gaW5mb3JtYXRpb24uCgk8YnIgLz48 aHIgLz4KPGEgbmFtZT0iZml4ZWQtdGVsZXBob25lIj48L2E+CjwvcD4KPHByZT4KCmVsZW1lbnQg ICAgICAgICAgIHRhZyAgICAgICAgICByZW1hcmtzCi0tLS0tLS0tLS0tLS0tLSAgIC0tLS0tLS0t LS0tICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpDYWxsZXIgSUQgICAgICAg ICByZXBvX3RlbGUgICAgcmVwb3J0ZXIncyB0ZWxlcGhvbmUgbnVtYmVyCgpBcmVhIG9mIGFkZHJl c3MgICBhZGRfYXJlYSAgICAgYXJlYSBvZiByZXBvcnRlcidzIGFkZHJlc3MKICBaaXAgY29kZSAg ICAgICAgYWRkX3Bvc3QgICAgIHBvc3RhbCBjb2RlIG51bWJlcgogIEFkZHJlc3MgY29kZSAgICBh ZGRfY29kZSAgICAgSklTKEphcGFuZXNlIEluZHVzdHJpYWwgU3RhbmRhcmQpCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBhZGRyZXNzIGNvZGUKICBBZGRyZXNzIG5hbWUgICAgYWRkX25h bWUgICAgIGxpdGVyYWwgaW5mb3JtYXRpb24gY29ycmVzcG9uZGluZwogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdG8gYWRkcmVzcyBjb2RlIChuYW1lIG9mIHByZWZlY3R1cmUsCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBjaXR5IG9yIGNvdW50eSwgZXRjLikKICBBZGRyZXNz IG51bWJlciAgYWRkX251bSAgICAgIGhvdXNlIG51bWJlciwgc3RyZWV0IG51bWJlciBldGMuCiAg T3RoZXJzICAgICAgICAgIGFkZF9vdGhlcnMgICBob3VzZSBuYW1lLCBidWlsZGluZyBudW1iZXIs IHJvb20KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG51bWJlciwgb3IgYnVpbGRpbmcg bmFtZSBhbmQgZmxvb3IKCkFyZWEgb2YgICAgICAgICAgIG5hbWVfYXJlYSAgICBhcmVhIG9mIHJl cG9ydGVyJ3MgbmFtZQpyZXBvcnRlcidzIG5hbWUKICBOYW1lIGluIGthbmEgICAgbmFtZV9rYW5h ICAgIHByb251bmNpYXRpb24gb2YgcmVwb3J0ZXIncyBuYW1lCiAgTmFtZSBpbiBrYW5qaSAgIG5h bWVfa2FuamkgICByZXBvcnRlcidzIG5hbWUgaW4ga2FuamkgbGV0dGVycwotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgo8 L3ByZT4KPHA+Cjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0i MiIgYWxpZ249ImNlbnRlciI+PHRyPjx0ZCBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJtb25h Y28sIE1TIFNhbnMgU2VyaWYiIHNpemU9IjEiPjxiPiZuYnNwO0ZpZ3VyZSZuYnNwOzE6IFRoZSBs b2NhdGlvbiBpbmZvcm1hdGlvbiBmb3IgdGhlIGZpeGVkIElQIHRlbGVwaG9uZSZuYnNwOzwvYj48 L2ZvbnQ+PGJyIC8+PC90ZD48L3RyPjwvdGFibGU+PGhyIHNpemU9IjEiIHNoYWRlPSIwIj4KCiAg ICAgICAgICAgIAo8L3A+CjxwPgoJPGJyIC8+PGhyIC8+CjxhIG5hbWU9InBvcnRhYmxlLXRlbGVw aG9uZSI+PC9hPgo8L3A+CjxwcmU+CgplbGVtZW50ICAgICAgICAgICB0YWcgICAgICAgICAgcmVt YXJrcwotLS0tLS0tLS0tLS0tLS0gICAtLS0tLS0tLS0tLSAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCkNhbGxlciBJRCAgICAgICAgIHJlcG9fdGVsZSAgICByZXBvcnRlcidz IHRlbGVwaG9uZSBudW1iZXIKCkFyZWEgb2YgbG9jYXRpb24gIGxvY19hcmVhICAgICBhcmVhIG9m IHJlcG9ydGVyJ3MgZ2VvZ3JhcGhpY2FsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBs b2NhdGlvbiBpbmZvcm1hdGlvbgogIFppcCBjb2RlICAgICAgICBsb2NfcG9zdCAgICAgcG9zdGFs IGNvZGUgbnVtYmVyCiAgQWRkcmVzcyBjb2RlICAgIGxvY19jb2RlICAgICBKSVMoSmFwYW5lc2Ug SW5kdXN0cmlhbCBTdGFuZGFyZCkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFkZHJl c3MgY29kZQogIEFkZHJlc3MgbmFtZSAgICBsb2NfbmFtZSAgICAgbGl0ZXJhbCBpbmZvcm1hdGlv biBjb3JyZXNwb25kaW5nCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byBhZGRyZXNz IGNvZGUgKG5hbWUgb2YgcHJlZmVjdHVyZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNpdHkgb3IgY291bnR5LCBldGMuKQogIEFkZHJlc3MgbnVtYmVyICBsb2NfbnVtICAgICAgaG91 c2UgbnVtYmVyLCBzdHJlZXQgbnVtYmVyIGV0Yy4KICBPdGhlcnMgICAgICAgICAgbG9jX290aGVy cyAgIGhvdXNlIG5hbWUsIGJ1aWxkaW5nIG51bWJlciwgcm9vbQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgbnVtYmVyLCBvciBidWlsZGluZyBuYW1lIGFuZCBmbG9vcgoKQXJlYSBvZiAg ICAgICAgICAgbmFtZV9hcmVhICAgIGFyZWEgb2YgcmVwb3J0ZXIncyBuYW1lCnJlcG9ydGVyJ3Mg bmFtZQogIE5hbWUgaW4ga2FuYSAgICBuYW1lX2thbmEgICAgcHJvbnVuY2lhdGlvbiBvZiByZXBv cnRlcidzIG5hbWUKICBOYW1lIGluIGthbmppICAgbmFtZV9rYW5qaSAgIHJlcG9ydGVyJ3MgbmFt ZSBpbiBrYW5qaSBsZXR0ZXJzCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCjwvcHJlPgo8cD4KPHRhYmxlIGJvcmRlcj0i MCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBhbGlnbj0iY2VudGVyIj48dHI+PHRk IGFsaWduPSJjZW50ZXIiPjxmb250IGZhY2U9Im1vbmFjbywgTVMgU2FucyBTZXJpZiIgc2l6ZT0i MSI+PGI+Jm5ic3A7RmlndXJlJm5ic3A7MjogVGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uIGZvciB0 aGUgcG9ydGFibGUgSVAgdGVsZXBob25lJm5ic3A7PC9iPjwvZm9udD48YnIgLz48L3RkPjwvdHI+ PC90YWJsZT48aHIgc2l6ZT0iMSIgc2hhZGU9IjAiPgoKICAgICAgICAgICAgCjwvcD4KPHA+Cgk8 YnIgLz48aHIgLz4KPGEgbmFtZT0ibW9iaWxlLXRlbGVwaG9uZSI+PC9hPgo8L3A+CjxwcmU+Cgpl bGVtZW50ICAgICAgICAgICB0YWcgICAgICAgICAgcmVtYXJrcwotLS0tLS0tLS0tLS0tLS0gICAt LS0tLS0tLS0tLSAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpDYWxsZXIg SUQgICAgICAgICByZXBvX3RlbGUgICAgcmVwb3J0ZXIncyB0ZWxlcGhvbmUgbnVtYmVyClRlcm1p bmFsIHR5cGUgICAgIHRlcm1fdHlwZSAgICB3aGV0aGVyIHJlcG9ydGVyJ3MgdGVybWluYWwgaXMg Zml4ZWQtCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1c2Ugb3IgbW9iaWxlLXVzZQpM b2NhdGlvbiB0eXBlICAgICBsb2NfdHlwZSAgICAgaW5kaWNhdGluZyBlaXRoZXIgcGxhY2Ugb2Yg ZGlzcGF0Y2gKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluZm9ybWF0aW9uIG9yIHBy ZXNlbnQgcGxhY2UKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluZm9ybWF0aW9uIChz ZWUgKjEpCkFyZWEgb2YgbG9jYXRpb24gIGxvY19hcmVhICAgICBhcmVhIG9mIHJlcG9ydGVyJ3Mg Z2VvZ3JhcGhpY2FsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsb2NhdGlvbiBpbmZv cm1hdGlvbgogIFppcCBjb2RlICAgICAgICBsb2NfcG9zdCAgICAgcG9zdGFsIGNvZGUgbnVtYmVy CiAgQWRkcmVzcyBjb2RlICAgIGxvY19jb2RlICAgICBKSVMoSmFwYW5lc2UgSW5kdXN0cmlhbCBT dGFuZGFyZCkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFkZHJlc3MgY29kZQogIEFk ZHJlc3MgbmFtZSAgICBsb2NfbmFtZSAgICAgbGl0ZXJhbCBpbmZvcm1hdGlvbiBjb3JyZXNwb25k aW5nCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byBhZGRyZXNzIGNvZGUgKG5hbWUg b2YgcHJlZmVjdHVyZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNpdHkgb3IgY291 bnR5LCBhbmQgc28gb24pCiAgQWRkcmVzcyBudW1iZXIgIGxvY19udW0gICAgICBob3VzZSBudW1i ZXIsIHN0cmVldCBudW1iZXIgZXRjLgogIE90aGVycyAgICAgICAgICBsb2Nfb3RoZXJzICAgaG91 c2UgbmFtZSwgYnVpbGRpbmcgbnVtYmVyLCByb29tCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBudW1iZXIsIG9yIGJ1aWxkaW5nIG5hbWUgYW5kIGZsb29yCgpBcmVhIG9mICAgICAgICAg ICBDaXJjdWxhckFyZWEgY2lyY3VsYXIgYXJlYSBpbmNsdWRpbmcgbWVhc3VyZWQKbWVhc3VyZWQg cG9zaXRpb24gICAgICAgICAgICAgIHBvc2l0aW9uCiAgTGF0aXR1ZGUgICAgICAgIFggICAgICAg ICAgICBsYXRpdHVkZSBvZiBjZW50ZXIgb2YgQ2lyY3VsYXJBcmVhCiAgTG9uZ2l0dWRlICAgICAg IFkgICAgICAgICAgICBsb25naXR1ZGUgb2YgY2VudGVyIG9mIENpcmN1bGFyQXJlYQogIFJhZGl1 cyAgICAgICAgICBSYWRpdXMgICAgICAgcmFkaXVzIG9mIENpcmN1bGFyQXJlYQogIEFsdGl0dWRl ICAgICAgICBBbHQgICAgICAgICAgYWx0aXR1ZGUgb2YgcmVwb3J0ZXIncyBsb2NhdGlvbgogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKG9wdGlvbmFsKQogIFByZWNpc2lvbiBvZiBBbHQg IGFsdF9hY2MgICAgcHJlY2lzaW9uIG9mIEFsdCAob3B0aW9uYWwpCgpBcmVhIG9mICAgICAgICAg ICBuYW1lX2FyZWEgICAgYXJlYSBvZiByZXBvcnRlcidzIG5hbWUKcmVwb3J0ZXIncyBuYW1lCiAg TmFtZSBpbiBrYW5hICAgIG5hbWVfa2FuYSAgICBwcm9udW5jaWF0aW9uIG9mIHJlcG9ydGVyJ3Mg bmFtZQogIE5hbWUgaW4ga2FuamkgICBuYW1lX2thbmppICAgcmVwb3J0ZXIncyBuYW1lIGluIGth bmppIGxldHRlcnMKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKPC9wcmU+CjxwPgo8dGFibGUgYm9yZGVyPSIwIiBjZWxs cGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGFsaWduPSJjZW50ZXIiPjx0cj48dGQgYWxpZ249 ImNlbnRlciI+PGZvbnQgZmFjZT0ibW9uYWNvLCBNUyBTYW5zIFNlcmlmIiBzaXplPSIxIj48Yj4m bmJzcDtGaWd1cmUmbmJzcDszOiBUaGUgbG9jYXRpb24gaW5mb3JtYXRpb24gZm9yIHRoZSBtb2Jp bGUgSVAgdGVsZXBob25lJm5ic3A7PC9iPjwvZm9udD48YnIgLz48L3RkPjwvdHI+PC90YWJsZT48 aHIgc2l6ZT0iMSIgc2hhZGU9IjAiPgoKICAgICAgICAgICAgCjwvcD4KPHA+KCoxKTogIlBsYWNl IG9mIGRpc3BhdGNoIGluZm9ybWF0aW9uIiBtZWFucyBpbmZvcm1hdGlvbiBvbiB0aGUgcGxhY2Ug d2hlcmUgdGhlIHJlcG9ydGVyIG1ha2VzIHRoZSBlbWVyZ2VuY3kgY2FsbC4gICJQcmVzZW50IHBs YWNlIGluZm9ybWF0aW9uIiBtZWFucyBpbmZvcm1hdGlvbiBvbiB0aGUgcGxhY2Ugd2hlcmUgdGhl IHJlcG9ydGVyIGlzIHdoZW4gdGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uIGlzIHNlbnQuIAo8L3A+ CjxhIG5hbWU9InNlY3VyaXR5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlv dXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9ImJ1ZyIgYWxpZ249InJp Z2h0Ij48dHI+PHRkIGNsYXNzPSJidWciPjxhIGhyZWY9IiN0b2MiIGNsYXNzPSJsaW5rMiI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40 Ij48L2E+PGgzPjQuJm5ic3A7U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L2gzPgoKPHA+VEJECjwv cD4KPGEgbmFtZT0iaWFuYSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0 IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJidWciIGFsaWduPSJyaWdo dCI+PHRyPjx0ZCBjbGFzcz0iYnVnIj48YSBocmVmPSIjdG9jIiBjbGFzcz0ibGluazIiPiZuYnNw O1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNSI+ PC9hPjxoMz41LiZuYnNwO0lBTkEgQ29uc2lkZXJhdGlvbnM8L2gzPgoKPHA+VGhpcyBkb2N1bWVu dCBkb2VzIG5vdCBjb250YWluIElBTkEgY29uc2lkZXJhdGlvbnMuCjwvcD4KPGEgbmFtZT0iYWRk cmVzcyBjb2RlIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxw YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9ImJ1ZyIgYWxpZ249InJpZ2h0Ij48dHI+ PHRkIGNsYXNzPSJidWciPjxhIGhyZWY9IiN0b2MiIGNsYXNzPSJsaW5rMiI+Jm5ic3A7VE9DJm5i c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5BIj48L2E+PGgz PkFwcGVuZGl4IEEuJm5ic3A7SmFwYW5lc2UgQWRkcmVzcyBDb2RlIGZvciBMb2NhdGlvbiBJbmZv cm1hdGlvbjwvaDM+Cgo8cD5UaGUgYWRkcmVzcyBjb2RlIDxhIGNsYXNzPSJpbmZvIiBocmVmPSIj TEFTREVDIj5bTEFTREVDXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSJpbmZvIj5Mb2NhbCBB dXRob3JpdGllcyBTeXN0ZW1zIERldmVsb3BtZW50IENlbnRlciwgJmxkcXVvO0NoYXJhY3Rlcmlz dGljcyBvZiBaZW5rb2t1IE1hY2hpLUF6YSBGaWxlLCZyZHF1bzsgLjwvc3Bhbj48c3Bhbj4pPC9z cGFuPjwvYT4gaXMgdXNlZCBhcyBvbmUgZWxlbWVudCBvZiB0aGUgbG9jYXRpb24gaW5mb3JtYXRp b24gdGhhdCBpcyB0cmFuc2ZlcnJlZCBhcyBhIGdlb2dyYXBoaWNhbCBsb2NhdGlvbiBpbmZvcm1h dGlvbiB0byBhbiBlbWVyZ2VuY3kgY2FsbCByZWNlcHRpb24gb2ZmaWNlIGluIDxhIGNsYXNzPSJp bmZvIiBocmVmPSIjZ2VvIGxvY2FpdG9uIj5TZWN0aW9uJm5ic3A7My40PHNwYW4+ICg8L3NwYW4+ PHNwYW4gY2xhc3M9ImluZm8iPlByZXNlbnRpbmcgYW5kIEFjcXVpcmluZyBHZW9ncmFwaGljYWwg TG9jYXRpb24gSW5mb3JtYXRpb248L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+Lgo8L3A+CjxwPkl0 IGlzIDExLWRpZ2l0IGNvZGUsIHdoaWNoIGNvbnNpc3RzIG9mIDItZGlnaXQgcHJlZmVjdHVyZSBj b2RlLCAzLWRpZ2l0IG11bmljaXBhbGl0eSBjb2RlLCAzLWRpZ2l0IHNlY3Rpb24gY29kZSBhbmQg My1kaWdpdCBzdWJzZWN0aW9uIGNvZGUuICBDdXJyZW50bGx5LCBhcHByb3hpbWF0ZWx5IDUwMDAw MCBjb2RlcyBhcmUgcmVnaXN0ZXJlZC4KPC9wPjxiciAvPjxociAvPgo8YSBuYW1lPSJhLWMgc3Ry Ij48L2E+Cjx0YWJsZSBjbGFzcz0iZGF0YSIgYWxpZ249ImNlbnRlciIgYm9yZGVyPSIxIiBjZWxs cGFkZGluZz0iMiIgY2VsbHNwYWNpbmc9IjIiPgo8dHI+Cjx0aCBhbGlnbj0ibGVmdCIgd2lkdGg9 IjglIj5kaWdpdDwvdGg+Cjx0aCBhbGlnbj0ibGVmdCIgd2lkdGg9IjI0JSI+bmFtZSBvZiBjb2Rl PC90aD4KPHRoIGFsaWduPSJsZWZ0IiB3aWR0aD0iMTglIj52YWx1ZTwvdGg+Cjx0aCBhbGlnbj0i bGVmdCIgd2lkdGg9IjUwJSI+cmVtYXJrczwvdGg+CjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJsZWZ0 Ij4xJjI8L3RkPgo8dGQgYWxpZ249ImxlZnQiPnByZWZlY3R1cmUgY29kZTwvdGQ+Cjx0ZCBhbGln bj0ibGVmdCI+MDEtIDQ3PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5wcmVmZWN0dXJlPC90ZD4KPC90 cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPjMtNTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+bXVuaWNp cGFsaXR5IGNvZGU8L3RkPgo8dGQgYWxpZ249ImxlZnQiPjEwMC0xOTk8L3RkPgo8dGQgYWxpZ249 ImxlZnQiPndhcmQgKGluIGFuIG9yZGluYW5jZS1kZXNpZ25hdGVkIGNpdHkpIGFuZCBzcGVjaWFs LXdhcmQ8L3RkPgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+Jm5ic3A7PC90ZD4KPHRkIGFs aWduPSJsZWZ0Ij4mbmJzcDs8L3RkPgo8dGQgYWxpZ249ImxlZnQiPjIwMS0yOTk8L3RkPgo8dGQg YWxpZ249ImxlZnQiPmNpdHkgb3RoZXIgdGhhbiBhYm92ZTwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFs aWduPSJsZWZ0Ij4mbmJzcDs8L3RkPgo8dGQgYWxpZ249ImxlZnQiPiZuYnNwOzwvdGQ+Cjx0ZCBh bGlnbj0ibGVmdCI+MzAxLTc5OTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+dG93biBhbmQgdmlsbGFn ZSAoaW4gYSBkaXN0cmljdCk8L3RkPgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+Ni04PC90 ZD4KPHRkIGFsaWduPSJsZWZ0Ij5zZWN0aW9uIGNvZGU8L3RkPgo8dGQgYWxpZ249ImxlZnQiPjAw MS05OTkKMTBBLTk5WSgqKTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+c2VjdGlvbiBvZiBhIG11bmlj aXBhbGl0eSBhbmQgYnktbmFtZSBvZiBhbiBhcmVhPC90ZD4KPC90cj4KPHRyPgo8dGQgYWxpZ249 ImxlZnQiPjktMTE8L3RkPgo8dGQgYWxpZ249ImxlZnQiPnN1YnNlY3Rpb24gY29kZTwvdGQ+Cjx0 ZCBhbGlnbj0ibGVmdCI+MDAxLTA5OTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+IkNob21lIiB0aGF0 IGRldmlkZXMgYSBzZWN0aW9uPC90ZD4KPC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPiZuYnNw OzwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+Jm5ic3A7PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij4xMDEt ODQ5PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5ieS1uYW1lIG9mIGFuIGFyZWE8L3RkPgo8L3RyPgo8 dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+Jm5ic3A7PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij4mbmJzcDs8 L3RkPgo8dGQgYWxpZ249ImxlZnQiPjg1MS04OTk8L3RkPgo8dGQgYWxpZ249ImxlZnQiPml0IGlz IHVzZWQgd2hlbiBhcmVhcyB0aGF0IGFyZSBzaG93biBpbiB0aGUgc2FtZSBwbGFjZSBuYW1lIGhh dmUgZGlmZmVyZW50IHBvc3RhbCBjb2RlczwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJsZWZ0 Ij4mbmJzcDs8L3RkPgo8dGQgYWxpZ249ImxlZnQiPiZuYnNwOzwvdGQ+Cjx0ZCBhbGlnbj0ibGVm dCI+OTAxLTk5OTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+Zm9yIGFkZHJlc3MgbmFtZSBvZiBLeW90 byBDaXR5PC90ZD4KPC90cj4KPC90YWJsZT4KCjxwPigqKTpUaGUgY2FwaXRhbCBsZXR0ZXJzIG9m IHRoZSBSb21hbiBhbHBoYWJldCBhcmUgYWxzbyB1c2VkIG9uIDh0aCBkaWdpdC4gIEluIG9yZGVy IHRvIHByZXZlbnQgbWlzcmVhZGluZyB0aGVtIGFzIG51bWVyYWxzLCAnTycsICdJJywgJ1MnIGFu ZCAnWicgbXVzdCBub3QgYmUgdXNlZCB0aGVyZS4KPC9wPjx0YWJsZSBib3JkZXI9IjAiIGNlbGxw YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgYWxpZ249ImNlbnRlciI+PHRyPjx0ZCBhbGlnbj0i Y2VudGVyIj48Zm9udCBmYWNlPSJtb25hY28sIE1TIFNhbnMgU2VyaWYiIHNpemU9IjEiPjxiPiZu YnNwO1RhYmxlIDE6IFN0cnVjdHVyZSBvZiBBZGRyZXNzIENvZGUmbmJzcDs8L2I+PC9mb250Pjxi ciAvPjwvdGQ+PC90cj48L3RhYmxlPjxociBzaXplPSIxIiBzaGFkZT0iMCI+Cgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi5BLjEiPjwvYT48aDQ+PGEgbmFtZT0iYS1jIHByZWYiPkFwcGVuZGl4IEEuMTwv YT4mbmJzcDtQcmVmZWN0dXJlIGNvZGU8L2g0PgoKPHA+VGhpcyBpcyB0aGUgdG9wIGxldmVsIG9m IHRoZSBhZGRyZXNzIGNvZGUgYW5kIGNvbnNpc3RzIG9mIDItZGlnaXQgYmV0d2VlbiAwMSBhbmQg NDcgaW4gdGhlIGRlY2ltYWwgc3lzdGVtLiAgSmFwYW4gY29uc2lzdHMgb2YgNDcgcHJlZmVjdHVy ZXMgYXMgeW91IGNhbiByZWZlciBmcm9tIHRoZSBmb2xsb3dpbmcgVVJMLgo8L3A+CjxwPjwvcD4K PGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0Pmh0dHA6Ly91cGxvYWQud2lraW1lZGlh Lm9yZy93aWtpcGVkaWEvamEvZi9mZC9KYXBhbl9wcmVmZWN0dXJlcy5wbmc8L2R0Pgo8ZGQ+CiAg ICAgICAgICAgICAgICAgICAgCjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD5udW1i ZXJzOjwvZHQ+CjxkZD5lcXVhbCB0byBwcmVmZWN0dXJlIGNvZGUKPC9kZD4KPGR0PnJlZCBsaW5l czo8L2R0Pgo8ZGQ+dGhlIGJvdW5kYXJpZXMgb2YgZWFjaCBwcmVmZWN0dXJlCjwvZGQ+CjxkdD5i bHVlIGxpbmVzOjwvZHQ+CjxkZD5jb2FzdGxpbmVzLCBvciB0aGUgYm91bmRhcmllcyBvZiBhbiBh cmVhIG9mIGEgcml2ZXIgb3IgYSBsYWtlCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAg ICAgICAgICAgICAgICAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT4KPC9wPgo8cD5UaGlzIGNv ZGUgaXMgZGVmaW5lZCBieSA8YSBjbGFzcz0iaW5mbyIgaHJlZj0iI0pJUyBYIDA0MDEiPltKSVMg WCAwNDAxXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSJpbmZvIj5KYXBhbiBJbmR1c3RyaWFs IFN0YW5kYXJkLCAmbGRxdW87VG8tRG8tRnUtS2VuIChQcmVmZWN0dXJlKSBJZGVudGlmaWNhdGlv biBDb2RlLCZyZHF1bzsgQXByaWwmbmJzcDsxOTczLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4u ICBBbmQgYWxzbyA8YSBjbGFzcz0iaW5mbyIgaHJlZj0iI0lTTyAzMTY2LTIiPltJU08gMzE2Ni0y XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSJpbmZvIj5JbnRlcm5hdGlvbmFsIE9yZ2FuaXph dGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAmbGRxdW87Q29kZXMgZm9yIHRoZSByZXByZXNlbnRh dGlvbiBvZiBuYW1lcyBvZiBjb3VudHJpZXMgYW5kIHRoZWlyIHN1YmRpdmlzaW9ucyAtLSBQYXJ0 IDI6IENvdW50cnkgc3ViZGl2aXNpb24gY29kZSwmcmRxdW87IDE5OTguPC9zcGFuPjxzcGFuPik8 L3NwYW4+PC9hPiBkZWZpbmVzIHRoZSBzaW1pbGFyIGNvZGUuCjwvcD48YnIgLz48aHIgLz4KPGEg bmFtZT0iSklTIGFuZCBJU08iPjwvYT4KPHRhYmxlIGNsYXNzPSJkYXRhIiBhbGlnbj0iY2VudGVy IiBib3JkZXI9IjEiIGNlbGxwYWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMiI+Cjx0cj4KPHRoIGFs aWduPSJsZWZ0IiB3aWR0aD0iMjUlIj5KSVMgWCAwNDAxPC90aD4KPHRoIGFsaWduPSJsZWZ0IiB3 aWR0aD0iMjUlIj5JU08gMzE2Ni0yPC90aD4KPHRoIGFsaWduPSJsZWZ0IiB3aWR0aD0iNTAlIj5O YW1lIG9mIHByZWZlY3R1cmU8L3RoPgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+MDE8L3Rk Pgo8dGQgYWxpZ249ImxlZnQiPkpQLTAxPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5Ib2trYWlkbzwv dGQ+CjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJsZWZ0Ij4wMjwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+ SlAtMDI8L3RkPgo8dGQgYWxpZ249ImxlZnQiPkFvbW9yaTwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFs aWduPSJsZWZ0Ij4wMzwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+SlAtMDM8L3RkPgo8dGQgYWxpZ249 ImxlZnQiPkl3YXRlPC90ZD4KPC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPjA0PC90ZD4KPHRk IGFsaWduPSJsZWZ0Ij5KUC0wNDwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+TWl5YWdpPC90ZD4KPC90 cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPjA1PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5KUC0wNTwv dGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+QWtpdGE8L3RkPgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVm dCI+MDY8L3RkPgo8dGQgYWxpZ249ImxlZnQiPkpQLTA2PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5Z YW1hZ2F0YTwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJsZWZ0Ij4wNzwvdGQ+Cjx0ZCBhbGln bj0ibGVmdCI+SlAtMDc8L3RkPgo8dGQgYWxpZ249ImxlZnQiPkZ1a3VzaGltYTwvdGQ+CjwvdHI+ Cjx0cj4KPHRkIGFsaWduPSJsZWZ0Ij4wODwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+SlAtMDg8L3Rk Pgo8dGQgYWxpZ249ImxlZnQiPkliYXJha2k8L3RkPgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVm dCI+MDk8L3RkPgo8dGQgYWxpZ249ImxlZnQiPkpQLTA5PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5U b2NoaWdpPC90ZD4KPC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPjEwPC90ZD4KPHRkIGFsaWdu PSJsZWZ0Ij5KUC0xMDwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+R3VtbWE8L3RkPgo8L3RyPgo8dHI+ Cjx0ZCBhbGlnbj0ibGVmdCI+MTE8L3RkPgo8dGQgYWxpZ249ImxlZnQiPkpQLTExPC90ZD4KPHRk IGFsaWduPSJsZWZ0Ij5TYWl0YW1hPC90ZD4KPC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPjEy PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5KUC0xMjwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+Q2hpYmE8 L3RkPgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+MTM8L3RkPgo8dGQgYWxpZ249ImxlZnQi PkpQLTEzPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5Ub2t5bzwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFs aWduPSJsZWZ0Ij4xNDwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+SlAtMTQ8L3RkPgo8dGQgYWxpZ249 ImxlZnQiPkthbmFnYXdhPC90ZD4KPC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPjE1PC90ZD4K PHRkIGFsaWduPSJsZWZ0Ij5KUC0xNTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+TmlpZ2F0YTwvdGQ+ CjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJsZWZ0Ij4xNjwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+SlAt MTY8L3RkPgo8dGQgYWxpZ249ImxlZnQiPlRveWFtYTwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFsaWdu PSJsZWZ0Ij4xNzwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+SlAtMTc8L3RkPgo8dGQgYWxpZ249Imxl ZnQiPklzaGlrYXdhPC90ZD4KPC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPjE4PC90ZD4KPHRk IGFsaWduPSJsZWZ0Ij5KUC0xODwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+RnVrdWk8L3RkPgo8L3Ry Pgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+MTk8L3RkPgo8dGQgYWxpZ249ImxlZnQiPkpQLTE5PC90 ZD4KPHRkIGFsaWduPSJsZWZ0Ij5ZYW1hbmFzaGk8L3RkPgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0i bGVmdCI+MjA8L3RkPgo8dGQgYWxpZ249ImxlZnQiPkpQLTIwPC90ZD4KPHRkIGFsaWduPSJsZWZ0 Ij5OYWdhbm88L3RkPgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+MjE8L3RkPgo8dGQgYWxp Z249ImxlZnQiPkpQLTIxPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5HaWZ1PC90ZD4KPC90cj4KPHRy Pgo8dGQgYWxpZ249ImxlZnQiPjIyPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5KUC0yMjwvdGQ+Cjx0 ZCBhbGlnbj0ibGVmdCI+U2hpenVva2E8L3RkPgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+ MjM8L3RkPgo8dGQgYWxpZ249ImxlZnQiPkpQLTIzPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5BaWNo aTwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJsZWZ0Ij4yNDwvdGQ+Cjx0ZCBhbGlnbj0ibGVm dCI+SlAtMjQ8L3RkPgo8dGQgYWxpZ249ImxlZnQiPk1pZTwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFs aWduPSJsZWZ0Ij4yNTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+SlAtMjU8L3RkPgo8dGQgYWxpZ249 ImxlZnQiPlNoaWdhPC90ZD4KPC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPjI2PC90ZD4KPHRk IGFsaWduPSJsZWZ0Ij5KUC0yNjwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+S3lvdG88L3RkPgo8L3Ry Pgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+Mjc8L3RkPgo8dGQgYWxpZ249ImxlZnQiPkpQLTI3PC90 ZD4KPHRkIGFsaWduPSJsZWZ0Ij5Pc2FrYTwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJsZWZ0 Ij4yODwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+SlAtMjg8L3RkPgo8dGQgYWxpZ249ImxlZnQiPkh5 b2dvPC90ZD4KPC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPjI5PC90ZD4KPHRkIGFsaWduPSJs ZWZ0Ij5KUC0yOTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+TmFyYTwvdGQ+CjwvdHI+Cjx0cj4KPHRk IGFsaWduPSJsZWZ0Ij4zMDwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+SlAtMzA8L3RkPgo8dGQgYWxp Z249ImxlZnQiPldha2F5YW1hPC90ZD4KPC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPjMxPC90 ZD4KPHRkIGFsaWduPSJsZWZ0Ij5KUC0zMTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+VG90dG9yaTwv dGQ+CjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJsZWZ0Ij4zMjwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+ SlAtMzI8L3RkPgo8dGQgYWxpZ249ImxlZnQiPlNoaW1hbmU8L3RkPgo8L3RyPgo8dHI+Cjx0ZCBh bGlnbj0ibGVmdCI+MzM8L3RkPgo8dGQgYWxpZ249ImxlZnQiPkpQLTMzPC90ZD4KPHRkIGFsaWdu PSJsZWZ0Ij5Pa2F5YW1hPC90ZD4KPC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPjM0PC90ZD4K PHRkIGFsaWduPSJsZWZ0Ij5KUC0zNDwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+SGlyb3NoaW1hPC90 ZD4KPC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPjM1PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5K UC0zNTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+WWFtYWd1Y2hpPC90ZD4KPC90cj4KPHRyPgo8dGQg YWxpZ249ImxlZnQiPjM2PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5KUC0zNjwvdGQ+Cjx0ZCBhbGln bj0ibGVmdCI+VG9rdXNoaW1hPC90ZD4KPC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPjM3PC90 ZD4KPHRkIGFsaWduPSJsZWZ0Ij5KUC0zNzwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+S2FnYXdhPC90 ZD4KPC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPjM4PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5K UC0zODwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+RWhpbWU8L3RkPgo8L3RyPgo8dHI+Cjx0ZCBhbGln bj0ibGVmdCI+Mzk8L3RkPgo8dGQgYWxpZ249ImxlZnQiPkpQLTM5PC90ZD4KPHRkIGFsaWduPSJs ZWZ0Ij5Lb2NoaTwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJsZWZ0Ij40MDwvdGQ+Cjx0ZCBh bGlnbj0ibGVmdCI+SlAtNDA8L3RkPgo8dGQgYWxpZ249ImxlZnQiPkZ1a3Vva2E8L3RkPgo8L3Ry Pgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+NDE8L3RkPgo8dGQgYWxpZ249ImxlZnQiPkpQLTQxPC90 ZD4KPHRkIGFsaWduPSJsZWZ0Ij5TYWdhPC90ZD4KPC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQi PjQyPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5KUC00MjwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+TmFn YXNha2k8L3RkPgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+NDM8L3RkPgo8dGQgYWxpZ249 ImxlZnQiPkpQLTQzPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5LdW1hbW90bzwvdGQ+CjwvdHI+Cjx0 cj4KPHRkIGFsaWduPSJsZWZ0Ij40NDwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+SlAtNDQ8L3RkPgo8 dGQgYWxpZ249ImxlZnQiPk9pdGE8L3RkPgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+NDU8 L3RkPgo8dGQgYWxpZ249ImxlZnQiPkpQLTQ1PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5NaXlhemFr aTwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJsZWZ0Ij40NjwvdGQ+Cjx0ZCBhbGlnbj0ibGVm dCI+SlAtNDY8L3RkPgo8dGQgYWxpZ249ImxlZnQiPkthZ29zaGltYTwvdGQ+CjwvdHI+Cjx0cj4K PHRkIGFsaWduPSJsZWZ0Ij40NzwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+SlAtNDc8L3RkPgo8dGQg YWxpZ249ImxlZnQiPk9raW5hd2E8L3RkPgo8L3RyPgo8L3RhYmxlPgo8dGFibGUgYm9yZGVyPSIw IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGFsaWduPSJjZW50ZXIiPjx0cj48dGQg YWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0ibW9uYWNvLCBNUyBTYW5zIFNlcmlmIiBzaXplPSIx Ij48Yj4mbmJzcDtUYWJsZSAyOiBQcmVmZWN0dXJlIGNvZGUmbmJzcDs8L2I+PC9mb250PjxiciAv PjwvdGQ+PC90cj48L3RhYmxlPjxociBzaXplPSIxIiBzaGFkZT0iMCI+Cgo8YSBuYW1lPSJyZmMu c2VjdGlvbi5BLjIiPjwvYT48aDQ+PGEgbmFtZT0iYS1jIG11bmkiPkFwcGVuZGl4IEEuMjwvYT4m bmJzcDtNdW5pY2lwYWxpdHkgY29kZTwvaDQ+Cgo8cD5UaGlzIGZvbGxvd3MgdGhlIFByZWZlY3R1 cmUgY29kZSBhbmQgY29uc2lzdHMgb2YgMy1kaWdpdCBpbiB0aGUgZGVjaW1hbCBzeXN0ZW0uICBU aGlzIGNvZGUgc2hvd3MgYSBzcGVjaWFsLXdhcmQsIGEgd2FyZCBpbiBhbiBnb3Zlcm5tZW50LWRl c2lnbmF0ZWQgbWFqb3IgY2l0eSwgYSBjaXR5LCBvciBhIHRvd24gb3IgYSB2aWxsYWdlIGluIGEg ZGlzdHJpY3QuICBUaGUgZm9sbG93aW5nIFVSTCBzaG93cyB0aGUgZGl2aXNpb24uICBUaGVyZSBh cmUgMjMgc3BlY2lhbC13YXJkcyAoaW4gVG9reW8pLCA3MjYgY2l0aWVzLCAxNTU5IHRvd25zIGFu ZCA0MDAgdmlsbGFnZXMgYXMgb2YgMTQgTWFyLiAyMDA1Lgo8L3A+CjxwPjwvcD4KPGJsb2NrcXVv dGUgY2xhc3M9InRleHQiPjxkbD4KPGR0Pmh0dHA6Ly91cGxvYWQud2lraW1lZGlhLm9yZy93aWtp cGVkaWEvamEvNy83Yi9KYXBhbl9tYXAucG5nPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAg IAo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+YmxhY2sgbGluZXM6PC9kdD4KPGRk PnRoZSBib3VuZGFyaWVzIG9mIGVhY2ggbXVuaWNpcGFsaXR5CjwvZGQ+CjxkdD5yZWQgbGluZXM6 PC9kdD4KPGRkPnRoZSBib3VuZGFyaWVzIG9mIGVhY2ggcHJlZmVjdHVyZQo8L2RkPgo8ZHQ+Ymx1 ZSBsaW5lczo8L2R0Pgo8ZGQ+Y29hc3RsaW5lcywgb3IgdGhlIGJvdW5kYXJpZXMgb2YgYW4gYXJl YSBvZiBhIHJpdmVyIG9yIGEgbGFrZQo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4KICAgICAg ICAgICAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+CjwvcD4KPHA+VGhpcyBjb2Rl IGlzIGRlZmluZWQgYnkgPGEgY2xhc3M9ImluZm8iIGhyZWY9IiNKSVMgWCAwNDAyIj5bSklTIFgg MDQwMl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0iaW5mbyI+SmFwYW4gSW5kdXN0cmlhbCBT dGFuZGFyZCwgJmxkcXVvO0lkZW50aWZpY2F0aW9uIGNvZGUgZm9yIGNpdGllcywgdG93bnMgYW5k IHZpbGxhZ2VzLCZyZHF1bzsgRGVjZW1iZXImbmJzcDsyMDAzLjwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4uCjwvcD4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQS4yLjEiPjwvYT48aDQ+PGEgbmFtZT0i cHJlZmVjdHVyZXMiPkFwcGVuZGl4IEEuMi4xPC9hPiZuYnNwO1ByZWZlY3R1cmU8L2g0PgoKPHA+ MDAwIGlzIHVzZWQgZm9yIGEgcHJlZmVjdHVyZS4gIEZvciBleGFtcGxlLCBIb2trYWlkbyBpcyAw MTAwMC4KPC9wPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5BLjIuMiI+PC9hPjxoND48YSBuYW1lPSJ3 YXJkIj5BcHBlbmRpeCBBLjIuMjwvYT4mbmJzcDtHb3Zlcm5tZW50LWRlc2lnbmF0ZWQgbWFqb3Ig Y2l0aWVzIGFuZCB3YXJkczwvaDQ+Cgo8cD5BIGdvdmVybm1lbnQtZGVzaWduYXRlZCBtYWpvciBj aXR5IGlzIGEgY2l0eSBvZiA1MDAwMDAgb3IgbW9yZSwgZ3JhbnRlZCBzcGVjaWFsIHJpZ2h0cyBi eSBnb3Zlcm5tZW50IG9yZGluYW5jZS4KPC9wPgo8cD5UaGUgY29kZSBmb3IgYSBnb3Zlcm5tZW50 LWRlc2lnbmF0ZWQgbWFqb3IgY2l0eSBpcyB1c2VkIHRoZSBudW1iZXIgc3RhcnRpbmcgZnJvbSAx MDAgZXZlcnkgMzAgaW4gb3JkZXIgdGhhdCB0aGUgb3JkaW5hbmNlLWRlc2lnbmF0ZWQgY2l0eSBp cyBlbmZvcmNlZCBpbiBhIHByZWZlY3R1cmUsIGUuZy4gMTAwLCAxMzAsIDE2MC4gIEFuZCBlYWNo IHdhcmQgaW4gdGhlIGNpdGllcyBpcyBzZXF1ZW50aWFsbHkgbnVtYmVyZWQgZnJvbSAxMDEsIDEz MSwgMTYxLgo8L3A+CjxwPjwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PkZv ciBleGFtcGxlLCBpbiBjYXNlIG9mIFlva29oYW1hIENpdHkgYW5kIEthd2FzYWtpIENpdHkgdGhh dCBhcmUgZ292ZXJtZW50LWRlc2lnbmF0ZWQgbWFqb3IgY2l0aWVzIGluIEthbmFnYXdhIHByZWZl Y3R1cmUgKHdoaWNoIHByZWZlY3R1cmUgY29kZSBpcyAxNCk7PC9kdD4KPGRkPgogICAgICAgICAg ICAgICAgICAgICAgCjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD5Zb2tvaGFtYSBD aXR5OjwvZHQ+CjxkZD4xNDEwMAogICAgICAgICAgICAgICAgICAgICAgICAKPGJsb2NrcXVvdGUg Y2xhc3M9InRleHQiPjxkbD4KPGR0PlRzdXJ1bWkgV2FyZDo8L2R0Pgo8ZGQ+MTQxMDEKPC9kZD4K PGR0PkthbmFnYXdhIFdhcmQ6PC9kdD4KPGRkPjE0MTAyCjwvZGQ+CjxkdD4uLi48L2R0Pgo8ZGQ+ CjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPgo8L2RkPgo8ZHQ+S2F3YXNha2kgQ2l0eTo8L2R0Pgo8 ZGQ+MTQxMzAKICAgICAgICAgICAgICAgICAgICAgICAgCjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0 Ij48ZGw+CjxkdD5LYXdhc2FraSBXYXJkOjwvZHQ+CjxkZD4xNDEzMQo8L2RkPgo8ZHQ+U2Fpd2Fp IFdhcmQ6PC9kdD4KPGRkPjE0MTMyCjwvZGQ+CjxkdD4uLi48L2R0Pgo8ZGQ+CjwvZGQ+CjwvZGw+ PC9ibG9ja3F1b3RlPgo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4KICAgICAgICAgICAgICAg ICAgICAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT4KPC9wPgo8YSBuYW1lPSJyZmMuc2VjdGlv bi5BLjIuMyI+PC9hPjxoND48YSBuYW1lPSJzLXdhcmQiPkFwcGVuZGl4IEEuMi4zPC9hPiZuYnNw O1NwZWNpYWwtd2FyZHMgaW4gVG9reW88L2g0PgoKPHA+MTAwIGlzIGFzc2lnbmVkIGZvciAiU3Bl Y2lhbC13YXJkIiBhcyB3ZWxsIGFzIHRoZSBnb3Zlcm5tZW50LWRlc2lnbmF0ZWQgbWFqb3IgY2l0 eS4gIEFuZCBlYWNoIHdhcmQgaW4gVG9reW8gKHdoaWNoIHByZWZlY3R1cmUgY29kZSBpcyAxMykg aXMgc2VxdWVudGlhbGx5IG51bWJlcmVkIGZyb20gMTAxLgo8L3A+CjxwPjwvcD4KPGJsb2NrcXVv dGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PkZvciBleGFtcGxlOzwvZHQ+CjxkZD4KICAgICAgICAg ICAgICAgICAgICAgIAo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+U3BlY2lhbC13 YXJkOjwvZHQ+CjxkZD4xMzEwMAo8L2RkPgo8ZHQ+Q2hpeW9kYSB3YXJkOjwvZHQ+CjxkZD4xMzEw MQo8L2RkPgo8ZHQ+Q2h1byB3YXJkOjwvZHQ+CjxkZD4xMzEwMgo8L2RkPgo8ZHQ+Li4uPC9kdD4K PGRkPgo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT4KPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+Cgo8 YSBuYW1lPSJyZmMuc2VjdGlvbi5BLjIuNCI+PC9hPjxoND48YSBuYW1lPSJjaXRpZXMiPkFwcGVu ZGl4IEEuMi40PC9hPiZuYnNwO0NpdGllczwvaDQ+Cgo8cD5FYWNoIGNpdHkgZXhjZXB0aW5nIEdv dmVybm1lbnQtZGVzaWduYXRlZCBtYWpvciBjaXRpZXMgaXMgc2VxdWVudGlhbGx5IG51bWJlcmVk IGZyb20gMjAxLiAgVXN1YWxseSB0aGUgbnVtYmVyIGlzIGFzc2lnbmVkIGluIG9yZGVyIG9mIHRo ZSBtdW5pY2lwYWwgb3JnYW5pemF0aW9uIGVuZm9yY2VtZW50Lgo8L3A+CjxwPjwvcD4KPGJsb2Nr cXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PkZvciBleGFtcGxlLCBpbiBjYXNlIG9mIFRva3lv IHByZWZlY3R1cmU7PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAgICAgCjxibG9ja3F1b3Rl IGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD5IYWNoaW9qaSBDaXR5OjwvZHQ+CjxkZD4xMzIwMQo8L2Rk Pgo8ZHQ+VGFjaGlrYXdhIENpdHk6PC9kdD4KPGRkPjEzMjAyCjwvZGQ+CjxkdD5NdXNhc2hpbm8g Q2l0eTo8L2R0Pgo8ZGQ+MTMyMDMKPC9kZD4KPGR0Pi4uLjwvZHQ+CjxkZD4KPC9kZD4KPC9kbD48 L2Jsb2NrcXVvdGU+CjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPgoKPGEgbmFtZT0icmZjLnNlY3Rp b24uQS4yLjUiPjwvYT48aDQ+PGEgbmFtZT0idG93biI+QXBwZW5kaXggQS4yLjU8L2E+Jm5ic3A7 VG93bnMgYW5kIFZpbGxhZ2VzPC9oND4KCjxwPlRoZSBudW1iZXIgZnJvbSAzMDEgaXMgYXNzaWdu ZWQgZm9yIGVhY2ggdG93biBhbmQgdmlsbGFnZS4gIFRoZSB0b3duIGFuZCB2aWxsYWdlIGlzIG1h ZGUgYSBncm91cCBpbiBlYWNoIGRpc3RyaWN0LCBhbmQgdGhlIG51bWJlciBvZiBldmVyeSAyMCBp cyBnaXZlbiBzZXF1ZW50aWFsbHkgYXMgMzAxLCAzMjEsIDM0MS4KPC9wPgo8cD48L3A+CjxibG9j a3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD5Gb3IgZXhhbXBsZSwgaW4gY2FzZSBvZiBIaWdh c2hpLVRzdWdhcnUgRGlzdHJpY3QgYW5kIE5pc2hpLVRzdWdhcnUgRGlzdHJpY3Qgb2YgQW9tb3Jp IHByZWZlY3R1cmUgKHdoaWNoIGNvZGUgaXMgMDIpOzwvZHQ+CjxkZD4KICAgICAgICAgICAgICAg ICAgICAgIAo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+SGlnYXNoaS1Uc3VnYXJ1 IERpc3RyaWN0PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAgICAgICAKPGJsb2NrcXVvdGUg Y2xhc3M9InRleHQiPjxkbD4KPGR0PkhpcmFuYWkgVG93bjo8L2R0Pgo8ZGQ+MDIzMDEKPC9kZD4K PGR0Pkthbml0YSBUb3duOjwvZHQ+CjxkZD4wMjMwMgo8L2RkPgo8ZHQ+SW1hYmV0c3UgVG93bjo8 L2R0Pgo8ZGQ+MDIzMDMKPC9kZD4KPGR0Pi4uLjwvZHQ+CjxkZD4KPC9kZD4KPC9kbD48L2Jsb2Nr cXVvdGU+CjwvZGQ+CjxkdD5OaXNoaS1Uc3VnYXJ1IERpc3RyaWN0PC9kdD4KPGRkPgogICAgICAg ICAgICAgICAgICAgICAgICAKPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PkFqaWdh c2F3YSBUb3duOjwvZHQ+CjxkZD4wMjMyMQo8L2RkPgo8ZHQ+RnVrYXVyYSBUb3duOjwvZHQ+Cjxk ZD4wMjMyMwo8L2RkPgo8ZHQ+SXdhc2FraSBWaWxsYWdlOjwvZHQ+CjxkZD4wMjMyNQo8L2RkPgo8 ZHQ+Li4uPC9kdD4KPGRkPgo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT4KPC9kZD4KPGR0PjwvZHQ+ CjxkZD5Ob3RlIHRoYXQgMDIzMjIsIDAyMzI0IGFyZSBtaXNzaW5nIG51bWJlciBkdWUgdG8gbXVu aWNpcGFsIG1lcmdlcnMuCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgICAgICAg ICAgICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPgo8L3A+CjxwPkV4Y2VwdGlvbmFsbHks IFNoaW1hamlyaSBEaXN0cmljdCBvZiBPa2luYXdhIFByZWZlY3R1cmUgaXMgYXNzaWduZWQgYmV0 d2VlbiAzNDEgYW5kIDM2OSwgYW5kIE1peWFrbyBEaXN0cmljdCBpcyBhc3NpZ25lZCBiZXR3ZWVu IDM3MSBhbmQgMzc5LCBiZWNhdXNlIFNoaW1hamlyaSBEaXN0cmljdCBjb25zaXN0ZWQgb2YgbW9y ZSB0aGFuIDIwIHRvd25zIGFuZCB2aWxsYWdlcy4KPC9wPgo8cD5JbiB0aGUgY2FzZSBvZiBIb2tr YWlkbywgZWFjaCBicmFuY2ggYWRtaW5pc3RyYXRpdmUgb2ZmaWNlIGlzIG1hZGUgYSBncm91cCwg YW5kIHRoZSBudW1iZXIgaXMgZ2l2ZW4gYXQgaW50ZXJ2YWxzIG9mIDMwIHN1Y2ggYXMgMzAxLCAz MzEsIDM2MS4gIEFuZCBhbHNvIGluIHRoZSBjYXNlIG9mIHNvbGl0YXJ5IGlzbGFuZHMgb2YgVG9r eW8gcHJlZmVjdHVyZSBhbmQgVHN1c2hpbWEgaXNsYW5kcyBvZiBOYWdhc2FraSBwcmVmZWN0dXJl LCBlYWNoIGJyYW5jaCBhZG1pbmlzdHJhdGl2ZSBvZmZpY2UgaXMgbWFkZSBhIGdyb3VwLCBhbmQg dGhlIG51bWJlciBmb2xsb3dpbmcgdGhlIG1haW5sYW5kIGlzIGdpdmVuIGF0IGludGVydmFscyBv ZiAyMC4KPC9wPgo8cD4KPC9wPgo8cD4KPC9wPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5BLjMiPjwv YT48aDQ+PGEgbmFtZT0iYS1jIHNlYyI+QXBwZW5kaXggQS4zPC9hPiZuYnNwO1NlY3Rpb24gY29k ZSBhbmQgU3Vic2VjdGlvbiBjb2RlPC9oND4KCjxwPlNlY3Rpb24gY29kZSBhbmQgU3Vic2VjdGlv biBjb2RlIGFyZSBkZWZpbmVkIGJ5IHR3byBwdWJsaWMgY29ycG9yYXRpb25zIHVuZGVyIHRoZSBq dXJpc2RpY3Rpb24gb2YgdGhlIE1pbmlzdHJ5IG9mIEludGVybmFsIEFmZmFpcnMgYW5kIENvbW11 bmljYXRpb25zLCB3aGljaCBhcmUgTEFTREVDIChMb2NhbCBBdXRob3JpdGllcyBTeXN0ZW1zIERl dmVsb3BtZW50IENlbnRlciwgaHR0cDovL3d3dy5sYXNkZWMubmlwcG9uLW5ldC5uZS5qcC8pIGFu ZCBKR0RDIChKYXBhbiBHZW9ncmFwaGljIERhdGEgQ2VudGVyLCBodHRwOi8vd3d3Lmtva3Vkby5v ci5qcC8pLiAgVGhlc2UgYXJlIHVzZWQgZm9yIHJlcHJlc2VudGluZyBvZmZpY2lhbCBhZGRyZXNz IG5hbWVzIGFuZCBwb3B1bGFyIG5hbWVzLiAgQXMgcG9wdWxhciBuYW1lcywgdGhlcmUgYXJlIHRo ZSBuYW1lIG9mIGFuIGFyY2hpdGVjdHVyZSwgdGhlIG51bWJlciBvZiBmbG9vciBhbmQgc28gb24u CjwvcD48YnIgLz48aHIgLz4KPGEgbmFtZT0iYnVpbGRpbmciPjwvYT4KPHRhYmxlIGNsYXNzPSJk YXRhIiBhbGlnbj0iY2VudGVyIiBib3JkZXI9IjEiIGNlbGxwYWRkaW5nPSIyIiBjZWxsc3BhY2lu Zz0iMiI+Cjx0cj4KPHRoIGFsaWduPSJsZWZ0IiB3aWR0aD0iMjAlIj5jb2RlPC90aD4KPHRoIGFs aWduPSJsZWZ0IiB3aWR0aD0iMjAlIj5QcmVmZWN0dXJlPC90aD4KPHRoIGFsaWduPSJsZWZ0IiB3 aWR0aD0iMjAlIj5NdW5pY2lwYWxpdHk8L3RoPgo8dGggYWxpZ249ImxlZnQiIHdpZHRoPSIyMCUi PlNlY3Rpb248L3RoPgo8dGggYWxpZ249ImxlZnQiIHdpZHRoPSIyMCUiPlN1YnNlY3Rpb248L3Ro Pgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+MTMxMDQxMTIwMDA8L3RkPgo8dGQgYWxpZ249 ImxlZnQiPlRva3lvPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5TaGluanVrdTwvdGQ+Cjx0ZCBhbGln bj0ibGVmdCI+SXNsYW5kLVRvd2VyPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij4mbmJzcDs8L3RkPgo8 L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+MTMxMDQxMTIxMDE8L3RkPgo8dGQgYWxpZ249Imxl ZnQiPlRva3lvPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij4gU2hpbmp1a3U8L3RkPgo8dGQgYWxpZ249 ImxlZnQiPklzbGFuZC1Ub3dlcjwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+MXN0IGZsb29yPC90ZD4K PC90cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPjEzMTA0MTEyMTAyPC90ZD4KPHRkIGFsaWduPSJs ZWZ0Ij5Ub2t5bzwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+U2hpbmp1a3U8L3RkPgo8dGQgYWxpZ249 ImxlZnQiPklzbGFuZC1Ub3dlPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij4ybmQgZmxvb3I8L3RkPgo8 L3RyPgo8L3RhYmxlPgo8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNp bmc9IjIiIGFsaWduPSJjZW50ZXIiPjx0cj48dGQgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0i bW9uYWNvLCBNUyBTYW5zIFNlcmlmIiBzaXplPSIxIj48Yj4mbmJzcDtUYWJsZSAzOiBFeGFtcGxl OiBhZGRyZXNzIGNvZGUgb2YgYSBidWlsZGluZyZuYnNwOzwvYj48L2ZvbnQ+PGJyIC8+PC90ZD48 L3RyPjwvdGFibGU+PGhyIHNpemU9IjEiIHNoYWRlPSIwIj4KCjxwPjEzIGlzIHRoZSBjb2RlIG9m IFRva3lvIHByZWZlY3R1cmUsIDEwNCBpcyBTaGluanVrdSBXYXJkLCAxMTIgaXMgSXNsYW5kLVRv d2VyIGJ1aWxkaW5nLiAgQW5kIHRoZSBudW1iZXIgb2YgZmxvb3IgaXMgYSBraW5kIG9mIHB1cGxh ciBuYW1lcywgc28gMTAxIGFuZCAxMDIgYXJlIGFzc2lnbmVkLgo8L3A+CjxwPkFuZCBJc2xhbmQt VG93ZXIgaXMgaW4gTmlzaGktU2hpbmp1a3UsIFNoaW5qdWt1IFdhcmQsIFRva3lvIHByZWZlY3R1 cmUuICBUaGUgY29kZXMgb2YgdGhhdCBhcmVhIGFyZSB0aGUgZm9sbG93aW5nOwo8L3A+PGJyIC8+ PGhyIC8+CjxhIG5hbWU9ImJ5LW5hbWUiPjwvYT4KPHRhYmxlIGNsYXNzPSJkYXRhIiBhbGlnbj0i Y2VudGVyIiBib3JkZXI9IjEiIGNlbGxwYWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMiI+Cjx0cj4K PHRoIGFsaWduPSJsZWZ0IiB3aWR0aD0iMjIlIj5jb2RlPC90aD4KPHRoIGFsaWduPSJsZWZ0IiB3 aWR0aD0iMjAlIj5QcmVmZWN0dXJlPC90aD4KPHRoIGFsaWduPSJsZWZ0IiB3aWR0aD0iMjIlIj5N dW5pY2lwYWxpdHk8L3RoPgo8dGggYWxpZ249ImxlZnQiIHdpZHRoPSIxNiUiPlNlY3Rpb248L3Ro Pgo8dGggYWxpZ249ImxlZnQiIHdpZHRoPSIyMCUiPlN1YnNlY3Rpb248L3RoPgo8L3RyPgo8dHI+ Cjx0ZCBhbGlnbj0ibGVmdCI+MTMxMDQwNzAwMDE8L3RkPgo8dGQgYWxpZ249ImxlZnQiPlRva3lv PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5TaGluanVrdTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+Tmlz aGktIFNoaW5qdWt1PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij4xLUNob21lPC90ZD4KPC90cj4KPHRy Pgo8dGQgYWxpZ249ImxlZnQiPjEzMTA0MDcwMDAyPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5Ub2t5 bzwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+U2hpbmp1a3U8L3RkPgo8dGQgYWxpZ249ImxlZnQiPk5p c2hpLSBTaGluanVrdTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+Mi1DaG9tZTwvdGQ+CjwvdHI+Cjx0 cj4KPHRkIGFsaWduPSJsZWZ0Ij4xMzEwNDA3MDAwMzwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+VG9r eW88L3RkPgo8dGQgYWxpZ249ImxlZnQiPlNoaW5qdWt1PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5O aXNoaS0gU2hpbmp1a3U8L3RkPgo8dGQgYWxpZ249ImxlZnQiPjMtQ2hvbWU8L3RkPgo8L3RyPgo8 dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+MTMxMDQwNzAwMDQ8L3RkPgo8dGQgYWxpZ249ImxlZnQiPlRv a3lvPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5TaGluanVrdTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+ TmlzaGktIFNoaW5qdWt1PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij40LUNob21lPC90ZD4KPC90cj4K PHRyPgo8dGQgYWxpZ249ImxlZnQiPjEzMTA0MDcwMDA1PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5U b2t5bzwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+U2hpbmp1a3U8L3RkPgo8dGQgYWxpZ249ImxlZnQi Pk5pc2hpLSBTaGluanVrdTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+NS1DaG9tZTwvdGQ+CjwvdHI+ Cjx0cj4KPHRkIGFsaWduPSJsZWZ0Ij4xMzEwNDA3MDAwNjwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+ VG9reW88L3RkPgo8dGQgYWxpZ249ImxlZnQiPlNoaW5qdWt1PC90ZD4KPHRkIGFsaWduPSJsZWZ0 Ij5OaXNoaS0gU2hpbmp1a3U8L3RkPgo8dGQgYWxpZ249ImxlZnQiPjYtQ2hvbWU8L3RkPgo8L3Ry Pgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+MTMxMDQwNzAwMDc8L3RkPgo8dGQgYWxpZ249ImxlZnQi PlRva3lvPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5TaGluanVrdTwvdGQ+Cjx0ZCBhbGlnbj0ibGVm dCI+TmlzaGktIFNoaW5qdWt1PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij43LUNob21lPC90ZD4KPC90 cj4KPHRyPgo8dGQgYWxpZ249ImxlZnQiPjEzMTA0MDcwMDA4PC90ZD4KPHRkIGFsaWduPSJsZWZ0 Ij5Ub2t5bzwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+U2hpbmp1a3U8L3RkPgo8dGQgYWxpZ249Imxl ZnQiPk5pc2hpLSBTaGluanVrdTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+OC1DaG9tZTwvdGQ+Cjwv dHI+CjwvdGFibGU+Cjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMiIgYWxpZ249ImNlbnRlciI+PHRyPjx0ZCBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJt b25hY28sIE1TIFNhbnMgU2VyaWYiIHNpemU9IjEiPjxiPiZuYnNwO1RhYmxlIDQ6IEV4YW1wbGU6 IGFkZHJlc3MgY29kZSBvZiBDaG9tZSZuYnNwOzwvYj48L2ZvbnQ+PGJyIC8+PC90ZD48L3RyPjwv dGFibGU+PGhyIHNpemU9IjEiIHNoYWRlPSIwIj4KCjxwPjA3MCBhdCA2LTggZGlnaXQgaXMgYXNz aWduZWQgZm9yIE5pc2hpLVNoaW5qdWt1LCBhbmQgMDAxIHRocnUgMDA4IGF0IDktMTEgZGlnaXQg YXJlIGVhY2ggIkNob21lIi4KPC9wPjxiciAvPjxociAvPgo8YSBuYW1lPSJkaWZmIHppcCI+PC9h Pgo8dGFibGUgY2xhc3M9ImRhdGEiIGFsaWduPSJjZW50ZXIiIGJvcmRlcj0iMSIgY2VsbHBhZGRp bmc9IjIiIGNlbGxzcGFjaW5nPSIyIj4KPHRyPgo8dGggYWxpZ249ImxlZnQiIHdpZHRoPSIyNiUi PmNvZGU8L3RoPgo8dGggYWxpZ249ImxlZnQiIHdpZHRoPSIxNCUiPlByZWZlYyB0dXJlPC90aD4K PHRoIGFsaWduPSJsZWZ0IiB3aWR0aD0iMTUlIj5NdW5pY2lwYWwgaXR5PC90aD4KPHRoIGFsaWdu PSJsZWZ0IiB3aWR0aD0iMTUlIj5TZWN0aW9uPC90aD4KPHRoIGFsaWduPSJsZWZ0IiB3aWR0aD0i MTUlIj5TdWIgc2VjdGlvbjwvdGg+Cjx0aCBhbGlnbj0ibGVmdCIgd2lkdGg9IjE1JSI+UG9zdGFs IENvZGU8L3RoPgo8L3RyPgo8dHI+Cjx0ZCBhbGlnbj0ibGVmdCI+MTMxMDQwOTkwMDM8L3RkPgo8 dGQgYWxpZ249ImxlZnQiPlRva3lvPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5TaGluanVrdTwvdGQ+ Cjx0ZCBhbGlnbj0ibGVmdCI+VG95YW1hPC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij4zLUNob21lPC90 ZD4KPHRkIGFsaWduPSJsZWZ0Ij4xNjItMDA1MjwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGFsaWduPSJs ZWZ0Ij4xMzEwNDA5OTg1MTwvdGQ+Cjx0ZCBhbGlnbj0ibGVmdCI+VG9reW88L3RkPgo8dGQgYWxp Z249ImxlZnQiPlNoaW5qdWt1PC90ZD4KPHRkIGFsaWduPSJsZWZ0Ij5Ub3lhbWE8L3RkPgo8dGQg YWxpZ249ImxlZnQiPjMtQ2hvbWU8L3RkPgo8dGQgYWxpZ249ImxlZnQiPjE2OS0wMDUyPC90ZD4K PC90cj4KPC90YWJsZT4KPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIyIiBhbGlnbj0iY2VudGVyIj48dHI+PHRkIGFsaWduPSJjZW50ZXIiPjxmb250IGZhY2U9 Im1vbmFjbywgTVMgU2FucyBTZXJpZiIgc2l6ZT0iMSI+PGI+Jm5ic3A7VGFibGUgNTogRXhhbXBs ZTogYWRkcmVzcyBjb2RlIG9mIGRpZmZlcmVudCBwb3N0YWwgY29kZSZuYnNwOzwvYj48L2ZvbnQ+ PGJyIC8+PC90ZD48L3RyPjwvdGFibGU+PGhyIHNpemU9IjEiIHNoYWRlPSIwIj4KCjxwPjMtQ2hv bWUsIFRveWFtYSwgU2hpbmp1a3UtV2FyZCwgVG9reW8gaXMgYXNzaWduZWQgbW9yZSB0aGFuIG9u ZSBwb3N0YWwgY29kZSBudW1iZXIuICBTbywgMTMxMDQwOTkwMDMgKDEzOiBUb2t5bywgMTA0OiBT aGluanVrdSwgMDk5OiBUb3lhbWEsIDAwMzogMy1DaG9tZSkgaXMgYXNzaWduZWQgYXMgdGhlIHBy aW5jaXBhbCBjb2RlLCAxMzEwNDA5OTg1MSBpcyBhcyB0aGUgc3VwcGxpbWVudGFyeSBjb2RlLgo8 L3A+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuNCI+PC9hPjxoND48YSBuYW1lPSJhZGQtZGlzYyI+ QXBwZW5kaXggQS40PC9hPiZuYnNwO0FkZGluZyBhbmQgRGlzY29udGludWluZyBDb2RlPC9oND4K CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuNC4xIj48L2E+PGg0PjxhIG5hbWU9ImNhc2UtYWRkLWRp c2NvbiI+QXBwZW5kaXggQS40LjE8L2E+Jm5ic3A7Q2FzZXMgb2YgYWRkaW5nIGFuZCBkaXNjb250 bnVpbmcgY29kZTwvaDQ+Cgo8cD48L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT5yZWFkanVzdG1l bnQgb2YgdGhlIGRpdml0aW9uIG9mIGxhbmQKPC9saT4KPGxpPmVuZm9yY2VtZW50IG9mIHRoZSB3 YXJkIHN5c3RlbQo8L2xpPgo8bGk+ZW5mb3JjZW1lbnQgb2YgdGhlIGNpdHkgc3lzdGVtCjwvbGk+ CjxsaT5tdW5pY2lwYWwgbWVyZ2VyCjwvbGk+CjxsaT5yZW51bWJlcmluZyBvZiBsb3RzLCBldGMu CjwvbGk+CjwvdWw+Cgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5BLjQuMiI+PC9hPjxoND48YSBuYW1l PSJhZGRjb2RlIj5BcHBlbmRpeCBBLjQuMjwvYT4mbmJzcDtBZGRpbmcgQ29kZTwvaDQ+Cgo8cD5B IG5ldyBhZGRyZXNzIGNvZGUgaXMgYXNzaWduZWQgdG8gdGhlIG5ldyBhZGRyZXNzLCB3aGljaCBp cyBicm91Z2h0IGFkbWluaXN0cmF0aXZlbHkuICBIb3dldmVyIG5vIG5ldyBjb2RlIGlzIGFzc2ln bmVkIGluIHRoZSBmb2xsb3dpbmcgY2FzZXM7CjwvcD4KPHA+PC9wPgo8dWwgY2xhc3M9InRleHQi Pgo8bGk+Y2hhbmdpbmcgb25seSB0aGUgbmFtZSBvZiBjaXR5LCB3YXJkLCB0b3duIG9yIHZpbGxh Z2UKPC9saT4KPGxpPnNoaWZ0aW5nIHZpbGxhZ2UgdG8gdG93bgo8L2xpPgo8bGk+aW4gY2FzZSBv ZiBtdW5pY2lwYWwgbWVyZ2VyLCBhbmQgb25lIG9mIHRoZWlyIG5hbWUgaXMgcmV1c2VkIGZvciB0 aGUgbWVyZ2VkIG11bmljaXBhbGl0eQo8L2xpPgo8L3VsPgoKPGEgbmFtZT0icmZjLnNlY3Rpb24u QS40LjMiPjwvYT48aDQ+PGEgbmFtZT0iZGlzY2NvZGUiPkFwcGVuZGl4IEEuNC4zPC9hPiZuYnNw O0Rpc2NvbnRpbnVpbmcgQ29kZTwvaDQ+Cgo8cD5JbiBjYXNlIGEgYWRkcmVzcyB3YXMgYWJvbGlz aGVkLCB0aGUgY29ycmVzcG9uZGluZyBjb2RlIHRvIHRoZSBhZGRyZXNzIHdvdWxkIHJlbWFpbiBi dXQgbmV2ZXIgYmUgdXNlZC4KPC9wPgo8YSBuYW1lPSJyZmMucmVmZXJlbmNlczEiPjwvYT48YnIg Lz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIyIiBjbGFzcz0iYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9ImJ1ZyI+PGEg aHJlZj0iI3RvYyIgY2xhc3M9ImxpbmsyIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwv dGFibGU+CjxoMz42LiZuYnNwO0luZm9ybWF0aXZlIFJlZmVyZW5jZXM8L2gzPgo8dGFibGUgd2lk dGg9Ijk5JSIgYm9yZGVyPSIwIj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0i dG9wIj48YSBuYW1lPSJJU08gMzE2Ni0yIj5bSVNPIDMxNjYtMl08L2E+PC90ZD4KPHRkIGNsYXNz PSJhdXRob3ItdGV4dCI+SW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXph dGlvbiwgJmxkcXVvO0NvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2YgY291 bnRyaWVzIGFuZCB0aGVpciBzdWJkaXZpc2lvbnMgLS0gUGFydCAyOiBDb3VudHJ5IHN1YmRpdmlz aW9uIGNvZGUsJnJkcXVvOyAxOTk4LjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRl eHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJKSVMgWCAwNDAxIj5bSklTIFggMDQwMV08L2E+PC90 ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+SmFwYW4gSW5kdXN0cmlhbCBTdGFuZGFyZCwgJmxk cXVvO1RvLURvLUZ1LUtlbiAoUHJlZmVjdHVyZSkgSWRlbnRpZmljYXRpb24gQ29kZSwmcmRxdW87 IEFwcmlsJm5ic3A7MTk3My48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2 YWxpZ249InRvcCI+PGEgbmFtZT0iSklTIFggMDQwMiI+W0pJUyBYIDA0MDJdPC9hPjwvdGQ+Cjx0 ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkphcGFuIEluZHVzdHJpYWwgU3RhbmRhcmQsICZsZHF1bztJ ZGVudGlmaWNhdGlvbiBjb2RlIGZvciBjaXRpZXMsIHRvd25zIGFuZCB2aWxsYWdlcywmcmRxdW87 IERlY2VtYmVyJm5ic3A7MjAwMy48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0 IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iTEFTREVDIj5bTEFTREVDXTwvYT48L3RkPgo8dGQgY2xh c3M9ImF1dGhvci10ZXh0Ij5Mb2NhbCBBdXRob3JpdGllcyBTeXN0ZW1zIERldmVsb3BtZW50IENl bnRlciwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly93d3cubGFzZGVjLm5pcHBvbi1uZXQubmUuanAv aXBkL2lwMy9pbmRleF90b3AuaHRtbCI+Q2hhcmFjdGVyaXN0aWNzIG9mIFplbmtva3UgTWFjaGkt QXphIEZpbGU8L2E+LiZyZHF1bzs8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0 IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iTUlDIGRyYWZ0IHJlcG9ydCI+W01JQyBkcmFmdCByZXBv cnRdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPlRoZSBNaW5pc3RyeSBvZiBJbnRl cm5hbCBBZmZhaXJzIGFuZCBDb21tdW5pY2F0aW9ucywgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly93 d3cuc291bXUuZ28uanAvam9ob190c3VzaW4vZW5nL1JlbGVhc2VzL1RlbGVjb21tdW5pY2F0aW9u cy9uZXdzMDUwMTI4XzcuaHRtbCI+ZHJhZnQgcmVwb3J0IGNvbmNlcm5pbmcgTWVhc3VyZXMgZm9y IFByZXNlcnZpbmcgSW1wb3J0YW50IENvbW11bmljYXRpb25zIFN1Y2ggYXMgRW1lcmdlbmN5IE1l c3NhZ2VzIG9uIElQIE5ldHdvcmtzPC9hPiwmcmRxdW87IEphbnVhcnkmbmJzcDsyMDA1LjwvdGQ+ PC90cj4KPC90YWJsZT4KCjxhIG5hbWU9InJmYy5hdXRob3JzIj48L2E+PGJyIC8+PGhyIC8+Cjx0 YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xh c3M9ImJ1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJidWciPjxhIGhyZWY9IiN0b2Mi IGNsYXNzPSJsaW5rMiI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8aDM+ QXV0aG9ycycgQWRkcmVzc2VzPC9oMz4KPHRhYmxlIHdpZHRoPSI5OSUiIGJvcmRlcj0iMCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQi PiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkhpZGVraSBBcmFpPC90ZD48L3Ry Pgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRo b3ItdGV4dCI+QXZheWEgSmFwYW4gTHRkLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9y LXRleHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjItMTctNyBBa2FzYWth PC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNs YXNzPSJhdXRob3ItdGV4dCI+TWluYXRvLWt1LCBUb2t5byAgMTA3LTAwNTI8L3RkPjwvdHI+Cjx0 cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10 ZXh0Ij5KYXBhbjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yIiBhbGlnbj0icmlnaHQi PkVtYWlsOiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0 bzphcmFpQGF2YXlhLmNvbSI+YXJhaUBhdmF5YS5jb208L2E+PC90ZD48L3RyPgo8dHIgY2VsbHBh ZGRpbmc9IjMiPjx0ZD4mbmJzcDs8L3RkPjx0ZD4mbmJzcDs8L3RkPjwvdHI+Cjx0cj48dGQgY2xh c3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5Nb3Rv aGFydSBLYXdhbmlzaGk8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJz cDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5Pa2kgRWxlY3RyaWMgSW5kdXN0cnkgQ28u LCBMdGQuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4K PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+NC0xMC0xNiBTaGliYXVyYTwvdGQ+PC90cj4KPHRyPjx0 ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQi Pk1pbmF0by1rdSwgVG9reW8gIDEwOC04NTUxPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRo b3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+SmFwYW48L3RkPjwv dHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvciIgYWxpZ249InJpZ2h0Ij5FbWFpbDombmJzcDs8L3Rk Pgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86a2F3YW5pc2hpMzgxQG9r aS5jb20iPmthd2FuaXNoaTM4MUBva2kuY29tPC9hPjwvdGQ+PC90cj4KPC90YWJsZT4KPGEgbmFt ZT0icmZjLmNvcHlyaWdodCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0 IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJidWciIGFsaWduPSJyaWdo dCI+PHRyPjx0ZCBjbGFzcz0iYnVnIj48YSBocmVmPSIjdG9jIiBjbGFzcz0ibGluazIiPiZuYnNw O1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGgzPkludGVsbGVjdHVhbCBQcm9wZXJ0 eSBTdGF0ZW1lbnQ8L2gzPgo8cCBjbGFzcz0nY29weXJpZ2h0Jz4KVGhlIElFVEYgdGFrZXMgbm8g cG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkKSW50ZWxsZWN0 dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVk CnRvIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9n eQpkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBs aWNlbnNlCnVuZGVyIHN1Y2ggcmlnaHRzIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7 IG5vciBkb2VzIGl0CnJlcHJlc2VudCB0aGF0IGl0IGhhcyBtYWRlIGFueSBpbmRlcGVuZGVudCBl ZmZvcnQgdG8gaWRlbnRpZnkgYW55CnN1Y2ggcmlnaHRzLgpJbmZvcm1hdGlvbiBvbiB0aGUgcHJv Y2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8KcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlIGZv dW5kIGluIEJDUCZuYnNwOzc4IGFuZCBCQ1AmbmJzcDs3OS48L3A+CjxwIGNsYXNzPSdjb3B5cmln aHQnPgpDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJp YXQgYW5kIGFueQphc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLApv ciB0aGUgcmVzdWx0IG9mIGFuIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vu c2Ugb3IKcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZiBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBi eSBpbXBsZW1lbnRlcnMgb3IKdXNlcnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRh aW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSCnJlcG9zaXRvcnkgYXQgPGEgaHJlZj0naHR0 cDovL3d3dy5pZXRmLm9yZy9pcHInPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByPC9hPi48L3A+Cjxw IGNsYXNzPSdjb3B5cmlnaHQnPgpUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5 IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24KYW55IGNvcHlyaWdodHMsCnBhdGVudHMgb3IgcGF0 ZW50IGFwcGxpY2F0aW9ucywKb3Igb3RoZXIKcHJvcHJpZXRhcnkgcmlnaHRzIHRoYXQgbWF5IGNv dmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQKdG8gaW1wbGVtZW50IHRoaXMgc3Rh bmRhcmQuClBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdCA8YSBo cmVmPSdtYWlsdG86aWV0Zi1pcHJAaWV0Zi5vcmcnPmlldGYtaXByQGlldGYub3JnPC9hPi48L3A+ CjxoMz5EaXNjbGFpbWVyIG9mIFZhbGlkaXR5PC9oMz4KPHAgY2xhc3M9J2NvcHlyaWdodCc+ClRo aXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92 aWRlZApvbiBhbiAmbGRxdW87QVMgSVMmcmRxdW87IGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1Is ClRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMgT1IgSVMgU1BPTlNPUkVEIEJZIChJ RiBBTlkpLApUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5H IFRBU0sgRk9SQ0UgRElTQ0xBSU0KQUxMIFdBUlJBTlRJRVMsCkVYUFJFU1MgT1IgSU1QTElFRCwK SU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9G IFRIRQpJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBB TlkgSU1QTElFRApXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBB IFBBUlRJQ1VMQVIgUFVSUE9TRS48L3A+CjxoMz5Db3B5cmlnaHQgU3RhdGVtZW50PC9oMz4KPHAg Y2xhc3M9J2NvcHlyaWdodCc+CkNvcHlyaWdodCAmY29weTsgVGhlIEludGVybmV0IFNvY2lldHkg KDIwMDUpLgpUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gdGhlIHJpZ2h0cywKbGljZW5zZXMg YW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQJm5ic3A7NzgsCmFuZCBleGNlcHQgYXMg c2V0IGZvcnRoIHRoZXJlaW4sCnRoZSBhdXRob3JzIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLjwv cD4KPGgzPkFja25vd2xlZGdtZW50PC9oMz4KPHAgY2xhc3M9J2NvcHlyaWdodCc+CkZ1bmRpbmcg Zm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUK SW50ZXJuZXQgU29jaWV0eS48L3A+CjwvYm9keT48L2h0bWw+Cgo= --EGBSE.AT4G6UESMTE.MWEAMV4GBA Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --EGBSE.AT4G6UESMTE.MWEAMV4GBA-- From ecrit-bounces@ietf.org Sat May 14 22:09:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DX8Zh-0000tA-PJ; Sat, 14 May 2005 22:09:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DX8Zf-0000t1-M9 for ecrit@megatron.ietf.org; Sat, 14 May 2005 22:09:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25272 for ; Sat, 14 May 2005 22:09:45 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DX8pt-0007ii-59 for ecrit@ietf.org; Sat, 14 May 2005 22:26:34 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 14 May 2005 19:09:36 -0700 X-IronPort-AV: i="3.93,109,1115017200"; d="scan'208"; a="265330192:sNHT38019024" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4F29YPo011760 for ; Sat, 14 May 2005 19:09:35 -0700 (PDT) Received: from jmpolk-wxp.diablo.cisco.com (sjc-vpn6-455.cisco.com [10.21.121.199]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA22011 for ; Sat, 14 May 2005 19:09:34 -0700 (PDT) Message-Id: <4.3.2.7.2.20050514210418.02d97ce8@diablo.cisco.com> X-Sender: jmpolk@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 14 May 2005 21:09:33 -0500 To: ecrit@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39821207e2a2cade5c69c89d23fb80ee Subject: [Ecrit] (114) Comments on ECRIT Reqs ID (part I) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org All [*** this is part 1 of a 2 part message to the list - since I received an error posting a message that exceeded 40k, the break between parts is at section 6 of the ID] I reviewed the requirements ID draft-schulzrinne-ecrit-requirements-00.txt for the meeting this coming week, and have a few comments.... ok, 114 comments.... listed.... below.... For those of you attending the interim, I will bring these up there. For those of you not attending the interim, chime in and be heard about this comments. My overall comment to this ID is it is taking on waaaaaay more than the WG charter intended, but I am not surprised. I know a lot of folks want to get specific items addressed here. Some of those items I feel should be addressed elsewhere. Anyway, to the comments - here they are in the order they appear in the doc with one exception, the last one. The last one should be addressed somewhere, and I do not know if it should only be addressed in http://www.ietf.org/internet-drafts/draft-ietf-sipping-location-requirements-02.txt and its next version in the SIP WG. The comments: [note to ID authors - I know this is a group effort, so do not take my use of the word "you" personally] The following is a review of draft-schulzrinne-ecrit-requirements-00 on May 14th, 2005 Comment #1 Section 2 - Terminology - top paragraph "MUSTNOT", "SHALLNOT", "SHOULDNOT" are all 2 words each Comment #2 Section 2 - Terminology - 2nd paragraph "protocols" should be singular Comment #3 Section 2 - Terminology - term When did IAP become AIP? IAP and ISP flowed and should be retained. Comment #4 Section 2 - Terminology - term basic emergency service - should be capitalized Comment #5 Section 2 - Terminology - term "domain" should be renamed "administrative domain" Comment #6 Section 2 - Terminology - term You mention "IPSAP" before defining it, and don't state you will define it below like you do other terms. Some call this an IP-PSAP, not an IPSAP, BTW... Comment #7 Section 2 - Terminology - term emergency caller: The user or user device entity needing sending his/ her location to another entity in the network. "...needing sending..." is poor wording Comment #8 Section 2 - Terminology - term emergency caller: The user or user device entity needing sending his/ her location to another entity in the network. The "emergency caller" is "the individual in distress desiring help". Comment #9 Section 2 - Terminology - term geographic coordinate system - you fail to mention "a defined meridian", which should be added to the definition Comment #10 R2. International: The protocols and protocol extensions developed MUST support regional, political and organizational differences. Motivation: It must be possible for a device or software developed... This "must" in the motivation should be a MUST as it talks normatively Comment #11 R5. Minimum Connectivity: NEED REQUIREMENT HERE Motivation: If there is network connectivity between the emergency caller and the PSAP, and routing information is available, the call should be completed, even if other parts of the network are not reachable. This makes little sense, because if there is connectivity, there is a route, yet the wording seems to believe there might not be (which means there is "no connectivity") Comment #12 R6. Incremental Deployment Emergency calls from IP-based devices MUST be incrementally supported. This wording doesn't make sense; should it be: "R6 Incremental Deployment - incremental deployment of IP-based emergency calling MUST be supported" Comment #13 "R6 Motivation: Any mechanism must be deployable incrementally and work even if not all entities support IP-based emergency calling. For example, User agents conforming to the SIP specification [1], but unaware of this document, must be able to place emergency calls, possibly with restricted functionality." This ID professes that it all about IP e2e connectivity, yet this states it isn't really necessary. Which is it? This motivation, or the wording in the Intro section? Comment #14 R7. Middlebox Reliance: For a transient time the device and the UA MAY use the help of servers (e.g. ESRP) to provide the connectivity to ECC, especially for ECC not yet connected to the Internet. Same as comment to #13 - This ID professes that it all about IP e2e connectivity, yet this states it isn't really necessary. Which is it? This motivation, or the wording in the Intro section? Comment #15 R7 Motivation: Emergency calling mechanisms must support existing emergency call centers based on circuit-switched technology as well as future ECCs that are IP-enabled. This motivation statement clearly contradicts the Intro section (stating this is for IP e2e scenarios). Comment #16 A2. Local: Since many countries have already deployed national emergency identifiers, such as 911 in North America and 112 in large parts of Europe, UAs, proxies and call routers MUST recognize these universal emergency identifiers, but MAY NOT recognize lower level local emergency identifiers, including those such as 999, 122, 133, etc. In addition, these same call routing entities SHOULD recognize emergency identifiers that are used in other jurisdictions I don't understand this one as written, as there are ~60 different numbers around the world, we should list which ones are recommended for support and discuss the list. Primary examples are 115, 116, 117 etc for different emergency services within the same jurisdiction. Comment #17 A2. Local - [Ed. The requirement A2 is really a set of 3 requirements, and needs to have the question answered which is: "what does the term "local" mean?".] Good question... Comment #18 A2 Motivation: The latter requirement is meant to help travelers that may not know the local emergency number and instinctively dial the number they are used to from home. However, it is unlikely that all systems could be programmed to recognize any emergency number used anywhere as some of these numbers are used for non-emergency purposes, in particular extensions and service numbers. What is meant by this last phrase: "... in particular extensions and service numbers." Comment #19 A3. Recognizable: Emergency calls MUST be recognizable by user agents, proxies and other network elements. To prevent fraud, an address identified as an emergency number for call features or authentication override MUST also cause routing to a PSAP. Recommend replacing some of the last sentence with: "...any call recognized as an emergency call MUST be delivered expeditiously to an ECC". Comment #20 A5. Secure configuration: Devices SHOULD be assured of the correctness of the local emergency numbers that are automatically configured. How do you "assure a device" without asserting something that requires a key the remote and local domains understand, as well as the UA understands? Comment #21 A6. Backwards-compatible: Existing devices that predate the specification of emergency call-related protocols and conventions MUST be able reach a PSAP. I've read this above somewhere else in the ID. If a PIDF-LO is required to complete a 911 call, and it isn't present, and the device doesn't support the error messages from draft-ietf-sipping-location-requirements-02.txt, how can this work? I think this can work in residential and SMB scenarios, but I'm not sure about any others. VPNs in those other network types is but one reason for these problems. Comment #22 A7. Common Identifier: User initiated requests using local initiation methods (e.g. 9-1-1) MUST be supported across non-local domains (e.g. foreign countries). This is stated too US-centric. The IETF isn't about a country. This should state that all/most recognizable local emergency numbers will be converted to (perhaps) one SIP user-part for all SIP intermediaries to know to process accordingly. Comment #23 A7 Motivation: While traveling, users must be able to use their familiar "home" emergency identifier. Users should also be able to dial the local emergency number in the country they are visiting. Looking at the range of potential numbers, this will be interesting to meet - including just dialing '0' and meaning an emergency call Comment #24 Section 5 Proxy-inserted: A proxy along the call path inserts the location or location reference. This violates 3261 and draft-ietf-sipping-location-requirements-02.txt Comment #25 L1. Multiple location services: For UA-referenced locations, PSAPs MUST be able to access different location providers. The location provider may be tied to the ASP, AIP or ISP or may be independent of these entities. This may be inside an enterprise, and that should not be underscored or overlooked due to the trust-boundary issues known there Comment #26 L1 Motivation: This requirement avoids that all users have to rely on a single location service provider. This requirement is hard to avoid if there are no traditional national application-layer service providers. I don't understand the first sentence as written, especially since this ID just got done talking about internationalization scope. Comment #27 L2. Civic and Geographic: Where available, both civic (street address) and geographic (longitude/latitude) information SHOULD be provided to the PSAP. This necessitates a PIDF-LO extension to indicate if one was derived from the other. That XML element doesn't exist to my knowledge. Comment #28 L2 Motivation: While geographic coordinate information can usually be translated into civic address location information, "some specific information, such as building number and floor, is more easily provided as civic location information since it does not require a detailed surveying operation". For direct location determination, it may also be easier for the user to check civic location information to assure verity. I don't understand the quoted comment (I put in the quotes BTW) in the first sentence above. Is this suggesting a detailed survey *will* yield the cube number from a GPS coordinate on a non-ground floor? If it won't, it doesn't need to be brought up as motivation. Comment #29 L3. Location source identification: The source of a location data, whether measured, derived (e.g geocoding or reverse geocoding transformation), or manually input, MUST be indicated to the PSAP. How is this not covered by the element in the PIDF-LO, and if so, why is the requirement not just "...the element MUST be present when known"... Comment #30 L3 Motivation: This allows the PSAP to better judge the reliability and accuracy of the data and track down problems. I don't believe the word "judge" is appropriate here, as the PSAPs first need to "learn" (a better word for above) from real world experience what data indicates what results. Down the road, they will then analyze trends and such to determine how best to interpret data. Comment #31 L4. Certifiable: In some cases, the source and generation time of the location object used for call routing and caller location display MUST be verifiable, e.g., by a digital signature. The security requirements describe this in more detail. If my wireline phone has a timestamp of 2002, is that bad/untrusted? I don't believe so. This requirement needs to be adjusted to state this is a function of the the location was derived from. Further, a future document (perhaps years from now) needs to be generated to give recommendations of those functions per value. Comment #32 L5. Multiple locations: Multiple locations MAY be associated with the caller How is this requirement different that L2? If it can be different, then this text needs to state when/how it can be different, yet still be considered good. Comment #33 L5 Motivation: Multiple locations may occur either because the caller has provided more than one civic or geographic (coordinates) location, supplies both civic and geospatial location information, or because different location determination entities make different assessments of the caller's location." There needs to be a requirement stating if there is location information in both formats, and both are depicting the same location (as far as the UA is concerned), they MUST be in the same PIDF-LO; if different - or not sure they are the same location, they need to be in separate PIDF-LOs (typically with different values). Comment #34 L5 Motivation: Multiple locations may occur either because the caller has provided more than one civic or geographic (coordinates) location, supplies both civic and geospatial location information, or because different location determination entities make different assessments of the caller's location." If there are more than one, and they are different, which is trusted to be true? Comment #35 L6. Validation of civic location: It MUST be possible to validate an address prior to its use in an actual emergency call. How is "validate" here in L6 different from "certifiable" in L4? Comment #36 L6. Validation of civic location: It MUST be possible to validate an address prior to its use in an actual emergency call. "... prior to its use in an actual emergency call." should be replaced with: "at any time" only. And...it's an implementation issue when this occurs, so I'm not sure this belongs in the ID. Someone like NENA should be defining this type of requirement. Comment #37 L7. Provide location: Calls using VoIP or subsequent methods MUST supply location with the call. "... with the call" should be replaced with: "...in each Request message (if SIP is used)." Comment #38 L8. Accept two location types: PSAPs shall accept location as civic and/or geo specified. [Ed. Suggest deleting above requirement since it doesn't deal with routing] I disagree with the Ed. Comment because this (as written) limits how many different formats a routing Proxy forwards, and how many formats an ECC has to deal with. The same piece of location information (if in a PIDF-LO) will be used for routing and dispatching. Limiting the number to two here is good. Comment #39 L9. Altitude included with location: All representations of location SHALL include the ability to carry altitude. This requirement does not imply altitude is always used or supplied. Either it does or it doesn't, but "include the ability..." is wishy-washy Comment #40 L10. Preferred datum: The preferred geographic coordinate system for emergency calls SHALL be WGS-84. 2D or 3D? Comment #41 L11. Multiple locations: If multiple locations are provided with a call, it SHOULD be possible to identify the most accurate, current, appropriate location information to be used for routing emergency calls and dispatching emergency responders. Exactly how will this be accomplished, especially by a Proxy? This is fruitless, therefore pointless. L2 should be all that is stated for this type of requirement. Comment #42 L14. Imprecise location: Imprecise location information MUST be available for emergency call routing and location delivery in cases where precise measurement based location determination mechanisms fail. How is "imprecise location" indicated to the PSAP as "imprecise"? If it cannot be, it shouldn't be a requirement. Comment #43 L15. Default identification: PSAPs MUST be made aware when imprecise location information was used to route a call. Same comment here that was to L14 - How is "imprecise location" indicated by the proxy to the PSAP as "imprecise"? If it cannot be, it shouldn't be a requirement. Comment #44 L16. Location Responsibility: Location determination MUST assume a responsible party. This is begging for liability statements to be included every time a location is given to a device, that it should not be used unless the user agrees "not to hold the deliverer responsible" before usage. Comment #45 L17 Motivation: The location information MUST be attributed to a specific point in time. That is, the location used for routing and which is reported to the PSAP call taker, must be the actual location of the caller at the time of making the call. This makes learning/getting/retrieving location a real-time event as the emergency call is being initiated - and this is not practical. If my home wireline phone has a timestamp of 2002, is that bad? Comment #46 L18. Location, Emergency Caller: Location provided with call MUST be associated with an Emergency Caller. Huh? This is to a device, one in which a user might not be logged into. Comment #47 L19 Motivation: Requirement 1 states that a level of authentication and validation for the source of the location is required. This implies the need to for the Emergency Caller to determine the authenticating and validating entity for the emergency services domain in which they reside. That is, it must be possible for an Emergency Caller to discover and utilize an answerable source of location in the access network they are using. The term in the 1st sentence "level" needs to be defined in order to understand if it is met. Level is not currently defined within this ID. Comment #48 L19. Location Domain Availability: Location domain MUST be obtainable by Emergency Caller. Motivation: Requirement 1 states that a level of authentication and validation for the source of the location is required. This implies the need to for the Emergency Caller to determine the authenticating and validating entity for the emergency services domain in which they reside. That is, it must be possible for an Emergency Caller to discover and utilize an answerable source of location in the access network they are using. "Emergency Caller" as used in the 1st sentence - I personally don't care who the authority is, and I doubt most (if any) do outside of this list and some regulators. Comment #49 L19. Location Domain Availability: Location domain MUST be obtainable by Emergency Caller. Motivation: Requirement 1 states that a level of authentication and validation for the source of the location is required. This implies the need to for the Emergency Caller to determine the authenticating and validating entity for the emergency services domain in which they reside. That is, it must be possible for an Emergency Caller to discover and utilize an answerable source of location in the access network they are using. This last sentence isn't clear. Provide an example of me discovering an "answerable source" so I can visualize it. Comment #50 L20. Location Certification: Location provided MUST be certified. This doesn't account for a GPS chip in a PDA or cell phone, therefore this cannot be a MUST. Comment #51 L20 Motivation: The Emergency Caller must be able to establish a session with the access domain authenticating and validating entity to obtain a certified location. The authentication of the location is granted with an expiry time, after which the location within the domain is deemed invalid. "INVALID"? This is starting to look an awful lot like a DHCP lease operation, and we're not building a protocol to do this here. Comment #52 L21. Location and Emergency Caller Identity: It MUST NOT be assumed that Emergency Caller identity provided with location is true identity of Emergency Caller. This contradicts L18 Comment #53 L22. Location Acceptability: Location provided by Emergency Caller MUST be considered acceptable as input to authentication and validation entity. This isn't really clear. Location should be in a certain format, and there is a 'the' missing in the requirement. Comment #54 L22. Location Acceptability: Location provided by Emergency Caller MUST be considered acceptable as input to authentication and validation entity. I see no requirement creating an "authentication and validation entity" which this requirement assumes already exists for every user. Comment #55 L24. Location Query Authorization: The ability to query emergency caller location using a location key MUST be limited to authorized end points. "end points" (which is one word BTW) Should be replaced with: "requests" Comment #56 L24 Motivation: Where the Emergency Caller does not desire the transmission of their location in-band with their call setup, they shall have the option of requesting a unique query key such that only authorized end points may query the location directly from the domain. As stated above: "end points" (which is one word) Should be replaced with: "requests" As "endpoints" implies the actual device has an SA relationship with the database server, which may not be the case, and only the user created an SA from a log-in screen. This is a two level operation. Comment #57 L25. Location Domain Authorization: Location Source entity MUST be authorized within the access domain. This is starting to create an architecture now... and I think this is starting to overstep some bounds of the charter and belongs more in NENA than IETF Comment #58 L26. Endpoint Location: Location MUST be tied to an endpoint within the access domain at the time of an emergency call. GPSs violate this, so this cannot be a MUST - see L27 below L27. Location Sources: Single source of location MUST NOT be assumed. Motivation: To achieve this, the end user device MUST be able to retrieve its current location from the access provider, from the infrastructure, via GPS, ... or as last resort, from the user itself. Comment #59 L28. Location Provided: Endpoint location SHOULD be provided to ECC. This needs to be restated as "if location is provided to the routing proxy, it MUST be provided to the ECC. cheers, James ******************* Truth is not to be argued... it is to be presented. Alas, few *truths* exist without the math. ...all else is a matter of perspective _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 14 22:13:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DX8aG-00010a-0n; Sat, 14 May 2005 22:10:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DX8aD-00010N-TM for ecrit@megatron.ietf.org; Sat, 14 May 2005 22:10:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25368 for ; Sat, 14 May 2005 22:10:19 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DX8qS-0007kC-P9 for ecrit@ietf.org; Sat, 14 May 2005 22:27:09 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 14 May 2005 19:10:12 -0700 X-IronPort-AV: i="3.93,109,1115017200"; d="scan'208"; a="265330406:sNHT39309996" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4F2A7Po011899 for ; Sat, 14 May 2005 19:10:07 -0700 (PDT) Received: from jmpolk-wxp.diablo.cisco.com (sjc-vpn6-455.cisco.com [10.21.121.199]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA22421 for ; Sat, 14 May 2005 19:10:06 -0700 (PDT) Message-Id: <4.3.2.7.2.20050514210355.0206cdb8@diablo.cisco.com> X-Sender: jmpolk@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 14 May 2005 21:09:26 -0500 To: ecrit@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b271b9c4fc51b08326fa0949e61c0156 Subject: [Ecrit] (114) Comments on ECRIT Reqs ID (part II) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org All [*** this is part 2 of a 2 part message to the list - since I received an error posting a message that exceeded 40k, the break between parts is at section 6 of the ID] Comment #60 6. Identifying the Appropriate Emergency Call Center From the previous section, we take the requirement of a single (or small number of) emergency addresses which are independent of the caller's location. However, since for reasons of robustness, jurisdiction and local knowledge, PSAPs only serve a limited geographic region, having the call reach the correct PSAP is crucial. While a PSAP may be able to transfer an errant call, any such transfer is likely to add tens of seconds to call setup latency and is prone to errors. (In the United States, there are about 6,100 PSAPs.) I'd like to see the data justifying this last claim of 10s of seconds statement going forward with IP. Comment #61 6. Identifying the Appropriate Emergency Call Center From the previous section, we take the requirement of a single (or small number of) emergency addresses which are independent of the caller's location. However, since for reasons of robustness, jurisdiction and local knowledge, PSAPs only serve a limited geographic region, having the call reach the correct PSAP is crucial. While a PSAP may be able to transfer an errant call, any such transfer is likely to add tens of seconds to call setup latency and is prone to errors. (In the United States, there are about 6,100 PSAPs.) And only about 600 regions, so this might not be so hard with IP and endpoint provided location Comment #62 Section 6, second paragraph at the end: A UA could conceivably store a complete list of all PSAPs across the world, but that would require frequent synchronization with a master database as PSAPs merge or jurisdictional boundaries change. "change"? This likely isn't so often, BTW Comment #63 Section 6, forth paragraph: Note that the first proxy, the ESRP, doing the translation may not be in the same geographic area as the UA placing the emergency call. "...the first proxy, the ESRP..." Does this assume that any proxy that can route based on the location of the caller is an ESRP? Comment #64 I4. Choice of IPSAPs: The emergency caller SHOULD be provided a choice of emergency call centers if more than one exists and is relevant. This gets into defining what an ECC is (which hasn't been done yet), and that if another number is dialed, it doesn't constitute an emergency call IMO. Comment #65 I5. Assuring IPSAP identity: The emergency caller SHOULD be able to determine conclusively that he has reached an accredited emergency call center. How can this possibly be done? If my display says "Dallas Police Dept." , do I trust it, or do I take the time to verbally question the identity of the calltaker? Do we suggestion questions to be asked to verify the identity of the calltaker? Comment #66 I5 Motivation: This requirement is meant to address the threat that a rogue, possibly criminal, entity pretends to accept emergency calls. How can't this be easily faked? Comment #67 I6. Warnings for unidentifiable IPSAP. Implementations SHOULD allow callers to proceed, with appropriate warnings or user confirmations, if the identity of the destination IPSAP cannot be verified. How is this verified without there being a root key installed in all UAs? Comment #68 I7. Traceable resolution: Particularly for mediated resolution, the caller SHOULD be able to definitively and securely determine who provided the emergency address resolution information. Is this suggesting that all Proxies must remain post transaction/dialog stateful to the user for them to later investigate something? For how long after? Comment #69 I10. Incrementally deployable: An Internet-based emergency call system MUST be able to be deployed incrementally. In the initial stages of deployment, an emergency call may not reach the optimal PSAP. If allowed, emergency calls must only be routed to PSAPs that have agreed to accept non-optimally routed calls. [Ed. Can this be merged with R6?] yes Comment #70 I11. ECC Availability: ECC communication MUST be continuously available. Motivation: From any Internet-connected device it MUST be possible at any time to contact the ECC responsible for the current location with the most appropriate method for communication for the user and the device. is this the famous five 9s? Comment #71 I13. Cross-Jurisdiction Device Support: Devices SHOULD support alternate emergency service systems between countries. Motivation: Even as each country is likely to operate their emergency calling infrastructure differently, SIP devices should be able to reach emergency help and, if possible, be located in any country. [Ed. above text needs clarification] yeah, this doesn't make much sense now Comment #72 I15: It MUST be possible to route a call based on either a civic or a geo location without requiring conversion from one to the other. This requirement does not prohibit an implementation from converting and using the resulting conversion for routing. how is this different from I14? Comment #73 I16: It MUST be possible for a designated 9-1-1 authority to a PSAP to approve of any geocoding database(s) used to assist in determining call routing to that PSAP. Mechanisms must be provided for the PSAP designated 9-1-1 authorities to test and certify a geocoding database as suitable for routing calls to the PSAP. The PSAP may choose to NOT avail itself of such a mechanism. This is implementation - and shouldn't be in here Comment #74 I17: It MUST be possible for the designated 9-1-1 authority to supply, maintain, or approve of databases used for civic routing. Mechanisms must be provided for a designated authority for a PSAP to test and certify a civic routing database as suitable for routing calls to that PSAP. This is implementation - and doesn't belong here Comment #75 I18: It MUST be possible for the PSAP itself (or a contractor it nominates on its behalf) to provide geocode and reverse geocode data and/or conversion services to be used for routing determination. This implies definition of a standard interchange format for geocode data, and protocols to access it. This has nothing to do with Routing the call, and shouldn't be in here. Comment #76 I20: Boundaries for civic routing MUST be able to be specific to a street address range, a side of a street (even/odd street addresses), a building within a "campus", or any of the location fields available. [Ed. Available from where? Please clarify. In the PIDF-LO I think Comment #77 I21: It MUST be possible to use various combined components of the location object for determination of routing. Some areas may only require routing to a country level, others to a state/province, others to a county, or to a municipality, and so on. No assumption should be made on the granularity of routing boundaries or about the combination of components used. The last sentence alone should be the requirement: "No assumption should be made on the granularity of routing boundaries or about the combination of components used." and the text above this sentence removed or used as explanation only. Comment #78 I22: Boundaries mechanisms for geo routing MUST be able to be specific to a natural political boundary, a natural physical boundary (such as a river), or the boundaries listed in the previous requirement. This is repetitive Comment #79 I23: Any given geographic location SHOULD result in identification of a unique governmentally-authorized PSAP entity for that location? This is repetitive Comment #80 I24: Routing databases using 9-1-1 Valid Addresses or lat/lon/ altitude as keys MUST both be available to all entities needing to route 9-1-1 calls. Too US centric Comment #81 I25: Carriers, enterprises and other entities that route emergency calls MUST be able to route calls from any location to its appropriate PSAP. "... to its appropriate PSAP should be replaced with "...towards its appropriate ECC." as the first proxy might no have enough knowledge to do it all Comment #82 I26: It MUST be possible for a given PSAP to decide where its calls should be routed. repetitive Comment #83 I27: It is desirable for higher level civic authorities such as a county or state/province to be able to make common routing decisions for all PSAPs within their jurisdiction. implementation - should be in NENA, not IETF For example, a state may wish to have all emergency calls placed within that state directed to a specific URI. This does NOT imply a single answering point; further routing may occur beyond the common URI. Comment #84 I28: Routing MAY change on short notice due to local conditions, traffic, failures, schedule, etc. this is true with anything IP based, what's the requirement? Comment #85 I32: Multiple types of failures MAY have different contingency routes. Is this a requirement? Comment #86 I33: It MUST be possible to provide more than one contingency route for the same type of failure. Duplicate of I31 Comment #87 I34: A procedure MUST be specified to handle "default route" capability when no location is available or the location information is corrupted. I34 and I35 state the same thing currently Comment #87 I35: Default routes MUST be available when location information is not available. I34 and I35 state the same thing currently Comment #88 I36: Entities routing emergency calls SHALL retain information used to choose a route for subsequent error resolution. "... retain information" for how long? Comment #89 I37: Access Infrastructure providers MUST provide a location object that is as accurate as possible when location measurement or lookup mechanisms fail. "... MUST provide a location object". This is stated incorrectly, the AIP doesn't give the UA its PIDF-LO, it gives it an LCI in most cases. The UA builds/generates the PIDF-LO. Comment #90 I38: Location available at the time that the call is routed MAY not be accurate. Is this a requirement? It's not written as one Comment #91 I39: It SHOULD be possible to have updates of location (which may occur when measuring devices provider early, but imprecise "first fix" location) which can change routing of calls. "... updates of location"... This is a duplicate (L13) Comment #92 7. Emergency Address Directory General comment on this whole section - isn't this sufficiently in the background that this is "architecture" and not "identification" or "routing" in that it doesn't belong in the IETF (but more like NENA)? Comment #93 D1. ECC Identification: Public access to ECC selection information MUST be assumed. Need to mention this is "read only" access Comment #94 D2. Assuring directory identity: The query agent (e.g UA or server) MUST be able to assure that it is querying the intended directory. Without a shared key exchange (ensuring the correct destination is contacted), how can this be accomplished? Comment #95 D3. Query response integrity: The query agent MUST be able to be confident that the query or response has not been tampered with. Suggested rewrite to: "The query agent MUST take appropriate steps to ensure the query or response maintained integrity." Comment #96 D4. Assurance of Update integrity: Any update mechanism for the directory MUST ensure that only authorized users can change directory information and must keep an audit log of all change transactions. This smells like an architectural implementation requirement, therefore it doesn't belong here Comment #97 D6. Multiple directories: A UA or proxy SHOULD be able to use multiple (separate) directories to resolve the emergency identifier. If this can ever be manually entered in a UA or a network server to then be distributed to that network's UAs, then this requirement needs to be opened up to "UA or Proxy or other server SHOULD..." Comment #98 D7. Referral: All directories SHOULD refer out-of-area queries to an appropriate default or region-specific directory. Not sure how this applies to ECRIT Comment #99 D8. Multiple query protocols: Directories MAY support multiple query protocols. What does this have to do with routing or identification? Comment #100 D9. Baseline query protocol: A mandatory-to-implement protocol MUST be specified. Suggested rewording: " A single mandatory-to-implement protocol MUST be specified. Other optional protocols may be listed to give guidance if another protocol is preferred." Comment #101 C1. Identity: The system SHOULD allow (but not force) the identification of both the caller's identity and his or her terminal network address. Doesn't this violate a previous requirement stating the caller's identity cannot be assumed (L21). Plus the definition of "basic emergency service" states this. Comment #102 C2. Privacy override: The end system MUST be able to automatically detect that a call is an emergency call and override any privacy settings that conflict with emergency calling. This doesn't go deep enough into how a jurisdiction may limit how private a caller can remain when calling an ECC. Or the opposite can be true. Comment #103 C3. Recontacting Endpoint: The ECC SHOULD have the capability to recontact the initiating endpoint after disconnection. Retitle "Reestablish Communication with Endpoint" Comment #104 C3 Motivation: Capability to re-contact the contacting device from the ECC in case of disruption or later query for a tbd period of time. This should also be possible from conventional ECC via temporary (virtual) E.164 numbers. All IP means you cannot assume E.164. Comment #105 S1. Authentication override: All outbound proxies and other call filtering elements MUST be able to be configured so that they allow unauthenticated emergency calls. Reword "... MUST be able to be configured..." to "...MUST be configurable..." Comment #106 S2. Mid-call features: The end system MUST be able to recognize an emergency call and allow configuration so that certain call features are not triggered accidentally. Reword " The end system MUST be able to recognize an emergency call and allow configuration so that certain call features are not triggered accidentally." To " The end system MUST recognize it initiated an emergency call and prevent certain call features that interfere with that call (e.g. call waiting, call hold)." Comment #107 In Just after S2 - there needs to be a requirement added stating something to the affect that "...once a UA initiates an emergency call, system resources SHOULD be prevented from certain call features that interfere with that call (e.g. Barge, call preemption). The latter example is for military or government networks. Comment #108 S3. Testable: A user SHOULD be able to test whether a particular address reaches the appropriate PSAP, without actually causing emergency help to be dispatched or consuming PSAP call taker resources. How can't this be faked? Comment #109 S6 Tracking and Tracing Facilities for all calls MUST be provided. This includes all routing entities as well as all signaling entities. "Facilities" reads like circuits and lines. What is meant here? Comment #110 S7 Each element in the signaling and routing paths solution SHALL maintain call detail records that can be accessed by management systems to develop call statistics in real time. Does it really need to be in real-time? Are we talking RTCP statistics? Is this something CALEA would want? How far towards the UAC can a ECC Net Mgmt station gain access to SIP element CDR information? How doesn't this look like a means of attack into an enterprise? Comment #111 S8 Each element of the signaling and routing paths SHALL provide congestion controls. We're talking RSVP and/or MPLS now? Diffserv doesn't do this, and the ECN proposal from Nortel is getting some pushback from Sally Floyd and Fred Baker. Comment #112 S9 It SHALL be possible to determine the complete call chain of a call, including the identity of each signaling element in the path, and the reason it received the call (Call History). We're talking RSVP and/or MPLS now? Diffserv doesn't do this, and the ECN proposal from Nortel is getting some pushback from Sally Floyd and Fred Baker. Comment #113 10. Supplemental Information Owner of the structure or tenant? Where is this in our Charter? SOMETHING TO ADD TO THIS DOCUMENT It is the case in Sweden that when a person calls for emergency help, they MUST provide two different locations in the call set-up. #1 - they MUST provide the location they are calling from (in civic or coordinate format); #2 - they MUST provide their billing location (where they personally receive their bills from. The next version of draft-ietf-sipping-location-requirements-02 (in the SIP WG) will account for this. But I on't know if should only be mentioned there. cheers, James ******************* Truth is not to be argued... it is to be presented. Alas, few *truths* exist without the math. ...all else is a matter of perspective _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun May 15 16:41:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXPvp-0005e7-6f; Sun, 15 May 2005 16:41:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DX8R3-0007Qy-C5 for ecrit@megatron.ietf.org; Sat, 14 May 2005 22:00:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24051 for ; Sat, 14 May 2005 22:00:50 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DX8hH-0007PO-8Z for ecrit@ietf.org; Sat, 14 May 2005 22:17:40 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 14 May 2005 19:00:42 -0700 X-IronPort-AV: i="3.93,109,1115017200"; d="scan'208"; a="265327932:sNHT44954476" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4F20cER021809 for ; Sat, 14 May 2005 19:00:39 -0700 (PDT) Received: from jmpolk-wxp.diablo.cisco.com (sjc-vpn6-455.cisco.com [10.21.121.199]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA18565 for ; Sat, 14 May 2005 19:00:39 -0700 (PDT) Message-Id: <4.3.2.7.2.20050514204240.02e2d3e8@diablo.cisco.com> X-Sender: jmpolk@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 14 May 2005 21:00:38 -0500 To: ecrit@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4675cbb5636f349448f668edcd96874c X-Mailman-Approved-At: Sun, 15 May 2005 16:41:46 -0400 Subject: [Ecrit] (114) Comments on ECRIT Reqs ID X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org All I reviewed the requirements ID draft-schulzrinne-ecrit-requirements-00.txt for the meeting this coming week, and have a few comments.... ok, 114 comments.... listed.... below.... For those of you attending the interim, I will bring these up there. For those of you not attending the interim, chime in and be heard about this comments. My overall comment to this ID is it is taking on waaaaaay more than the WG charter intended, but I am not surprised. I know a lot of folks want to get specific items addressed here. Some of those items I feel should be addressed elsewhere. Anyway, to the comments - here they are in the order they appear in the doc with one exception, the last one. The last one should be addressed somewhere, and I do not know if it should only be addressed in http://www.ietf.org/internet-drafts/draft-ietf-sipping-location-requirements-02.txt and its next version in the SIP WG. The comments: [note to ID authors - I know this is a group effort, so do not take my use of the word "you" personally] The following is a review of draft-schulzrinne-ecrit-requirements-00 on May 14th, 2005 Comment #1 Section 2 - Terminology - top paragraph "MUSTNOT", "SHALLNOT", "SHOULDNOT" are all 2 words each Comment #2 Section 2 - Terminology - 2nd paragraph "protocols" should be singular Comment #3 Section 2 - Terminology - term When did IAP become AIP? IAP and ISP flowed and should be retained. Comment #4 Section 2 - Terminology - term basic emergency service - should be capitalized Comment #5 Section 2 - Terminology - term "domain" should be renamed "administrative domain" Comment #6 Section 2 - Terminology - term You mention "IPSAP" before defining it, and don't state you will define it below like you do other terms. Some call this an IP-PSAP, not an IPSAP, BTW... Comment #7 Section 2 - Terminology - term emergency caller: The user or user device entity needing sending his/ her location to another entity in the network. "...needing sending..." is poor wording Comment #8 Section 2 - Terminology - term emergency caller: The user or user device entity needing sending his/ her location to another entity in the network. The "emergency caller" is "the individual in distress desiring help". Comment #9 Section 2 - Terminology - term geographic coordinate system - you fail to mention "a defined meridian", which should be added to the definition Comment #10 R2. International: The protocols and protocol extensions developed MUST support regional, political and organizational differences. Motivation: It must be possible for a device or software developed... This "must" in the motivation should be a MUST as it talks normatively Comment #11 R5. Minimum Connectivity: NEED REQUIREMENT HERE Motivation: If there is network connectivity between the emergency caller and the PSAP, and routing information is available, the call should be completed, even if other parts of the network are not reachable. This makes little sense, because if there is connectivity, there is a route, yet the wording seems to believe there might not be (which means there is "no connectivity") Comment #12 R6. Incremental Deployment Emergency calls from IP-based devices MUST be incrementally supported. This wording doesn't make sense; should it be: "R6 Incremental Deployment - incremental deployment of IP-based emergency calling MUST be supported" Comment #13 "R6 Motivation: Any mechanism must be deployable incrementally and work even if not all entities support IP-based emergency calling. For example, User agents conforming to the SIP specification [1], but unaware of this document, must be able to place emergency calls, possibly with restricted functionality." This ID professes that it all about IP e2e connectivity, yet this states it isn't really necessary. Which is it? This motivation, or the wording in the Intro section? Comment #14 R7. Middlebox Reliance: For a transient time the device and the UA MAY use the help of servers (e.g. ESRP) to provide the connectivity to ECC, especially for ECC not yet connected to the Internet. Same as comment to #13 - This ID professes that it all about IP e2e connectivity, yet this states it isn't really necessary. Which is it? This motivation, or the wording in the Intro section? Comment #15 R7 Motivation: Emergency calling mechanisms must support existing emergency call centers based on circuit-switched technology as well as future ECCs that are IP-enabled. This motivation statement clearly contradicts the Intro section (stating this is for IP e2e scenarios). Comment #16 A2. Local: Since many countries have already deployed national emergency identifiers, such as 911 in North America and 112 in large parts of Europe, UAs, proxies and call routers MUST recognize these universal emergency identifiers, but MAY NOT recognize lower level local emergency identifiers, including those such as 999, 122, 133, etc. In addition, these same call routing entities SHOULD recognize emergency identifiers that are used in other jurisdictions I don't understand this one as written, as there are ~60 different numbers around the world, we should list which ones are recommended for support and discuss the list. Primary examples are 115, 116, 117 etc for different emergency services within the same jurisdiction. Comment #17 A2. Local - [Ed. The requirement A2 is really a set of 3 requirements, and needs to have the question answered which is: "what does the term "local" mean?".] Good question... Comment #18 A2 Motivation: The latter requirement is meant to help travelers that may not know the local emergency number and instinctively dial the number they are used to from home. However, it is unlikely that all systems could be programmed to recognize any emergency number used anywhere as some of these numbers are used for non-emergency purposes, in particular extensions and service numbers. What is meant by this last phrase: "... in particular extensions and service numbers." Comment #19 A3. Recognizable: Emergency calls MUST be recognizable by user agents, proxies and other network elements. To prevent fraud, an address identified as an emergency number for call features or authentication override MUST also cause routing to a PSAP. Recommend replacing some of the last sentence with: "...any call recognized as an emergency call MUST be delivered expeditiously to an ECC". Comment #20 A5. Secure configuration: Devices SHOULD be assured of the correctness of the local emergency numbers that are automatically configured. How do you "assure a device" without asserting something that requires a key the remote and local domains understand, as well as the UA understands? Comment #21 A6. Backwards-compatible: Existing devices that predate the specification of emergency call-related protocols and conventions MUST be able reach a PSAP. I've read this above somewhere else in the ID. If a PIDF-LO is required to complete a 911 call, and it isn't present, and the device doesn't support the error messages from draft-ietf-sipping-location-requirements-02.txt, how can this work? I think this can work in residential and SMB scenarios, but I'm not sure about any others. VPNs in those other network types is but one reason for these problems. Comment #22 A7. Common Identifier: User initiated requests using local initiation methods (e.g. 9-1-1) MUST be supported across non-local domains (e.g. foreign countries). This is stated too US-centric. The IETF isn't about a country. This should state that all/most recognizable local emergency numbers will be converted to (perhaps) one SIP user-part for all SIP intermediaries to know to process accordingly. Comment #23 A7 Motivation: While traveling, users must be able to use their familiar "home" emergency identifier. Users should also be able to dial the local emergency number in the country they are visiting. Looking at the range of potential numbers, this will be interesting to meet - including just dialing '0' and meaning an emergency call Comment #24 Section 5 Proxy-inserted: A proxy along the call path inserts the location or location reference. This violates 3261 and draft-ietf-sipping-location-requirements-02.txt Comment #25 L1. Multiple location services: For UA-referenced locations, PSAPs MUST be able to access different location providers. The location provider may be tied to the ASP, AIP or ISP or may be independent of these entities. This may be inside an enterprise, and that should not be underscored or overlooked due to the trust-boundary issues known there Comment #26 L1 Motivation: This requirement avoids that all users have to rely on a single location service provider. This requirement is hard to avoid if there are no traditional national application-layer service providers. I don't understand the first sentence as written, especially since this ID just got done talking about internationalization scope. Comment #27 L2. Civic and Geographic: Where available, both civic (street address) and geographic (longitude/latitude) information SHOULD be provided to the PSAP. This necessitates a PIDF-LO extension to indicate if one was derived from the other. That XML element doesn't exist to my knowledge. Comment #28 L2 Motivation: While geographic coordinate information can usually be translated into civic address location information, "some specific information, such as building number and floor, is more easily provided as civic location information since it does not require a detailed surveying operation". For direct location determination, it may also be easier for the user to check civic location information to assure verity. I don't understand the quoted comment (I put in the quotes BTW) in the first sentence above. Is this suggesting a detailed survey *will* yield the cube number from a GPS coordinate on a non-ground floor? If it won't, it doesn't need to be brought up as motivation. Comment #29 L3. Location source identification: The source of a location data, whether measured, derived (e.g geocoding or reverse geocoding transformation), or manually input, MUST be indicated to the PSAP. How is this not covered by the element in the PIDF-LO, and if so, why is the requirement not just "...the element MUST be present when known"... Comment #30 L3 Motivation: This allows the PSAP to better judge the reliability and accuracy of the data and track down problems. I don't believe the word "judge" is appropriate here, as the PSAPs first need to "learn" (a better word for above) from real world experience what data indicates what results. Down the road, they will then analyze trends and such to determine how best to interpret data. Comment #31 L4. Certifiable: In some cases, the source and generation time of the location object used for call routing and caller location display MUST be verifiable, e.g., by a digital signature. The security requirements describe this in more detail. If my wireline phone has a timestamp of 2002, is that bad/untrusted? I don't believe so. This requirement needs to be adjusted to state this is a function of the the location was derived from. Further, a future document (perhaps years from now) needs to be generated to give recommendations of those functions per value. Comment #32 L5. Multiple locations: Multiple locations MAY be associated with the caller How is this requirement different that L2? If it can be different, then this text needs to state when/how it can be different, yet still be considered good. Comment #33 L5 Motivation: Multiple locations may occur either because the caller has provided more than one civic or geographic (coordinates) location, supplies both civic and geospatial location information, or because different location determination entities make different assessments of the caller's location." There needs to be a requirement stating if there is location information in both formats, and both are depicting the same location (as far as the UA is concerned), they MUST be in the same PIDF-LO; if different - or not sure they are the same location, they need to be in separate PIDF-LOs (typically with different values). Comment #34 L5 Motivation: Multiple locations may occur either because the caller has provided more than one civic or geographic (coordinates) location, supplies both civic and geospatial location information, or because different location determination entities make different assessments of the caller's location." If there are more than one, and they are different, which is trusted to be true? Comment #35 L6. Validation of civic location: It MUST be possible to validate an address prior to its use in an actual emergency call. How is "validate" here in L6 different from "certifiable" in L4? Comment #36 L6. Validation of civic location: It MUST be possible to validate an address prior to its use in an actual emergency call. "... prior to its use in an actual emergency call." should be replaced with: "at any time" only. And...it's an implementation issue when this occurs, so I'm not sure this belongs in the ID. Someone like NENA should be defining this type of requirement. Comment #37 L7. Provide location: Calls using VoIP or subsequent methods MUST supply location with the call. "... with the call" should be replaced with: "...in each Request message (if SIP is used)." Comment #38 L8. Accept two location types: PSAPs shall accept location as civic and/or geo specified. [Ed. Suggest deleting above requirement since it doesn't deal with routing] I disagree with the Ed. Comment because this (as written) limits how many different formats a routing Proxy forwards, and how many formats an ECC has to deal with. The same piece of location information (if in a PIDF-LO) will be used for routing and dispatching. Limiting the number to two here is good. Comment #39 L9. Altitude included with location: All representations of location SHALL include the ability to carry altitude. This requirement does not imply altitude is always used or supplied. Either it does or it doesn't, but "include the ability..." is wishy-washy Comment #40 L10. Preferred datum: The preferred geographic coordinate system for emergency calls SHALL be WGS-84. 2D or 3D? Comment #41 L11. Multiple locations: If multiple locations are provided with a call, it SHOULD be possible to identify the most accurate, current, appropriate location information to be used for routing emergency calls and dispatching emergency responders. Exactly how will this be accomplished, especially by a Proxy? This is fruitless, therefore pointless. L2 should be all that is stated for this type of requirement. Comment #42 L14. Imprecise location: Imprecise location information MUST be available for emergency call routing and location delivery in cases where precise measurement based location determination mechanisms fail. How is "imprecise location" indicated to the PSAP as "imprecise"? If it cannot be, it shouldn't be a requirement. Comment #43 L15. Default identification: PSAPs MUST be made aware when imprecise location information was used to route a call. Same comment here that was to L14 - How is "imprecise location" indicated by the proxy to the PSAP as "imprecise"? If it cannot be, it shouldn't be a requirement. Comment #44 L16. Location Responsibility: Location determination MUST assume a responsible party. This is begging for liability statements to be included every time a location is given to a device, that it should not be used unless the user agrees "not to hold the deliverer responsible" before usage. Comment #45 L17 Motivation: The location information MUST be attributed to a specific point in time. That is, the location used for routing and which is reported to the PSAP call taker, must be the actual location of the caller at the time of making the call. This makes learning/getting/retrieving location a real-time event as the emergency call is being initiated - and this is not practical. If my home wireline phone has a timestamp of 2002, is that bad? Comment #46 L18. Location, Emergency Caller: Location provided with call MUST be associated with an Emergency Caller. Huh? This is to a device, one in which a user might not be logged into. Comment #47 L19 Motivation: Requirement 1 states that a level of authentication and validation for the source of the location is required. This implies the need to for the Emergency Caller to determine the authenticating and validating entity for the emergency services domain in which they reside. That is, it must be possible for an Emergency Caller to discover and utilize an answerable source of location in the access network they are using. The term in the 1st sentence "level" needs to be defined in order to understand if it is met. Level is not currently defined within this ID. Comment #48 L19. Location Domain Availability: Location domain MUST be obtainable by Emergency Caller. Motivation: Requirement 1 states that a level of authentication and validation for the source of the location is required. This implies the need to for the Emergency Caller to determine the authenticating and validating entity for the emergency services domain in which they reside. That is, it must be possible for an Emergency Caller to discover and utilize an answerable source of location in the access network they are using. "Emergency Caller" as used in the 1st sentence - I personally don't care who the authority is, and I doubt most (if any) do outside of this list and some regulators. Comment #49 L19. Location Domain Availability: Location domain MUST be obtainable by Emergency Caller. Motivation: Requirement 1 states that a level of authentication and validation for the source of the location is required. This implies the need to for the Emergency Caller to determine the authenticating and validating entity for the emergency services domain in which they reside. That is, it must be possible for an Emergency Caller to discover and utilize an answerable source of location in the access network they are using. This last sentence isn't clear. Provide an example of me discovering an "answerable source" so I can visualize it. Comment #50 L20. Location Certification: Location provided MUST be certified. This doesn't account for a GPS chip in a PDA or cell phone, therefore this cannot be a MUST. Comment #51 L20 Motivation: The Emergency Caller must be able to establish a session with the access domain authenticating and validating entity to obtain a certified location. The authentication of the location is granted with an expiry time, after which the location within the domain is deemed invalid. "INVALID"? This is starting to look an awful lot like a DHCP lease operation, and we're not building a protocol to do this here. Comment #52 L21. Location and Emergency Caller Identity: It MUST NOT be assumed that Emergency Caller identity provided with location is true identity of Emergency Caller. This contradicts L18 Comment #53 L22. Location Acceptability: Location provided by Emergency Caller MUST be considered acceptable as input to authentication and validation entity. This isn't really clear. Location should be in a certain format, and there is a 'the' missing in the requirement. Comment #54 L22. Location Acceptability: Location provided by Emergency Caller MUST be considered acceptable as input to authentication and validation entity. I see no requirement creating an "authentication and validation entity" which this requirement assumes already exists for every user. Comment #55 L24. Location Query Authorization: The ability to query emergency caller location using a location key MUST be limited to authorized end points. "end points" (which is one word BTW) Should be replaced with: "requests" Comment #56 L24 Motivation: Where the Emergency Caller does not desire the transmission of their location in-band with their call setup, they shall have the option of requesting a unique query key such that only authorized end points may query the location directly from the domain. As stated above: "end points" (which is one word) Should be replaced with: "requests" As "endpoints" implies the actual device has an SA relationship with the database server, which may not be the case, and only the user created an SA from a log-in screen. This is a two level operation. Comment #57 L25. Location Domain Authorization: Location Source entity MUST be authorized within the access domain. This is starting to create an architecture now... and I think this is starting to overstep some bounds of the charter and belongs more in NENA than IETF Comment #58 L26. Endpoint Location: Location MUST be tied to an endpoint within the access domain at the time of an emergency call. GPSs violate this, so this cannot be a MUST - see L27 below L27. Location Sources: Single source of location MUST NOT be assumed. Motivation: To achieve this, the end user device MUST be able to retrieve its current location from the access provider, from the infrastructure, via GPS, ... or as last resort, from the user itself. Comment #59 L28. Location Provided: Endpoint location SHOULD be provided to ECC. This needs to be restated as "if location is provided to the routing proxy, it MUST be provided to the ECC. Comment #60 6. Identifying the Appropriate Emergency Call Center From the previous section, we take the requirement of a single (or small number of) emergency addresses which are independent of the caller's location. However, since for reasons of robustness, jurisdiction and local knowledge, PSAPs only serve a limited geographic region, having the call reach the correct PSAP is crucial. While a PSAP may be able to transfer an errant call, any such transfer is likely to add tens of seconds to call setup latency and is prone to errors. (In the United States, there are about 6,100 PSAPs.) I'd like to see the data justifying this last claim of 10s of seconds statement going forward with IP. Comment #61 6. Identifying the Appropriate Emergency Call Center From the previous section, we take the requirement of a single (or small number of) emergency addresses which are independent of the caller's location. However, since for reasons of robustness, jurisdiction and local knowledge, PSAPs only serve a limited geographic region, having the call reach the correct PSAP is crucial. While a PSAP may be able to transfer an errant call, any such transfer is likely to add tens of seconds to call setup latency and is prone to errors. (In the United States, there are about 6,100 PSAPs.) And only about 600 regions, so this might not be so hard with IP and endpoint provided location Comment #62 Section 6, second paragraph at the end: A UA could conceivably store a complete list of all PSAPs across the world, but that would require frequent synchronization with a master database as PSAPs merge or jurisdictional boundaries change. "change"? This likely isn't so often, BTW Comment #63 Section 6, forth paragraph: Note that the first proxy, the ESRP, doing the translation may not be in the same geographic area as the UA placing the emergency call. "...the first proxy, the ESRP..." Does this assume that any proxy that can route based on the location of the caller is an ESRP? Comment #64 I4. Choice of IPSAPs: The emergency caller SHOULD be provided a choice of emergency call centers if more than one exists and is relevant. This gets into defining what an ECC is (which hasn't been done yet), and that if another number is dialed, it doesn't constitute an emergency call IMO. Comment #65 I5. Assuring IPSAP identity: The emergency caller SHOULD be able to determine conclusively that he has reached an accredited emergency call center. How can this possibly be done? If my display says "Dallas Police Dept." , do I trust it, or do I take the time to verbally question the identity of the calltaker? Do we suggestion questions to be asked to verify the identity of the calltaker? Comment #66 I5 Motivation: This requirement is meant to address the threat that a rogue, possibly criminal, entity pretends to accept emergency calls. How can't this be easily faked? Comment #67 I6. Warnings for unidentifiable IPSAP. Implementations SHOULD allow callers to proceed, with appropriate warnings or user confirmations, if the identity of the destination IPSAP cannot be verified. How is this verified without there being a root key installed in all UAs? Comment #68 I7. Traceable resolution: Particularly for mediated resolution, the caller SHOULD be able to definitively and securely determine who provided the emergency address resolution information. Is this suggesting that all Proxies must remain post transaction/dialog stateful to the user for them to later investigate something? For how long after? Comment #69 I10. Incrementally deployable: An Internet-based emergency call system MUST be able to be deployed incrementally. In the initial stages of deployment, an emergency call may not reach the optimal PSAP. If allowed, emergency calls must only be routed to PSAPs that have agreed to accept non-optimally routed calls. [Ed. Can this be merged with R6?] yes Comment #70 I11. ECC Availability: ECC communication MUST be continuously available. Motivation: From any Internet-connected device it MUST be possible at any time to contact the ECC responsible for the current location with the most appropriate method for communication for the user and the device. is this the famous five 9s? Comment #71 I13. Cross-Jurisdiction Device Support: Devices SHOULD support alternate emergency service systems between countries. Motivation: Even as each country is likely to operate their emergency calling infrastructure differently, SIP devices should be able to reach emergency help and, if possible, be located in any country. [Ed. above text needs clarification] yeah, this doesn't make much sense now Comment #72 I15: It MUST be possible to route a call based on either a civic or a geo location without requiring conversion from one to the other. This requirement does not prohibit an implementation from converting and using the resulting conversion for routing. how is this different from I14? Comment #73 I16: It MUST be possible for a designated 9-1-1 authority to a PSAP to approve of any geocoding database(s) used to assist in determining call routing to that PSAP. Mechanisms must be provided for the PSAP designated 9-1-1 authorities to test and certify a geocoding database as suitable for routing calls to the PSAP. The PSAP may choose to NOT avail itself of such a mechanism. This is implementation - and shouldn't be in here Comment #74 I17: It MUST be possible for the designated 9-1-1 authority to supply, maintain, or approve of databases used for civic routing. Mechanisms must be provided for a designated authority for a PSAP to test and certify a civic routing database as suitable for routing calls to that PSAP. This is implementation - and doesn't belong here Comment #75 I18: It MUST be possible for the PSAP itself (or a contractor it nominates on its behalf) to provide geocode and reverse geocode data and/or conversion services to be used for routing determination. This implies definition of a standard interchange format for geocode data, and protocols to access it. This has nothing to do with Routing the call, and shouldn't be in here. Comment #76 I20: Boundaries for civic routing MUST be able to be specific to a street address range, a side of a street (even/odd street addresses), a building within a "campus", or any of the location fields available. [Ed. Available from where? Please clarify. In the PIDF-LO I think Comment #77 I21: It MUST be possible to use various combined components of the location object for determination of routing. Some areas may only require routing to a country level, others to a state/province, others to a county, or to a municipality, and so on. No assumption should be made on the granularity of routing boundaries or about the combination of components used. The last sentence alone should be the requirement: "No assumption should be made on the granularity of routing boundaries or about the combination of components used." and the text above this sentence removed or used as explanation only. Comment #78 I22: Boundaries mechanisms for geo routing MUST be able to be specific to a natural political boundary, a natural physical boundary (such as a river), or the boundaries listed in the previous requirement. This is repetitive Comment #79 I23: Any given geographic location SHOULD result in identification of a unique governmentally-authorized PSAP entity for that location? This is repetitive Comment #80 I24: Routing databases using 9-1-1 Valid Addresses or lat/lon/ altitude as keys MUST both be available to all entities needing to route 9-1-1 calls. Too US centric Comment #81 I25: Carriers, enterprises and other entities that route emergency calls MUST be able to route calls from any location to its appropriate PSAP. "... to its appropriate PSAP should be replaced with "...towards its appropriate ECC." as the first proxy might no have enough knowledge to do it all Comment #82 I26: It MUST be possible for a given PSAP to decide where its calls should be routed. repetitive Comment #83 I27: It is desirable for higher level civic authorities such as a county or state/province to be able to make common routing decisions for all PSAPs within their jurisdiction. implementation - should be in NENA, not IETF For example, a state may wish to have all emergency calls placed within that state directed to a specific URI. This does NOT imply a single answering point; further routing may occur beyond the common URI. Comment #84 I28: Routing MAY change on short notice due to local conditions, traffic, failures, schedule, etc. this is true with anything IP based, what's the requirement? Comment #85 I32: Multiple types of failures MAY have different contingency routes. Is this a requirement? Comment #86 I33: It MUST be possible to provide more than one contingency route for the same type of failure. Duplicate of I31 Comment #87 I34: A procedure MUST be specified to handle "default route" capability when no location is available or the location information is corrupted. I34 and I35 state the same thing currently Comment #87 I35: Default routes MUST be available when location information is not available. I34 and I35 state the same thing currently Comment #88 I36: Entities routing emergency calls SHALL retain information used to choose a route for subsequent error resolution. "... retain information" for how long? Comment #89 I37: Access Infrastructure providers MUST provide a location object that is as accurate as possible when location measurement or lookup mechanisms fail. "... MUST provide a location object". This is stated incorrectly, the AIP doesn't give the UA its PIDF-LO, it gives it an LCI in most cases. The UA builds/generates the PIDF-LO. Comment #90 I38: Location available at the time that the call is routed MAY not be accurate. Is this a requirement? It's not written as one Comment #91 I39: It SHOULD be possible to have updates of location (which may occur when measuring devices provider early, but imprecise "first fix" location) which can change routing of calls. "... updates of location"... This is a duplicate (L13) Comment #92 7. Emergency Address Directory General comment on this whole section - isn't this sufficiently in the background that this is "architecture" and not "identification" or "routing" in that it doesn't belong in the IETF (but more like NENA)? Comment #93 D1. ECC Identification: Public access to ECC selection information MUST be assumed. Need to mention this is "read only" access Comment #94 D2. Assuring directory identity: The query agent (e.g UA or server) MUST be able to assure that it is querying the intended directory. Without a shared key exchange (ensuring the correct destination is contacted), how can this be accomplished? Comment #95 D3. Query response integrity: The query agent MUST be able to be confident that the query or response has not been tampered with. Suggested rewrite to: "The query agent MUST take appropriate steps to ensure the query or response maintained integrity." Comment #96 D4. Assurance of Update integrity: Any update mechanism for the directory MUST ensure that only authorized users can change directory information and must keep an audit log of all change transactions. This smells like an architectural implementation requirement, therefore it doesn't belong here Comment #97 D6. Multiple directories: A UA or proxy SHOULD be able to use multiple (separate) directories to resolve the emergency identifier. If this can ever be manually entered in a UA or a network server to then be distributed to that network's UAs, then this requirement needs to be opened up to "UA or Proxy or other server SHOULD..." Comment #98 D7. Referral: All directories SHOULD refer out-of-area queries to an appropriate default or region-specific directory. Not sure how this applies to ECRIT Comment #99 D8. Multiple query protocols: Directories MAY support multiple query protocols. What does this have to do with routing or identification? Comment #100 D9. Baseline query protocol: A mandatory-to-implement protocol MUST be specified. Suggested rewording: " A single mandatory-to-implement protocol MUST be specified. Other optional protocols may be listed to give guidance if another protocol is preferred." Comment #101 C1. Identity: The system SHOULD allow (but not force) the identification of both the caller's identity and his or her terminal network address. Doesn't this violate a previous requirement stating the caller's identity cannot be assumed (L21). Plus the definition of "basic emergency service" states this. Comment #102 C2. Privacy override: The end system MUST be able to automatically detect that a call is an emergency call and override any privacy settings that conflict with emergency calling. This doesn't go deep enough into how a jurisdiction may limit how private a caller can remain when calling an ECC. Or the opposite can be true. Comment #103 C3. Recontacting Endpoint: The ECC SHOULD have the capability to recontact the initiating endpoint after disconnection. Retitle "Reestablish Communication with Endpoint" Comment #104 C3 Motivation: Capability to re-contact the contacting device from the ECC in case of disruption or later query for a tbd period of time. This should also be possible from conventional ECC via temporary (virtual) E.164 numbers. All IP means you cannot assume E.164. Comment #105 S1. Authentication override: All outbound proxies and other call filtering elements MUST be able to be configured so that they allow unauthenticated emergency calls. Reword "... MUST be able to be configured..." to "...MUST be configurable..." Comment #106 S2. Mid-call features: The end system MUST be able to recognize an emergency call and allow configuration so that certain call features are not triggered accidentally. Reword " The end system MUST be able to recognize an emergency call and allow configuration so that certain call features are not triggered accidentally." To " The end system MUST recognize it initiated an emergency call and prevent certain call features that interfere with that call (e.g. call waiting, call hold)." Comment #107 In Just after S2 - there needs to be a requirement added stating something to the affect that "...once a UA initiates an emergency call, system resources SHOULD be prevented from certain call features that interfere with that call (e.g. Barge, call preemption). The latter example is for military or government networks. Comment #108 S3. Testable: A user SHOULD be able to test whether a particular address reaches the appropriate PSAP, without actually causing emergency help to be dispatched or consuming PSAP call taker resources. How can't this be faked? Comment #109 S6 Tracking and Tracing Facilities for all calls MUST be provided. This includes all routing entities as well as all signaling entities. "Facilities" reads like circuits and lines. What is meant here? Comment #110 S7 Each element in the signaling and routing paths solution SHALL maintain call detail records that can be accessed by management systems to develop call statistics in real time. Does it really need to be in real-time? Are we talking RTCP statistics? Is this something CALEA would want? How far towards the UAC can a ECC Net Mgmt station gain access to SIP element CDR information? How doesn't this look like a means of attack into an enterprise? Comment #111 S8 Each element of the signaling and routing paths SHALL provide congestion controls. We're talking RSVP and/or MPLS now? Diffserv doesn't do this, and the ECN proposal from Nortel is getting some pushback from Sally Floyd and Fred Baker. Comment #112 S9 It SHALL be possible to determine the complete call chain of a call, including the identity of each signaling element in the path, and the reason it received the call (Call History). We're talking RSVP and/or MPLS now? Diffserv doesn't do this, and the ECN proposal from Nortel is getting some pushback from Sally Floyd and Fred Baker. Comment #113 10. Supplemental Information Owner of the structure or tenant? Where is this in our Charter? SOMETHING TO ADD TO THIS DOCUMENT It is the case in Sweden that when a person calls for emergency help, they MUST provide two different locations in the call set-up. #1 - they MUST provide the location they are calling from (in civic or coordinate format); #2 - they MUST provide their billing location (where they personally receive their bills from. The next version of draft-ietf-sipping-location-requirements-02 (in the SIP WG) will account for this. But I on't know if should only be mentioned there. cheers, James ******************* Truth is not to be argued... it is to be presented. Alas, few *truths* exist without the math. ...all else is a matter of perspective _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 16 21:38:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXr2U-0004bO-IB; Mon, 16 May 2005 21:38:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXr2U-0004bJ-3H for ecrit@megatron.ietf.org; Mon, 16 May 2005 21:38:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25743 for ; Mon, 16 May 2005 21:38:28 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXrJ8-0001tn-Jd for ecrit@ietf.org; Mon, 16 May 2005 21:55:43 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4H1cIdv029476 for ; Mon, 16 May 2005 18:38:18 -0700 (PDT) Received: from [70.200.22.119] (vpn-10-50-16-3.qualcomm.com [10.50.16.3]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4H1cA2o029638 for ; Mon, 16 May 2005 18:38:14 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Mon, 16 May 2005 18:38:07 -0700 To: ecrit@ietf.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Subject: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andy, Hannes, and I put this together for discussion; sorry that we did not make the week-prior deadline, but hopefully we can at least have hallway discussion on some of the ideas. regards, Ted >To: i-d-announce@ietf.org >From: Internet-Drafts@ietf.org >Date: Mon, 16 May 2005 15:38:39 -0400 >Subject: I-D ACTION:draft-hardie-ecrit-iris-00.txt >X-BeenThere: i-d-announce@ietf.org >Reply-To: internet-drafts@ietf.org >List-Id: i-d-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: i-d-announce-bounces@ietf.org >X-QUALCOMM-AV: Sophos AV Testing > > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : An IRIS Schema for Emergency Service Contact URIs > Author(s) : T. Hardie, et al. > Filename : draft-hardie-ecrit-iris-00.txt > Pages : 23 > Date : 2005-5-16 > >This document describes an XML-based protocol for passing location > information to a server that returns emergency service contact URIs. > It is based on IRIS, the Internet Registry Information Service, and > starts from the premise that the search for emergency service > contacts can be modelled as a database search that uses geolocation > or civic location as input and returns one or more contact URIs as > output. It is intended to fit within a larger framework of > standards. specifically, it presumes the existence of a URI scheme > appropriate for signaling that emergency service is required and > distinguishing among emergency services if appropriate. It also > presumes that an entity requesting this response will be able to > handle the URIs returned as input to appropriate handlers. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hardie-ecrit-iris-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body >of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-hardie-ecrit-iris-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-hardie-ecrit-iris-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > >[The following attachment must be fetched by mail. Command-click the >URL below and send the resulting message to get the attachment.] > >[The following attachment must be fetched by ftp. Command-click the >URL below to ask your ftp client to fetch it.] > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 16 22:36:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXrwd-0002hB-68; Mon, 16 May 2005 22:36:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXrwc-0002h4-8n for ecrit@megatron.ietf.org; Mon, 16 May 2005 22:36:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01168 for ; Mon, 16 May 2005 22:36:27 -0400 (EDT) Received: from www.cdt.org ([72.3.253.41]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXsDH-0004zW-Cp for ecrit@ietf.org; Mon, 16 May 2005 22:53:43 -0400 Received: from [10.0.1.13] (localhost [127.0.0.1]) (authenticated bits=0) by www.cdt.org (8.12.11/8.12.11) with ESMTP id j4H2QRVR012633; Mon, 16 May 2005 21:26:28 -0500 Mime-Version: 1.0 X-Sender: cdt-jmorris-lists@localhost Message-Id: In-Reply-To: References: Date: Mon, 16 May 2005 22:36:07 -0400 To: Ted Hardie From: John Morris Subject: Re: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Ted, One thought: I can understand why you do not want to convey or imply a preference among multiple methods of contact (and thus multiple URIs). Certainly, ideally, a PSAP could handle multiple contact methods equally well. But what about scenarios where they cannot -- like today, some 911 calls end up going over the PSAP's administrative telephone line, which is a distance second choice compared to calls coming in "normally". Is there possible value in (at the risk of adding complexity) allowing an optional in addition to the element (both of which could allow multiple URIs). The Alt designation would strongly convey that the Alt URIs are greatly disfavored contact methods, but are still usable as a last resort. With your approach, a PSAP would not (hypothetically) provide an e-mail URI because e-mails are really sub-optimal ways to initiate a 911 report. With my suggestion, the PSAPs might provide 3 favored URIs, and a couple of disfavored ones like e-mail. And then in some odd scenario someone who can really only send e-mail can still get through. (Maybe e-mail is not the best example, but you get the idea -- perhaps a PSAP might say that any and all voice-based or TTY-based contact methods are greatly favored, but IM is also possible). Just a thought. John At 6:38 PM -0700 5/16/05, Ted Hardie wrote: >Andy, Hannes, and I put this together for discussion; sorry that we >did not make the week-prior deadline, but hopefully we can at >least have hallway discussion on some of the ideas. > regards, > Ted > >>To: i-d-announce@ietf.org >>From: Internet-Drafts@ietf.org >>Date: Mon, 16 May 2005 15:38:39 -0400 >>Subject: I-D ACTION:draft-hardie-ecrit-iris-00.txt >>X-BeenThere: i-d-announce@ietf.org >>Reply-To: internet-drafts@ietf.org >>List-Id: i-d-announce.ietf.org >>List-Unsubscribe: , >> >>List-Post: >>List-Help: >>List-Subscribe: , >> >>Sender: i-d-announce-bounces@ietf.org >>X-QUALCOMM-AV: Sophos AV Testing >> >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : An IRIS Schema for Emergency Service Contact URIs >> Author(s) : T. Hardie, et al. >> Filename : draft-hardie-ecrit-iris-00.txt >> Pages : 23 >> Date : 2005-5-16 >> >>This document describes an XML-based protocol for passing location >> information to a server that returns emergency service contact URIs. >> It is based on IRIS, the Internet Registry Information Service, and >> starts from the premise that the search for emergency service >> contacts can be modelled as a database search that uses geolocation >> or civic location as input and returns one or more contact URIs as >> output. It is intended to fit within a larger framework of >> standards. specifically, it presumes the existence of a URI scheme >> appropriate for signaling that emergency service is required and >> distinguishing among emergency services if appropriate. It also >> presumes that an entity requesting this response will be able to >> handle the URIs returned as input to appropriate handlers. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-hardie-ecrit-iris-00.txt >> >>To remove yourself from the I-D Announcement list, send a message to >>i-d-announce-request@ietf.org with the word unsubscribe in the body >>of the message. You can also visit >>https://www1.ietf.org/mailman/listinfo/I-D-announce >>to change your subscription settings. >> >> >>Internet-Drafts are also available by anonymous FTP. Login with the username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-hardie-ecrit-iris-00.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-hardie-ecrit-iris-00.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> >> >>[The following attachment must be fetched by mail. Command-click >>the URL below and send the resulting message to get the attachment.] >> >>[The following attachment must be fetched by ftp. Command-click >>the URL below to ask your ftp client to fetch it.] >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www1.ietf.org/mailman/listinfo/i-d-announce > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 16 22:42:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXs2e-0004fO-0j; Mon, 16 May 2005 22:42:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXs2c-0004fG-Kx; Mon, 16 May 2005 22:42:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01842; Mon, 16 May 2005 22:42:40 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXsJG-0005MO-Tr; Mon, 16 May 2005 22:59:56 -0400 Received: from [192.168.0.31] (pool-138-89-81-67.mad.east.verizon.net [138.89.81.67]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4H2gdNF003201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 May 2005 22:42:40 -0400 (EDT) Message-ID: <42895A1C.1010208@cs.columbia.edu> Date: Mon, 16 May 2005 22:42:36 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: geopriv@ietf.org, ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: Subject: [Ecrit] Threats X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Based on the discussion today, some notes, first on the threat model. At a high level, for this discussion, we care about users that place calls using wrong location information, for one of two purposes: (1) dispatching resources to a wrong place (here, resources can be anything from AAA towtrucks to Domino's Pizza to a fire engine) = crank call; (2) flooding call centers with lots of calls apparently from different individuals and different locations, to overwhelm call takers that need to answer the call, determine that there's no human there (but maybe a recording) = DOS. The first case relies on the ability to spoof locations, possibly on a small scale, while the second relies on the ability to create lots of different-looking calls in short order. It is easy to filter out lots of calls coming from the same caller and/or exact same location, so that type of replay attack is not as major a concern. We can probably agree that dealing with zombie PCs that report their correct location and identity, but have been owned by a worm, are beyond what GEOPRIV can fix and is best left to Microsoft and kin. (There are some things one could do at the application layer if there's an attack, such as some kind of Turing test to ascertain that the caller is a live human being. I suspect it is not easy to make this work with sufficiently low failure rates for children and those with limited command of English.) For both cases above, there are two related issues: (1) limiting the ability to perform the attack; (2) prosecuting the attacker, as this is likely to act as a deterrent. It would be helpful to converge on the threat model, without discussing solutions. It may well be that either threat cannot be addressed in all cases. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 16 23:06:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXsPK-0002S8-GQ; Mon, 16 May 2005 23:06:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXsPH-0002Rt-2u; Mon, 16 May 2005 23:06:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03903; Mon, 16 May 2005 23:06:04 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXsfv-0006dd-4S; Mon, 16 May 2005 23:23:20 -0400 Received: from [192.168.0.31] (pool-138-89-81-67.mad.east.verizon.net [138.89.81.67]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4H363iK005161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 May 2005 23:06:04 -0400 (EDT) Message-ID: <42895F9D.7030105@cs.columbia.edu> Date: Mon, 16 May 2005 23:06:05 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: geopriv@ietf.org, "'ecrit@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Subject: [Ecrit] Deployment models X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org We had discussed several deployment models (network architectures), including, roughly in order of challenge: (Vertical integration) Network access and call signaling (SIP) operated by the same entity or at least two entities with a close relationship; for example, the IAP operates an outbound proxy in each subnet that can insert or provide location information; (User cert) The IAP and VSP are separate entities that don't cooperate, but the IAP might operate an outbound proxy that provides identity assertion based on access identity. (Certified customer, no relationship) The IAP hands out customer certificates that allow a user to certify that they are known to a larger entity. Customers can give their private keys to their evil twins and shady friends, but they would presumably face some liability for this. The VSP is a separate entity in this case. (No relationship) The IAP and VSP have no relationship; one certifies location and maybe a customer name, the other an identity only. There is no long-term stable relationship between the access identifier and the voice identifier. (Indeed, there may not be any voice identifier as such, as the caller may just run its own SIP client, without the benefit of a Vonage-like entity.) The basic assumption is that the IAP provides location (and maybe identity), the VSP identity, but no location. Obviously, in the first case, they are the same, so the distinction is moot. This only matters if the receiver can discriminate under overload. If the receiving call center is somehow obligated to take all calls with equal probability, signing does not matter, except to prevent a bad actor from modifying in-transit signaling requests (for which channel security is probably a better approach). In all cases, it doesn't matter for this discussion whether the location is identified by a location object or some pointer to a location object. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 17 07:48:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY0YW-0002RL-GV; Tue, 17 May 2005 07:48:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY0YU-0002RD-Kp; Tue, 17 May 2005 07:48:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11818; Tue, 17 May 2005 07:48:09 -0400 (EDT) Message-Id: <200505171148.HAA11818@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY0pE-00011B-JD; Tue, 17 May 2005 08:05:28 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DY0YK-0001hS-7U; Tue, 17 May 2005 06:48:00 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , , Date: Tue, 17 May 2005 07:47:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVajcKA+h1J6iboS2GXxkOzd9IT0QARtPgg In-Reply-To: <42895F9D.7030105@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: Subject: [Ecrit] RE: [Geopriv] Deployment models X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree with these model descriptions. I have problems with terminology. I think we all know and agree with the term "Internet Service Provider". A customer has a direct relationship with his ISP. I have been using the term "Access Infrastructure Provider" for the entity that actually owns the infrastructure. This may or may not be the ISP. However, when the AIP and the ISP are not the same entity, the ISP borrows/rents/leases facilities from the AIP. Location is always reported to the subscriber by the ISP. The AIP is the entity that actually knows where the subscriber is. Location is always originated by (and possibly signed by) the AIP. There are cases where the infrastructure is split between two entities. For example, one entity may actually own the wires, and another the layer 2 infrastructure. Again, there are contractual relationships between these parties. I'm calling the AIP the Layer 2 entity. The ISP provides IP packet forwarding. I'm not sure what entity an IAP is. Brian > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf > Of Henning Schulzrinne > Sent: Monday, May 16, 2005 11:06 PM > To: geopriv@ietf.org; 'ecrit@ietf.org' > Subject: [Geopriv] Deployment models > > We had discussed several deployment models (network architectures), > including, roughly in order of challenge: > > (Vertical integration) Network access and call signaling (SIP) operated > by the same entity or at least two entities with a close relationship; > for example, the IAP operates an outbound proxy in each subnet that can > insert or provide location information; > > (User cert) The IAP and VSP are separate entities that don't cooperate, > but the IAP might operate an outbound proxy that provides identity > assertion based on access identity. > > (Certified customer, no relationship) The IAP hands out customer > certificates that allow a user to certify that they are known to a > larger entity. Customers can give their private keys to their evil twins > and shady friends, but they would presumably face some liability for > this. The VSP is a separate entity in this case. > > (No relationship) The IAP and VSP have no relationship; one certifies > location and maybe a customer name, the other an identity only. There is > no long-term stable relationship between the access identifier and the > voice identifier. (Indeed, there may not be any voice identifier as > such, as the caller may just run its own SIP client, without the benefit > of a Vonage-like entity.) > > The basic assumption is that the IAP provides location (and maybe > identity), the VSP identity, but no location. Obviously, in the first > case, they are the same, so the distinction is moot. > > This only matters if the receiver can discriminate under overload. If > the receiving call center is somehow obligated to take all calls with > equal probability, signing does not matter, except to prevent a bad > actor from modifying in-transit signaling requests (for which channel > security is probably a better approach). > > In all cases, it doesn't matter for this discussion whether the location > is identified by a location object or some pointer to a location object. > > > Henning > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 17 08:17:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY10p-0001Az-Ti; Tue, 17 May 2005 08:17:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY10o-00019i-Jl for ecrit@megatron.ietf.org; Tue, 17 May 2005 08:17:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15232 for ; Tue, 17 May 2005 08:17:24 -0400 (EDT) Message-Id: <200505171217.IAA15232@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY1HY-0002p2-Os for ecrit@ietf.org; Tue, 17 May 2005 08:34:45 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DY10d-0003LN-Sw; Tue, 17 May 2005 07:17:16 -0500 From: "Brian Rosen" To: "'John Morris'" , "'Ted Hardie'" Subject: RE: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-00.txt Date: Tue, 17 May 2005 08:17:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVaiY6jaaY1+MSKQ3+07qn7NtL53wAT6XXA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org There is a concept of "default route" in the current emergency calling system in North America. You use that route when your actual route fails for some reason. A typical one is that the source location data doesn't yield a valid route, or there is some kind of equipment failure. I think the idea that there is a default route function is very useful. Your idea, an alternate route, is different, and may also be useful. It somewhat depends on how PSAPs are interconnected to various networks. If there actually are multiple network connections that have different addressing (and possibly protocol) mechanisms, then it may be useful to include them. An example would be a PSTN (tel uri) number as opposed to a sip uri. It may be, for example, that the sip uri routes over the Internet, but the tel uri routes over the PSTN to a private IP connection to the PSAP. "Dialable" telephone numbers for emergency calls are generally frowned upon, because of abuse issues, but they may still be preferable to loss of connections when some facilities fail. As we know, while the core of the Internet is very unlikely to fail even in major disasters, we do have problems with access networks, and PSAPs are going to be on access networks. Hopefully, they will be engineered to be highly reliable, but alternate routes may still be useful. If you got both a default route and an alternate route, you would probably use the alternate route first, and then the default route. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > John Morris > Sent: Monday, May 16, 2005 10:36 PM > To: Ted Hardie > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-00.txt > > Ted, > > One thought: I can understand why you do not want to convey or imply > a preference among multiple methods of contact (and thus multiple > URIs). Certainly, ideally, a PSAP could handle multiple contact > methods equally well. But what about scenarios where they cannot -- > like today, some 911 calls end up going over the PSAP's > administrative telephone line, which is a distance second choice > compared to calls coming in "normally". Is there possible value in > (at the risk of adding complexity) allowing an optional > in addition to the element > (both of which could allow multiple URIs). The Alt designation would > strongly convey that the Alt URIs are greatly disfavored contact > methods, but are still usable as a last resort. With your approach, > a PSAP would not (hypothetically) provide an e-mail URI because > e-mails are really sub-optimal ways to initiate a 911 report. With > my suggestion, the PSAPs might provide 3 favored URIs, and a couple > of disfavored ones like e-mail. And then in some odd scenario > someone who can really only send e-mail can still get through. > > (Maybe e-mail is not the best example, but you get the idea -- > perhaps a PSAP might say that any and all voice-based or TTY-based > contact methods are greatly favored, but IM is also possible). Just > a thought. > > John > > > At 6:38 PM -0700 5/16/05, Ted Hardie wrote: > >Andy, Hannes, and I put this together for discussion; sorry that we > >did not make the week-prior deadline, but hopefully we can at > >least have hallway discussion on some of the ideas. > > regards, > > Ted > > > >>To: i-d-announce@ietf.org > >>From: Internet-Drafts@ietf.org > >>Date: Mon, 16 May 2005 15:38:39 -0400 > >>Subject: I-D ACTION:draft-hardie-ecrit-iris-00.txt > >>X-BeenThere: i-d-announce@ietf.org > >>Reply-To: internet-drafts@ietf.org > >>List-Id: i-d-announce.ietf.org > >>List-Unsubscribe: , > >> > >>List-Post: > >>List-Help: > >>List-Subscribe: , > >> > >>Sender: i-d-announce-bounces@ietf.org > >>X-QUALCOMM-AV: Sophos AV Testing > >> > >> > >> > >>A New Internet-Draft is available from the on-line Internet-Drafts > >>directories. > >> > >> > >> Title : An IRIS Schema for Emergency Service Contact URIs > >> Author(s) : T. Hardie, et al. > >> Filename : draft-hardie-ecrit-iris-00.txt > >> Pages : 23 > >> Date : 2005-5-16 > >> > >>This document describes an XML-based protocol for passing location > >> information to a server that returns emergency service contact URIs. > >> It is based on IRIS, the Internet Registry Information Service, and > >> starts from the premise that the search for emergency service > >> contacts can be modelled as a database search that uses geolocation > >> or civic location as input and returns one or more contact URIs as > >> output. It is intended to fit within a larger framework of > >> standards. specifically, it presumes the existence of a URI scheme > >> appropriate for signaling that emergency service is required and > >> distinguishing among emergency services if appropriate. It also > >> presumes that an entity requesting this response will be able to > >> handle the URIs returned as input to appropriate handlers. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-hardie-ecrit-iris-00.txt > >> > >>To remove yourself from the I-D Announcement list, send a message to > >>i-d-announce-request@ietf.org with the word unsubscribe in the body > >>of the message. You can also visit > >>https://www1.ietf.org/mailman/listinfo/I-D-announce > >>to change your subscription settings. > >> > >> > >>Internet-Drafts are also available by anonymous FTP. Login with the > username > >>"anonymous" and a password of your e-mail address. After logging in, > >>type "cd internet-drafts" and then > >> "get draft-hardie-ecrit-iris-00.txt". > >> > >>A list of Internet-Drafts directories can be found in > >>http://www.ietf.org/shadow.html > >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> > >>Internet-Drafts can also be obtained by e-mail. > >> > >>Send a message to: > >> mailserv@ietf.org. > >>In the body type: > >> "FILE /internet-drafts/draft-hardie-ecrit-iris-00.txt". > >> > >>NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE" > >> command. To decode the response(s), you will need "munpack" or > >> a MIME-compliant mail reader. Different MIME-compliant mail readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been split > >> up into multiple messages), so check your local documentation on > >> how to manipulate these messages. > >> > >> > >>Below is the data which will enable a MIME compliant mail reader > >>implementation to automatically retrieve the ASCII version of the > >>Internet-Draft. > >> > >> > >>[The following attachment must be fetched by mail. Command-click > >>the URL below and send the resulting message to get the attachment.] > >> drafts/draft-hardie-ecrit-iris-00.txt> > >>[The following attachment must be fetched by ftp. Command-click > >>the URL below to ask your ftp client to fetch it.] > >> > >>_______________________________________________ > >>I-D-Announce mailing list > >>I-D-Announce@ietf.org > >>https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 17 09:08:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY1oX-0004ov-Rt; Tue, 17 May 2005 09:08:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY1oV-0004ke-I8; Tue, 17 May 2005 09:08:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20157; Tue, 17 May 2005 09:08:45 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY25G-0005gh-A1; Tue, 17 May 2005 09:26:06 -0400 Received: from [160.39.244.214] (dyn-wireless-244-214.dyn.columbia.edu [160.39.244.214]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4HD8enP000528 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 17 May 2005 09:08:45 -0400 (EDT) In-Reply-To: <200505171148.HAA11818@ietf.org> References: <200505171148.HAA11818@ietf.org> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Tue, 17 May 2005 09:08:42 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.728) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org, ecrit@ietf.org Subject: [Ecrit] Re: [Geopriv] Deployment models X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Some people prefer IAP (Internet Access Provider), but it's the same thing as your AIP. (I find IAP somewhat more parallel to ISP.) The VPN comment has nothing to do with location, but rather with the IP prefix. This was for the case that LO signatures turn out to be useless. On May 17, 2005, at 7:47 AM, Brian Rosen wrote: > I agree with these model descriptions. I have problems with > terminology. > > I think we all know and agree with the term "Internet Service > Provider". A > customer has a direct relationship with his ISP. > > I have been using the term "Access Infrastructure Provider" for the > entity > that actually owns the infrastructure. This may or may not be the > ISP. > However, when the AIP and the ISP are not the same entity, the ISP > borrows/rents/leases facilities from the AIP. Location is always > reported > to the subscriber by the ISP. The AIP is the entity that actually > knows > where the subscriber is. Location is always originated by (and > possibly > signed by) the AIP. There are cases where the infrastructure is split > between two entities. For example, one entity may actually own the > wires, > and another the layer 2 infrastructure. Again, there are contractual > relationships between these parties. I'm calling the AIP the Layer 2 > entity. The ISP provides IP packet forwarding. > > I'm not sure what entity an IAP is. > > Brian > > >> -----Original Message----- >> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] >> On Behalf >> Of Henning Schulzrinne >> Sent: Monday, May 16, 2005 11:06 PM >> To: geopriv@ietf.org; 'ecrit@ietf.org' >> Subject: [Geopriv] Deployment models >> >> We had discussed several deployment models (network architectures), >> including, roughly in order of challenge: >> >> (Vertical integration) Network access and call signaling (SIP) >> operated >> by the same entity or at least two entities with a close >> relationship; >> for example, the IAP operates an outbound proxy in each subnet >> that can >> insert or provide location information; >> >> (User cert) The IAP and VSP are separate entities that don't >> cooperate, >> but the IAP might operate an outbound proxy that provides identity >> assertion based on access identity. >> >> (Certified customer, no relationship) The IAP hands out customer >> certificates that allow a user to certify that they are known to a >> larger entity. Customers can give their private keys to their evil >> twins >> and shady friends, but they would presumably face some liability for >> this. The VSP is a separate entity in this case. >> >> (No relationship) The IAP and VSP have no relationship; one certifies >> location and maybe a customer name, the other an identity only. >> There is >> no long-term stable relationship between the access identifier and >> the >> voice identifier. (Indeed, there may not be any voice identifier as >> such, as the caller may just run its own SIP client, without the >> benefit >> of a Vonage-like entity.) >> >> The basic assumption is that the IAP provides location (and maybe >> identity), the VSP identity, but no location. Obviously, in the first >> case, they are the same, so the distinction is moot. >> >> This only matters if the receiver can discriminate under overload. If >> the receiving call center is somehow obligated to take all calls with >> equal probability, signing does not matter, except to prevent a bad >> actor from modifying in-transit signaling requests (for which channel >> security is probably a better approach). >> >> In all cases, it doesn't matter for this discussion whether the >> location >> is identified by a location object or some pointer to a location >> object. >> >> >> Henning >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> >> > > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 17 10:37:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY3C6-0000JK-Er; Tue, 17 May 2005 10:37:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY3C5-0000JA-Qd; Tue, 17 May 2005 10:37:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01159; Tue, 17 May 2005 10:37:11 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY3Sq-0002XM-To; Tue, 17 May 2005 10:54:33 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 17 May 2005 10:37:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4HEaoe8004306; Tue, 17 May 2005 10:37:01 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 10:36:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: [Geopriv] Deployment models Date: Tue, 17 May 2005 10:36:55 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E327C3C3@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] RE: [Geopriv] Deployment models Thread-Index: AcVajcKA+h1J6iboS2GXxkOzd9IT0QARtPggAAYZEbA= From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Henning Schulzrinne" , , X-OriginalArrivalTime: 17 May 2005 14:36:56.0345 (UTC) FILETIME=[E0199890:01C55AED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, This is as bad as trying to define "what is the Internet". I would say that each of these entities are providing a piece of the Internet puzzle. For one of them to assert an exclusive claim to be THE Internet Service Provider is hubris. Each could claim to be an ISP. Therefore, we may be better served to distinguish them as: Access ISP: provides data transport to the home or business user Core ISP: provides data transport between access data networks Service ISP: provides a service platform such a telephony softswitches, PSTN GW, etc. Of course, a single company (ISP) can support one, multiple, or all of these data transport and application services. Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Brian Rosen > Sent: Tuesday, May 17, 2005 7:48 AM > To: 'Henning Schulzrinne'; geopriv@ietf.org; ecrit@ietf.org > Subject: [Ecrit] RE: [Geopriv] Deployment models >=20 > I agree with these model descriptions. I have problems with=20 > terminology. >=20 > I think we all know and agree with the term "Internet Service=20 > Provider". A customer has a direct relationship with his ISP. >=20 > I have been using the term "Access Infrastructure Provider"=20 > for the entity that actually owns the infrastructure. This=20 > may or may not be the ISP. > However, when the AIP and the ISP are not the same entity,=20 > the ISP borrows/rents/leases facilities from the AIP. =20 > Location is always reported to the subscriber by the ISP. =20 > The AIP is the entity that actually knows where the=20 > subscriber is. Location is always originated by (and=20 > possibly signed by) the AIP. There are cases where the=20 > infrastructure is split between two entities. For example,=20 > one entity may actually own the wires, and another the layer=20 > 2 infrastructure. Again, there are contractual relationships=20 > between these parties. I'm calling the AIP the Layer 2=20 > entity. The ISP provides IP packet forwarding. =20 >=20 > I'm not sure what entity an IAP is. >=20 > Brian >=20 > > -----Original Message----- > > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On=20 > > Behalf Of Henning Schulzrinne > > Sent: Monday, May 16, 2005 11:06 PM > > To: geopriv@ietf.org; 'ecrit@ietf.org' > > Subject: [Geopriv] Deployment models > >=20 > > We had discussed several deployment models (network architectures),=20 > > including, roughly in order of challenge: > >=20 > > (Vertical integration) Network access and call signaling (SIP)=20 > > operated by the same entity or at least two entities with a close=20 > > relationship; for example, the IAP operates an outbound=20 > proxy in each=20 > > subnet that can insert or provide location information; > >=20 > > (User cert) The IAP and VSP are separate entities that don't=20 > > cooperate, but the IAP might operate an outbound proxy that=20 > provides=20 > > identity assertion based on access identity. > >=20 > > (Certified customer, no relationship) The IAP hands out customer=20 > > certificates that allow a user to certify that they are known to a=20 > > larger entity. Customers can give their private keys to their evil=20 > > twins and shady friends, but they would presumably face=20 > some liability=20 > > for this. The VSP is a separate entity in this case. > >=20 > > (No relationship) The IAP and VSP have no relationship; one=20 > certifies=20 > > location and maybe a customer name, the other an identity=20 > only. There=20 > > is no long-term stable relationship between the access=20 > identifier and=20 > > the voice identifier. (Indeed, there may not be any voice=20 > identifier=20 > > as such, as the caller may just run its own SIP client, without the=20 > > benefit of a Vonage-like entity.) > >=20 > > The basic assumption is that the IAP provides location (and maybe=20 > > identity), the VSP identity, but no location. Obviously, in=20 > the first=20 > > case, they are the same, so the distinction is moot. > >=20 > > This only matters if the receiver can discriminate under=20 > overload. If=20 > > the receiving call center is somehow obligated to take all=20 > calls with=20 > > equal probability, signing does not matter, except to prevent a bad=20 > > actor from modifying in-transit signaling requests (for=20 > which channel=20 > > security is probably a better approach). > >=20 > > In all cases, it doesn't matter for this discussion whether the=20 > > location is identified by a location object or some pointer=20 > to a location object. > >=20 > >=20 > > Henning > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 17 11:33:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY44u-0006BA-Ax; Tue, 17 May 2005 11:33:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY44s-00068a-Bp for ecrit@megatron.ietf.org; Tue, 17 May 2005 11:33:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06572 for ; Tue, 17 May 2005 11:33:47 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY4Ld-0005ik-D7 for ecrit@ietf.org; Tue, 17 May 2005 11:51:10 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 May 2005 08:33:40 -0700 X-IronPort-AV: i="3.93,114,1115017200"; d="scan'208"; a="266279842:sNHT31967016" Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4HFXcPo001988 for ; Tue, 17 May 2005 08:33:38 -0700 (PDT) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA00346 for ; Tue, 17 May 2005 08:33:37 -0700 (PDT) Message-Id: <200505171533.IAA00346@malone.cisco.com> From: "Marc Linsner" To: Date: Tue, 17 May 2005 11:33:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Thread-Index: AcVa9a/RGR5/znjmS52IWJfZ+4r/5w== X-Spam-Score: 1.1 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Ecrit] ECRIT Interim Meeting Agenda 5/17/2005 - 5/18/2005 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org 5/17 - 1:00pm - 5:30pm Discussion of draft 'draft-schulzrinne-ecrit-requirements-00.txt' 5/18 - 8:30am - 11:30am (con't) Discussion of draft 'draft-schulzrinne-ecrit-requirements-00.txt' 5/18 - 1:00pm - 5:30pm Discussion of draft 'draft-tschofenig-ecrit-security-threats-00.txt' -Marc Linsner- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 17 13:18:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY5i5-00050b-Dq; Tue, 17 May 2005 13:18:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY5i4-00050U-Dz for ecrit@megatron.ietf.org; Tue, 17 May 2005 13:18:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17220 for ; Tue, 17 May 2005 13:18:20 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY5yq-0003IJ-CZ for ecrit@ietf.org; Tue, 17 May 2005 13:35:45 -0400 Received: from [160.39.250.39] ([::ffff:160.39.250.39]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 17 May 2005 13:18:21 -0400 id 001BFA93.428A275D.00001409 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <817817f7929a99b079b3924020ff089b@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ecrit@ietf.org From: Andrew Newton Date: Tue, 17 May 2005 13:18:21 -0400 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [Ecrit] jabber chat room X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org because the xmpp.org server still seems to be unavailable... we'll use the chat room from the geopriv interim (since Brian is already logged in there). geopriv@conference.ecotroph.net -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 17 14:00:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY6N5-0007aN-De; Tue, 17 May 2005 14:00:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY6N3-0007aI-CR for ecrit@megatron.ietf.org; Tue, 17 May 2005 14:00:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21730 for ; Tue, 17 May 2005 14:00:43 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY6dp-0005iD-Kt for ecrit@ietf.org; Tue, 17 May 2005 14:18:07 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4HI0Xdv019771 for ; Tue, 17 May 2005 11:00:33 -0700 (PDT) Received: from [160.39.251.93] (vpn-10-50-16-59.qualcomm.com [10.50.16.59]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4HI0UsH029205 for ; Tue, 17 May 2005 11:00:31 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Tue, 17 May 2005 11:00:28 -0700 To: ecrit@ietf.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Ecrit] Proposed replacement text for R6 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org R6 Incremental Deployment The output of the ECRIT mapping protocol will be one or more URIs that can be used as the target of an emergency communication. These must be usable by an appropriately capable device even if that device has no knowledge of the mapping protocol. As an example, if the mapping protocol returns a SIP URI any SIP-capable phone should be able to use it as a target of the call; no special extension to SIP should be required. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 17 17:11:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY9Lc-0007hT-PO; Tue, 17 May 2005 17:11:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY9Lb-0007hG-07 for ecrit@megatron.ietf.org; Tue, 17 May 2005 17:11:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20539 for ; Tue, 17 May 2005 17:11:23 -0400 (EDT) Message-Id: <200505172111.RAA20539@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY9cP-00035p-0E for ecrit@ietf.org; Tue, 17 May 2005 17:28:50 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DY9LP-0006fw-Ee for ecrit@ietf.org; Tue, 17 May 2005 16:11:15 -0500 From: "Brian Rosen" To: Date: Tue, 17 May 2005 17:11:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVbJPFayqa4VKWlSASrN8EuYOvI7g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [Ecrit] Mapping any time requirement X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The mapping function MUST be able to be invoked at any time, including while an emergency call is in process. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 17 21:21:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYDFj-00082F-Pq; Tue, 17 May 2005 21:21:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYDFi-00081l-5j; Tue, 17 May 2005 21:21:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11474; Tue, 17 May 2005 21:21:35 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYDWW-00089s-9F; Tue, 17 May 2005 21:39:03 -0400 Received: from [10.6.93.34] ([::ffff:206.17.143.86]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 17 May 2005 21:09:26 -0400 id 000FFB14.428A95C6.00006B3F In-Reply-To: <42895F9D.7030105@cs.columbia.edu> References: <42895F9D.7030105@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <74952f2462e10c6d17943bb1dcffb3f5@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Tue, 17 May 2005 21:09:25 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org, "'ecrit@ietf.org'" Subject: [Ecrit] Re: [Geopriv] Deployment models X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On May 16, 2005, at 11:06 PM, Henning Schulzrinne wrote: > We had discussed several deployment models (network architectures), > including, roughly in order of challenge: This thread is started in the context of discussing signing of LCI? > (Vertical integration) Network access and call signaling (SIP) > operated by the same entity or at least two entities with a close > relationship; for example, the IAP operates an outbound proxy in each > subnet that can insert or provide location information; > > (User cert) The IAP and VSP are separate entities that don't > cooperate, but the IAP might operate an outbound proxy that provides > identity assertion based on access identity. Perhaps I'm misreading this, but is there a real-life example of this deployment scenario? > (Certified customer, no relationship) The IAP hands out customer > certificates that allow a user to certify that they are known to a > larger entity. Customers can give their private keys to their evil > twins and shady friends, but they would presumably face some liability > for this. The VSP is a separate entity in this case. > > (No relationship) The IAP and VSP have no relationship; one certifies > location and maybe a customer name, the other an identity only. There > is no long-term stable relationship between the access identifier and > the voice identifier. (Indeed, there may not be any voice identifier > as such, as the caller may just run its own SIP client, without the > benefit of a Vonage-like entity.) You seem to have assumed public key crypto. Is there a reason why shared key could not be used? > The basic assumption is that the IAP provides location (and maybe > identity), the VSP identity, but no location. Obviously, in the first > case, they are the same, so the distinction is moot. > > This only matters if the receiver can discriminate under overload. If > the receiving call center is somehow obligated to take all calls with > equal probability, signing does not matter, except to prevent a bad > actor from modifying in-transit signaling requests (for which channel > security is probably a better approach). > > In all cases, it doesn't matter for this discussion whether the > location is identified by a location object or some pointer to a > location object. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 17 21:37:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYDUp-0004Rh-Vh; Tue, 17 May 2005 21:37:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYDUp-0004RV-Bq; Tue, 17 May 2005 21:37:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12713; Tue, 17 May 2005 21:37:12 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYDlg-0000YF-Nq; Tue, 17 May 2005 21:54:41 -0400 Received: from [192.168.0.31] (pool-138-89-81-67.mad.east.verizon.net [138.89.81.67]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4I1b5Su009567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 May 2005 21:37:09 -0400 (EDT) Message-ID: <428A9C40.80907@cs.columbia.edu> Date: Tue, 17 May 2005 21:37:04 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton References: <42895F9D.7030105@cs.columbia.edu> <74952f2462e10c6d17943bb1dcffb3f5@hxr.us> In-Reply-To: <74952f2462e10c6d17943bb1dcffb3f5@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 1.3 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org, "'ecrit@ietf.org'" Subject: [Ecrit] Re: [Geopriv] Deployment models X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andrew Newton wrote: > > This thread is started in the context of discussing signing of LCI? Motivated by, but I don't want this to be seen as discussing that issue. I don't think much of this discussion depends on signing of a particular data object. I'm just trying to ascertain models that have security impact if an entity wants to ascertain who is calling and/or from where. > Perhaps I'm misreading this, but is there a real-life example of this > deployment scenario? Kind of. Many corporate firewalls essentially operate that way, i.e., they'll terminate application sessions and act as an outbound proxy. This model in particular is rather hypothetical. It might avoid some of the tieing-ourselves-in-knots that the separation of known signaling identity and known location incurs. Operating an outbound proxy just for emergency calls is a minor burden for an IAP, and doesn't seem to substantially interfere with the ability to choose any VSP for other voice services. > > You seem to have assumed public key crypto. Is there a reason why > shared key could not be used? In some cases, the scenario is that a third party verifies the assertion, e.g., that a call was generated by customer42@phonecompany.com. As far as I know, this is most readily accomplished by using PK. In the case of the outbound proxy you asked about, standard authentication, such as SIP Digest auth, would work (based on shared keys). Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 17 22:17:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYE7m-0000Pe-Of; Tue, 17 May 2005 22:17:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYE7k-0000PZ-Ik for ecrit@megatron.ietf.org; Tue, 17 May 2005 22:17:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15379 for ; Tue, 17 May 2005 22:17:25 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYEOb-0002d8-T4 for ecrit@ietf.org; Tue, 17 May 2005 22:34:54 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Tue, 17 May 2005 22:17:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] WG: Review (part 1) of I-D :draft-schulzrinne-ecrit-requirements-00.txt Date: Tue, 17 May 2005 19:17:15 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575024EA750@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] WG: Review (part 1) of I-D :draft-schulzrinne-ecrit-requirements-00.txt Thread-Index: AcVSfG5supQyJEqRSZGS41N9yJhQXwIyqlzg From: "Roger Marshall" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org All: See listed below, a summary of the initial disposition of requirements, = produced at today's interim ecrit meeting. These results were based on = a working group review of the requirements listed in:=20 draft-schulzrinne-ecrit-requirements-00.txt 3 categories (with qualifiers) of disposition are: 1. Keep (as written, or with required changes to text) 2. Move (into another document) 3. Delete Note: Original requirement numbers (e.g. L1, L2, L3, etc.) which may get = deleted or moved, will not be reused. This means that there may be gaps = in the numbered sequence, (which is OK), and that any new requirements = will be added onto the end of each section (in the next revision of the = I-D). 3. High-Level Requirements R1 - Keep R2 - Keep R3 - Keep R4 - Keep R5 - Keep (Henning Schulzrinne to rewrite text) R6 - Keep (Ted Hardie to send candidate text as replacement for R6) R7 - Delete 4. Emergency Address A1 - Keep (possible reword of A1, may split into two separate = requirements) A2 - Move (Jon Peterson will advise Henning on destination for A2) A3 - Keep (reword along with A1 into two separable requirements) A4 - Keep A5 - Delete A6 - Keep (possible reword per Ted Hardie composed text) A7 - Delete 5. Identifying the Caller Location L1 - Move (L1, L2, & L3 to be put into a new document (to be created by = James Polk) with the goal of becoming an Informational RFC L2 - (see L1) L3 - (see L1) L4 - Move (into the Information doc) L5 - Move (Patti McCalmont to rewrite, consolidate with L11, move into = the Information doc) L6 - Keep (Nadine Abbott to supply additional text) L7 - Delete (out of scope) L8 - Delete (out of scope) L9 - Keep (Nadine to rewrite, for clarity to say "as input to the = mapping protocol" L10 - Keep (Hannes Tschofenig to lead further investigation w/Nadine, = Ted) L11 - Move (see L5) L12 - Delete (out of scope) L13 - Move (into the Information doc) Note: based on discussion around L13, Brian Rosen to write a new = requirement to say that mapping function must be independent of the call = (and at the time of the call) L14 - Delete (out of scope) L15 - Delete (out of scope) Note: based on discussion around L15, Brian Rosen to write a new = requirement re: default routing L16 - Delete (out of scope), (geopriv) L17 - Delete (out of scope) L18 - Delete (out of scope), (geopriv) L19 - Delete (out of scope), (geopriv) L20 - Delete (already discussed) L21 - Move (into Informational doc) L22 - Delete L23 - Delete L24 - Move (to (Hannes) security I-D) [end of discussion for 5/17 - will resume on 5/18] Please discuss any corrections/changes to above in tomorrow's meeting. Regards, Roger Marshall -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Tschofenig Hannes Sent: Friday, May 06, 2005 1:39 PM To: 'ecrit@ietf.org' Subject: [Ecrit] WG: I-D = ACTION:draft-schulzrinne-ecrit-requirements-00.txt hi all,=20 this document is an attempt to consolidate the requirements of the individual documents into a single document. as indicated at the ecrit working group meeting henning's document was used as the starting point. = the draft authors of the other requirements documents have tried to determine whether their requirements are already covered by henning's document. roger incorporated them if they weren't. roger also clean up = the terminology and removed non-relevant parts. thanks for the good work, = roger. please review the document carefully. we will spend some time at the = interim meeting to discuss the open issues.=20 ciao hannes -----Urspr=FCngliche Nachricht----- Von: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] Im Auftrag von Internet-Drafts@ietf.org Gesendet: Freitag, 6. Mai 2005 21:44 An: i-d-announce@ietf.org Betreff: I-D ACTION:draft-schulzrinne-ecrit-requirements-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Emergency Context Resolution=20 with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-schulzrinne-ecrit-requirements-00.txt Pages : 38 Date : 2005-5-6 =09 This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-= 00. txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schulzrinne-ecrit-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schulzrinne-ecrit-requirements-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 18 03:54:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYJOL-0006U3-SG; Wed, 18 May 2005 03:54:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYJOJ-0006Tv-Ls for ecrit@megatron.ietf.org; Wed, 18 May 2005 03:54:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15152 for ; Wed, 18 May 2005 03:54:53 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DYJfC-0003B8-Lz for ecrit@ietf.org; Wed, 18 May 2005 04:12:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Proposed replacement text for R6 Date: Wed, 18 May 2005 09:53:44 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B1F91@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Proposed replacement text for R6 Thread-Index: AcVbCzZWHMnPDk4ZQE6QpPTLfPU3VAActQ/A From: "Stastny Richard" To: "Ted Hardie" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, since I am (regrettable) not able to participate at the meeting, the proposed text seems somewhat cryptic to me. First I would like to see a definition of the ECRIT mapping protocol first and Second I do not fully understand the title of the requirement in the context of text: Incremental deployment. Best regards Richard Stastny OeFEG +43 664 420 4100 callto://fordprefect =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Ted Hardie > Sent: Tuesday, May 17, 2005 8:00 PM > To: ecrit@ietf.org > Subject: [Ecrit] Proposed replacement text for R6 >=20 > R6 Incremental Deployment >=20 > The output of the ECRIT mapping protocol will be one or more URIs > that can be used as the target of an emergency communication. These > must be usable by an appropriately capable device even if that device has > no knowledge of the mapping protocol. As an example, if the mapping > protocol returns a SIP URI any SIP-capable phone should be able to use > it as a target of the call; no special extension to SIP should be > required. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 18 04:13:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYJdY-0002W5-TM; Wed, 18 May 2005 04:10:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYJdU-0002VX-BW for ecrit@megatron.ietf.org; Wed, 18 May 2005 04:10:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15908 for ; Wed, 18 May 2005 04:10:34 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DYJuO-0003uc-Mx for ecrit@ietf.org; Wed, 18 May 2005 04:28:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] WG: Review (part 1) of I-D:draft-schulzrinne-ecrit-requirements-00.txt Date: Wed, 18 May 2005 10:09:31 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B1F93@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] WG: Review (part 1) of I-D:draft-schulzrinne-ecrit-requirements-00.txt Thread-Index: AcVSfG5supQyJEqRSZGS41N9yJhQXwIyqlzgAA5Tu0A= From: "Stastny Richard" To: "Roger Marshall" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Short comment: Regarding A reqs: I need to see the new text. Regarding L reqs: a basic question about the new Informational RFC: Some of the moved reqs are currently musts and shalls: how can these be in an Informational document? regards Richard Stastny OeFEG +43 664 420 4100 callto://fordprefect =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of > Roger Marshall > Sent: Wednesday, May 18, 2005 4:17 AM > To: ecrit@ietf.org > Subject: RE: [Ecrit] WG: Review (part 1) of = I-D:draft-schulzrinne-ecrit- > requirements-00.txt >=20 > All: > See listed below, a summary of the initial disposition of = requirements, > produced at today's interim ecrit meeting. These results were based = on a > working group review of the requirements listed in: >=20 > draft-schulzrinne-ecrit-requirements-00.txt >=20 > 3 categories (with qualifiers) of disposition are: > 1. Keep (as written, or with required changes to text) > 2. Move (into another document) > 3. Delete >=20 > Note: > Original requirement numbers (e.g. L1, L2, L3, etc.) which may get = deleted > or moved, will not be reused. This means that there may be gaps in = the > numbered sequence, (which is OK), and that any new requirements will = be > added onto the end of each section (in the next revision of the I-D). >=20 >=20 > 3. High-Level Requirements > R1 - Keep > R2 - Keep > R3 - Keep > R4 - Keep > R5 - Keep (Henning Schulzrinne to rewrite text) > R6 - Keep (Ted Hardie to send candidate text as replacement for R6) > R7 - Delete >=20 > 4. Emergency Address > A1 - Keep (possible reword of A1, may split into two separate > requirements) > A2 - Move (Jon Peterson will advise Henning on destination for A2) > A3 - Keep (reword along with A1 into two separable requirements) > A4 - Keep > A5 - Delete > A6 - Keep (possible reword per Ted Hardie composed text) > A7 - Delete >=20 > 5. Identifying the Caller Location > L1 - Move (L1, L2, & L3 to be put into a new document (to be created = by > James Polk) with the goal of becoming an Informational RFC > L2 - (see L1) > L3 - (see L1) > L4 - Move (into the Information doc) > L5 - Move (Patti McCalmont to rewrite, consolidate with L11, move into = the > Information doc) > L6 - Keep (Nadine Abbott to supply additional text) > L7 - Delete (out of scope) > L8 - Delete (out of scope) > L9 - Keep (Nadine to rewrite, for clarity to say "as input to the = mapping > protocol" > L10 - Keep (Hannes Tschofenig to lead further investigation w/Nadine, = Ted) > L11 - Move (see L5) > L12 - Delete (out of scope) > L13 - Move (into the Information doc) >=20 > Note: based on discussion around L13, Brian Rosen to write a new > requirement to say that mapping function must be independent of the = call > (and at the time of the call) >=20 > L14 - Delete (out of scope) > L15 - Delete (out of scope) >=20 > Note: based on discussion around L15, Brian Rosen to write a new > requirement re: default routing >=20 > L16 - Delete (out of scope), (geopriv) > L17 - Delete (out of scope) > L18 - Delete (out of scope), (geopriv) > L19 - Delete (out of scope), (geopriv) > L20 - Delete (already discussed) > L21 - Move (into Informational doc) > L22 - Delete > L23 - Delete > L24 - Move (to (Hannes) security I-D) >=20 > [end of discussion for 5/17 - will resume on 5/18] >=20 > Please discuss any corrections/changes to above in tomorrow's meeting. >=20 > Regards, >=20 >=20 > Roger Marshall >=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of > Tschofenig Hannes > Sent: Friday, May 06, 2005 1:39 PM > To: 'ecrit@ietf.org' > Subject: [Ecrit] WG: I-D ACTION:draft-schulzrinne-ecrit-requirements- > 00.txt >=20 > hi all, >=20 > this document is an attempt to consolidate the requirements of the > individual documents into a single document. as indicated at the ecrit > working group meeting henning's document was used as the starting = point. > the draft authors of the other requirements documents have tried to > determine whether their requirements are already covered by henning's > document. roger incorporated them if they weren't. roger also clean up = the > terminology and removed non-relevant parts. thanks for the good work, > roger. >=20 >=20 > please review the document carefully. we will spend some time at the > interim > meeting to discuss the open issues. >=20 > ciao > hannes >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] > Im > Auftrag von Internet-Drafts@ietf.org > Gesendet: Freitag, 6. Mai 2005 21:44 > An: i-d-announce@ietf.org > Betreff: I-D ACTION:draft-schulzrinne-ecrit-requirements-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Requirements for Emergency Context Resolution > with Internet Technologies > Author(s) : H. Schulzrinne, R. Marshall > Filename : draft-schulzrinne-ecrit-requirements-00.txt > Pages : 38 > Date : 2005-5-6 >=20 > This document enumerates requirements for emergency calls placed by > the public using voice-over-IP (VoIP) and general Internet = multimedia > systems, where Internet protocols are used end-to-end. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-= > 00. > txt >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of = the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-schulzrinne-ecrit-requirements-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-schulzrinne-ecrit-requirements-00.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 18 08:50:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYO0C-0004Rq-R0; Wed, 18 May 2005 08:50:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYO0A-0004RH-2l for ecrit@megatron.ietf.org; Wed, 18 May 2005 08:50:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14585 for ; Wed, 18 May 2005 08:50:16 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYOH6-0003kf-1a for ecrit@ietf.org; Wed, 18 May 2005 09:07:49 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4ICo3dv026040; Wed, 18 May 2005 05:50:04 -0700 (PDT) Received: from [160.39.251.93] (vpn-10-50-0-44.qualcomm.com [10.50.0.44]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4ICo12o023074; Wed, 18 May 2005 05:50:02 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Wed, 18 May 2005 05:49:59 -0700 To: winterb@nortelnetworks.com From: Ted Hardie Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ecrit@ietf.org Subject: [Ecrit] L25 question X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi James, In L25, there was a question on the meaning of the text. Do we mean "access domain" as in "columbia university, which runs this network" and the source is "some ap sending location by dhcp" or is it "access domain" ="NENA access domain" and source is "columbia university"? Either the way the group felt it to be out of scope, but knowing which way to face the follow on question depends on the answer. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 18 09:29:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYOc7-0001Qj-Ix; Wed, 18 May 2005 09:29:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYOc5-0001Qe-IA for ecrit@megatron.ietf.org; Wed, 18 May 2005 09:29:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19427 for ; Wed, 18 May 2005 09:29:27 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYOt2-0006Mx-SI for ecrit@ietf.org; Wed, 18 May 2005 09:47:01 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4IDTHCK003712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 May 2005 06:29:17 -0700 (PDT) Received: from [160.39.251.93] (vpn-10-50-0-44.qualcomm.com [10.50.0.44]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4IDTD2o026659; Wed, 18 May 2005 06:29:15 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B1F91@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D461B1F91@oefeg-s04.oefeg.loc> Date: Wed, 18 May 2005 06:29:12 -0700 To: "Stastny Richard" , From: Ted Hardie Subject: RE: [Ecrit] Proposed replacement text for R6 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 9:53 AM +0200 5/18/05, Stastny Richard wrote: >Hi all, > >since I am (regrettable) not able to participate at the meeting, the >proposed text seems somewhat cryptic to me. > >First I would like to see a definition of the ECRIT mapping protocol >first and >Second I do not fully understand the title of the requirement >in the context of text: Incremental deployment. Hi Richard, To take these back to front, "Incremental Deployment" was the original title and I didn't change it, so it probably does need to change. In considering the original R6, this was the requirement that seemed to fall out--that a device currently capable of using the contact protocol (e.g. SIP) should continue to work for emergency calling even if it doesn't do the mapping itself. The mapping protocol has not been chosen; it's logically the part of the process in which the location is used to select an appropriate contact URI. regards, Ted Hardie >Best regards > >Richard Stastny >OeFEG >+43 664 420 4100 >callto://fordprefect > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of >> Ted Hardie >> Sent: Tuesday, May 17, 2005 8:00 PM >> To: ecrit@ietf.org >> Subject: [Ecrit] Proposed replacement text for R6 >> >> R6 Incremental Deployment >> >> The output of the ECRIT mapping protocol will be one or more URIs >> that can be used as the target of an emergency communication. These >> must be usable by an appropriately capable device even if that device >has >> no knowledge of the mapping protocol. As an example, if the mapping >> protocol returns a SIP URI any SIP-capable phone should be able to use >> it as a target of the call; no special extension to SIP should be >> required. >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 18 09:47:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYOt4-0005xY-Sl; Wed, 18 May 2005 09:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYOt2-0005xQ-QY for ecrit@megatron.ietf.org; Wed, 18 May 2005 09:47:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20964 for ; Wed, 18 May 2005 09:46:58 -0400 (EDT) Message-Id: <200505181346.JAA20964@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYP9z-0007JF-Jz for ecrit@ietf.org; Wed, 18 May 2005 10:04:32 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DYOsq-00076Z-OT for ecrit@ietf.org; Wed, 18 May 2005 08:46:48 -0500 From: "Brian Rosen" To: Date: Wed, 18 May 2005 09:46:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVbsALZkh1dj3P6RfGFzFMZn5VDyw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit Subject: [Ecrit] Text for I7 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I7. Traceable resolution: The entity requesting mapping SHOULD be able to definitively and securely determine the entity or entities who provided the emergency address resolution information. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 18 10:20:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYPPl-0001I5-NL; Wed, 18 May 2005 10:20:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYPPj-0001I0-RR for ecrit@megatron.ietf.org; Wed, 18 May 2005 10:20:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24961 for ; Wed, 18 May 2005 10:20:45 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYPgg-0000uu-Ua for ecrit@ietf.org; Wed, 18 May 2005 10:38:20 -0400 Received: from [160.39.247.24] (dyn-160-39-247-24.dyn.columbia.edu [160.39.247.24]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4IEKglN009687 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 May 2005 10:20:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: <7E012DC3-0EF0-4DC5-8285-1F06C93664B7@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ecrit@ietf.org From: Henning Schulzrinne Date: Wed, 18 May 2005 10:20:47 -0400 X-Mailer: Apple Mail (2.728) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.6 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: [Ecrit] I3, I4, I8 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I3: Multi-stage resolution The mapping protocol MUST be able to resolve a location to a URL incrementally, i.e., provide a URL that represents a larger geographic area, where another invocation of the mapping protocol then provides a more fine-grained resolution. Motivation: In some cases, an initial mapping may provide a single URL for a large geographic area. The ESRP identified by that URL then re-invokes the mapping protocol on a different database to obtain another URL for an ESRP or PSAP covering a smaller area. I4: Return multiple PSAPs The mapping protocol MUST be able to return multiple URLs for different PSAPs that cover the same area. The mapping protocol MUST provide additional information that allows the querying entity to determine relevant properties of the URL. Motivation: In some cases, the same geographic area is served by several PSAPs, for example, a corporate campus might be served by both a corporate security department and the municipal PSAP. The mapping protocol should then return URLs for both, with information allowing the querying entity to choose one or the other. The choice would typically be made by an ESRP based on local policy, not by a human user. I8: Resilience against server failure A client MUST be able to fail over to another replica of the mapping server, so that a failure of a server does not endanger the ability to perform the mapping. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 18 10:42:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYPkH-0000hW-Pw; Wed, 18 May 2005 10:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYPkF-0000fF-Sl for ecrit@megatron.ietf.org; Wed, 18 May 2005 10:41:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27223 for ; Wed, 18 May 2005 10:41:57 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYQ1D-0002DI-8N for ecrit@ietf.org; Wed, 18 May 2005 10:59:32 -0400 Received: from [160.39.247.24] (dyn-160-39-247-24.dyn.columbia.edu [160.39.247.24]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4IEfv01014927 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 May 2005 10:41:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: <506490FD-CCE1-41BF-A234-74AEA541C5D6@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ecrit@ietf.org From: Henning Schulzrinne Date: Wed, 18 May 2005 10:42:02 -0400 X-Mailer: Apple Mail (2.728) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [Ecrit] I25 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Mapping can be requested from anywhere The mapping protocol MUST be able to provide the mapping regardless of where the querier is located, either geographically or by network location. Motivation: The querier, such as the ESRP, may not necessarily be anywhere close to the caller or the appropriate PSAP, but must still be able to obtain a mapping. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 18 10:58:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYPzs-0005YF-Ox; Wed, 18 May 2005 10:58:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYPzq-0005Xt-GG for ecrit@megatron.ietf.org; Wed, 18 May 2005 10:58:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28787 for ; Wed, 18 May 2005 10:58:04 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYQGi-00038D-K1 for ecrit@ietf.org; Wed, 18 May 2005 11:15:39 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4IEvlCK011427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 18 May 2005 07:57:48 -0700 (PDT) Received: from [160.39.251.93] (vpn-10-50-0-44.qualcomm.com [10.50.0.44]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4IEvilF003959 for ; Wed, 18 May 2005 07:57:45 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Wed, 18 May 2005 07:57:42 -0700 To: ecrit@ietf.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Ecrit] Proposed update to I-31 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org In response to a mapping request, a server will normally provide a URI or set of URIs for contacting the appropriate PSAP. The protocol must also be to return a URI or contact method explicitly marked as an alternate contact. When this is used will be described in an operational document. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 18 11:21:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQMg-0004sz-LQ; Wed, 18 May 2005 11:21:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQMf-0004rx-SL for ecrit@megatron.ietf.org; Wed, 18 May 2005 11:21:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01091 for ; Wed, 18 May 2005 11:21:39 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYQdd-0004YJ-E8 for ecrit@ietf.org; Wed, 18 May 2005 11:39:14 -0400 Received: from [160.39.247.24] (dyn-160-39-247-24.dyn.columbia.edu [160.39.247.24]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4IFLVB5024894 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 May 2005 11:21:31 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ecrit@ietf.org From: Henning Schulzrinne Date: Wed, 18 May 2005 11:21:35 -0400 X-Mailer: Apple Mail (2.728) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [Ecrit] D1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The mapping information MUST be available without having to use a service provider. Motivation: The mapping server may well be operated by a service provider, but access to the server offering the mapping MUST NOT require use of a specific ISP or VSP. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 18 11:34:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQYy-0000k0-2P; Wed, 18 May 2005 11:34:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQYu-0000js-Tw for ecrit@megatron.ietf.org; Wed, 18 May 2005 11:34:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02554 for ; Wed, 18 May 2005 11:34:17 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYQps-0005KL-6x for ecrit@ietf.org; Wed, 18 May 2005 11:51:53 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4IFXuCK015271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 May 2005 08:33:56 -0700 (PDT) Received: from [160.39.251.93] (vpn-10-50-0-44.qualcomm.com [10.50.0.44]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4IFXrsH017113; Wed, 18 May 2005 08:33:54 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 18 May 2005 08:33:51 -0700 To: Henning Schulzrinne , ecrit@ietf.org From: Ted Hardie Subject: Re: [Ecrit] D1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 11:21 AM -0400 5/18/05, Henning Schulzrinne wrote: >The mapping information MUST be available without having to use a >service provider. Would "enroll with a service provider" be clearer? I think we're trying to say that you don't need to have a business relationship with the service provider in order to do the mapping, but "use a service provider" is a bit ambiguous. regards, Ted >Motivation: The mapping server may well be operated by a service >provider, but access to the server offering the mapping MUST NOT >require use of a specific ISP or VSP. > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 18 11:36:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQau-0001Q8-Q6; Wed, 18 May 2005 11:36:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQas-0001KY-86 for ecrit@megatron.ietf.org; Wed, 18 May 2005 11:36:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02722 for ; Wed, 18 May 2005 11:36:19 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYQrq-0005T2-2g for ecrit@ietf.org; Wed, 18 May 2005 11:53:55 -0400 Received: from [160.39.247.24] (dyn-160-39-247-24.dyn.columbia.edu [160.39.247.24]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4IFaHEl009423 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 18 May 2005 11:36:20 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] D1 Date: Wed, 18 May 2005 11:36:21 -0400 To: Ted Hardie X-Mailer: Apple Mail (2.728) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yes, that would work. On May 18, 2005, at 11:33 AM, Ted Hardie wrote: > At 11:21 AM -0400 5/18/05, Henning Schulzrinne wrote: > >> The mapping information MUST be available without having to use a >> service provider. >> > > Would "enroll with a service provider" be clearer? I think we're > trying > to say that you don't need to have a business relationship with the > service > provider in order to do the mapping, but "use a service provider" is > a bit ambiguous. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 18 11:41:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQfQ-0003OR-HQ; Wed, 18 May 2005 11:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQfP-0003OM-98 for ecrit@megatron.ietf.org; Wed, 18 May 2005 11:41:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03366 for ; Wed, 18 May 2005 11:41:00 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYQwN-0005pV-1M for ecrit@ietf.org; Wed, 18 May 2005 11:58:36 -0400 Received: from [160.39.247.24] (dyn-160-39-247-24.dyn.columbia.edu [160.39.247.24]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4IFexRG014222 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 May 2005 11:40:59 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: <8A50CDC7-9AB7-4282-9382-4FE4DB2D9422@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ecrit@ietf.org From: Henning Schulzrinne Date: Wed, 18 May 2005 11:41:03 -0400 X-Mailer: Apple Mail (2.728) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Ecrit] D7 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Referral: The querier MUST be able to contact any server and be referred to another server that is more qualified to answer the query. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 18 11:48:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQma-0005yx-Gs; Wed, 18 May 2005 11:48:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQmY-0005yo-Gq for ecrit@megatron.ietf.org; Wed, 18 May 2005 11:48:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04439 for ; Wed, 18 May 2005 11:48:22 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYR3V-0006II-Cl for ecrit@ietf.org; Wed, 18 May 2005 12:05:58 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 May 2005 08:48:15 -0700 Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4IFmAER006569 for ; Wed, 18 May 2005 08:48:10 -0700 (PDT) Received: from MLINSNER (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA16588 for ; Wed, 18 May 2005 08:48:12 -0700 (PDT) Message-Id: <200505181548.IAA16588@malone.cisco.com> From: "Marc Linsner" To: Date: Wed, 18 May 2005 11:47:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Thread-Index: AcVbwPFHXRejgDDNRlG14AEQcHmuTg== X-Spam-Score: 1.1 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [Ecrit] Security Presentation X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The interim preso on security can be found at: http://www.ietf-ecrit.org/Interim2005/ecrit-security.ppt -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 18 13:37:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYSUG-0006iU-4E; Wed, 18 May 2005 13:37:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYSUE-0006iP-To for ecrit@megatron.ietf.org; Wed, 18 May 2005 13:37:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16281 for ; Wed, 18 May 2005 13:37:37 -0400 (EDT) Message-Id: <200505181737.NAA16281@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYSlD-00031Q-Q7 for ecrit@ietf.org; Wed, 18 May 2005 13:55:13 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DYSU4-0003G0-1y for ecrit@ietf.org; Wed, 18 May 2005 12:37:28 -0500 From: "Brian Rosen" To: Date: Wed, 18 May 2005 13:37:17 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVb0Dx1j5mj5FxfShG0/ayWMMAXDg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [Ecrit] New Text for i10 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0919026848==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0919026848== Content-Type: multipart/alternative; boundary="----=_NextPart_000_03DB_01C55BAE.B63B8BC0" This is a multi-part message in MIME format. ------=_NextPart_000_03DB_01C55BAE.B63B8BC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Incrementally deployable: The mapping function MUST be capable of being deployed incrementally. It must not be necessary, for example, to have a global street level database before deploying the system. It is acceptable to have some misrouting of calls when the database does not (yet) contain accurate boundary information. ------=_NextPart_000_03DB_01C55BAE.B63B8BC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
      Incrementally =
deployable: The mapping function MUST be capable of being deployed =
incrementally.  It must not be necessary, for example, to have a =
global street level database before deploying the system.  It is =
acceptable to have some misrouting of calls when the database does not =
(yet) contain accurate boundary =
information.

 

------=_NextPart_000_03DB_01C55BAE.B63B8BC0-- --===============0919026848== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0919026848==-- From ecrit-bounces@ietf.org Wed May 18 13:43:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYSaE-0008At-Qw; Wed, 18 May 2005 13:43:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYSaD-0008Ao-T4 for ecrit@megatron.ietf.org; Wed, 18 May 2005 13:43:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16847 for ; Wed, 18 May 2005 13:43:48 -0400 (EDT) Message-Id: <200505181743.NAA16847@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYSrD-0003HN-Pe for ecrit@ietf.org; Wed, 18 May 2005 14:01:24 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DYSa4-0003Uz-B5 for ecrit@ietf.org; Wed, 18 May 2005 12:43:40 -0500 From: "Brian Rosen" To: Date: Wed, 18 May 2005 13:43:30 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVb0Rp3P0iljC3uSO+ZQznDsbt63g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [Ecrit] Possible replacement for I13 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1730664310==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1730664310== Content-Type: multipart/alternative; boundary="----=_NextPart_000_03E5_01C55BAF.943A4BA0" This is a multi-part message in MIME format. ------=_NextPart_000_03E5_01C55BAF.943A4BA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I13. Existing infrastructure support: It SHOULD be possible for the mapping function to provide information that allows the requesting entity to determine if ecrit compatible emergency call support is available in the jurisdiction where the location is proferred for mapping. Where ecrit compatible emergency calling is NOT available, the mapping function MAY yield information which could be used to route emergency calls using existing, country specific methods. For example, a tel URI may be provided for a PSTN routed call, or a routing code which has meaning only within a country specific routing mechanism. Ed note: would "IP emergency call termination, or IP based emergency call information be a better choice than "ecrit compatible"? ------=_NextPart_000_03E5_01C55BAF.943A4BA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
I13.  Existing infrastructure support: =
It SHOULD be possible for the mapping function to provide information =
that allows the requesting entity to determine if ecrit compatible =
emergency call support is available in the jurisdiction where the =
location is proferred for mapping.  Where ecrit compatible =
emergency calling is NOT available, the mapping function MAY yield =
information which could be used to route emergency calls using existing, =
country specific methods.  For example, a tel URI may be provided =
for a PSTN routed call, or a routing code which has meaning only within =
a country specific routing =
mechanism.
 
Ed note: =
would “IP emergency call termination, or IP based emergency call =
information be a better choice than “ecrit =
compatible”?

 

------=_NextPart_000_03E5_01C55BAF.943A4BA0-- --===============1730664310== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1730664310==-- From ecrit-bounces@ietf.org Wed May 18 14:29:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYTI5-0006b5-1I; Wed, 18 May 2005 14:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYTI3-0006av-0X for ecrit@megatron.ietf.org; Wed, 18 May 2005 14:29:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21323 for ; Wed, 18 May 2005 14:29:02 -0400 (EDT) Received: from dnsmx2pya.telcordia.com ([128.96.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYTYy-0005KF-TR for ecrit@ietf.org; Wed, 18 May 2005 14:46:39 -0400 Received: from rrc-its-ieg01.cc.telcordia.com (rrc-its-ieg01.cc.telcordia.com [128.96.109.78]) by dnsmx2pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j4IISnj16775; Wed, 18 May 2005 14:28:49 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-its-ieg01.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005051814284500740 ; Wed, 18 May 2005 14:28:45 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 May 2005 14:27:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 May 2005 14:27:27 -0400 Message-ID: Thread-Topic: Location Validation defn and L9 re-write (to include others) Thread-Index: AcVb11R8N0rc+VKwSIG6AwMbvJmpuA== From: "Abbott, Nadine B" To: "Roger Marshall" X-OriginalArrivalTime: 18 May 2005 18:27:49.0596 (UTC) FILETIME=[4BB1B1C0:01C55BD7] X-Spam-Score: 0.5 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ecrit@ietf.org Subject: [Ecrit] Location Validation defn and L9 re-write (to include others) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0965577893==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0965577893== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55BD7.3E85D10F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55BD7.3E85D10F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Roger, =20 Proposed new text for the ecrit requirements document, as requested. =20 =20 Definition of Location Validation (to support L6) Location validation refers to a process to determine whether or not a given civic location is valid or not. A location is said to be valid if it can be mapped exactly to a unique emergency address for a PSAP, known to the emergency services directory/mapping database. L9 re-write to include various other related requirements L9. The mapping protocol MUST be extensible to allow for the inclusion of new location fields. Motivation: This is needed, for example, to accommodate future extensions to location information that might be included in the PIDF-LO. =20 Nadine ------_=_NextPart_001_01C55BD7.3E85D10F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Roger,
 
Proposed new text=20 for the ecrit requirements document, as requested.
 
 
Definition of=20 Location Validation (to support L6)
Location=20 validation refers to a process to determine whether or not a given = civic=20 location is valid or not.  A location is said to be valid if it = can be=20 mapped exactly to a unique emergency address for a PSAP, known to the=20 emergency services directory/mapping = database.
L9  re-write to=20 include various other related requirements
L9.  The=20 mapping protocol MUST be extensible to allow for the inclusion of new = location=20 fields.
Motivation: This=20 is needed, for example, to accommodate future extensions to location=20 information that might be included in the=20 PIDF-LO.
 
Nadine
=00 ------_=_NextPart_001_01C55BD7.3E85D10F-- --===============0965577893== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0965577893==-- From ecrit-bounces@ietf.org Wed May 18 15:22:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYU7s-0004Hj-Vw; Wed, 18 May 2005 15:22:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYU7r-0004HJ-Du for ecrit@megatron.ietf.org; Wed, 18 May 2005 15:22:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26666 for ; Wed, 18 May 2005 15:22:37 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYUOp-0007Ro-NF for ecrit@ietf.org; Wed, 18 May 2005 15:40:14 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 18 May 2005 15:22:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] WG: Updated Req Review of I-D:draft-schulzrinne-ecrit-requirements-00.txt Date: Wed, 18 May 2005 12:22:21 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575025215F8@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] WG: Updated Req Review of I-D:draft-schulzrinne-ecrit-requirements-00.txt Thread-Index: AcVSfG5supQyJEqRSZGS41N9yJhQXwIyqlzgAB61AZA= From: "Roger Marshall" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org All: RE: ECRIT REQUIREMENTS REVIEW UPDATE: Below is a completed disposition status listing of ALL ecrit (I-D) = requirements, based on continued (5/18) interim ecrit meeting this = morning. These results are associated with review of requirements listed in:=20 draft-schulzrinne-ecrit-requirements-00.txt 3 categories (with qualifiers) of disposition are: 1. Keep (as written, or with required changes to text) 2. Move (into another document) 3. Delete (remove, possibly merge into other requirement) Note: Original requirement numbers will not be reused. New requirements will = be added onto the end of each section (in the next revision of the I-D). 3. High-Level Requirements R1 - Keep R2 - Keep R3 - Keep R4 - Keep R5 - Keep (Henning Schulzrinne to rewrite text) R6 - Keep (Ted Hardie to send candidate text as replacement for R6) R7 - Delete 4. Emergency Address A1 - Keep (possible reword of A1, may split into two separate = requirements) A2 - Move (Jon Peterson will advise Henning on destination for A2) A3 - Keep (reword along with A1 into two separable requirements) A4 - Keep A5 - Delete A6 - Keep (possible reword per Ted Hardie composed text) A7 - Delete 5. Identifying the Caller Location L1 - Move (L1, L2, & L3 to be put into a new document (to be created by = James Polk) with the goal of becoming an Informational RFC L2 - (see L1) L3 - (see L1) L4 - Move (into the Information doc) L5 - Move (Patti McCalmont to rewrite, consolidate with L11, move into = the Information doc) L6 - Keep (Nadine Abbott to supply additional text) L7 - Delete (out of scope) L8 - Delete (out of scope) L9 - Keep (Nadine to rewrite, for clarity to say "as input to the = mapping protocol" L10 - Keep (Hannes Tschofenig to lead further investigation w/Nadine, = Ted) L11 - Move (see L5) L12 - Delete (out of scope) L13 - Move (into the Information doc) Note: based on discussion around L13, Brian Rosen to write a new = requirement to say that mapping function must be independent of the call = (and at the time of the call) L14 - Delete (out of scope) L15 - Delete (out of scope) Note: based on discussion around L15, Brian Rosen to write a new = requirement re: default routing L16 - Delete (out of scope), (geopriv) L17 - Delete (out of scope) L18 - Delete (out of scope), (geopriv) L19 - Delete (out of scope), (geopriv) L20 - Delete (already discussed) L21 - Move (into Informational doc) [start of 5/18 discussion] L22 - (Change to:) Move (to Informational doc/BCP)=20 L23 - Delete L24 - (Change to:) Move (to Informational doc/BCP) L25 - Move (into Informational doc) L26 - Delete (out of scope) L27 - Delete (out of scope) L28 - Keep (James Polk to provide reworded text) L29 - Delete (out of scope) L30 - Delete (out of scope, covered elsewhere) 6. Identifying the Appropriate Emergency Call Center Note 1: Delete following paragraph from text block: "Note that the first proxy, the ESRP, doing the translation may not = be in the same geographic area as the UA placing the emergency call." Note 2: Consolidate following terms (throughout document): ECC; iPSAP, = IP-PSAP all become one term, PSAP. I1 - Keep (reword as "Calls Must be routed to the PSAP responsible for = this particular geographic area") I2 - Move (into Informational doc) I3 - Keep (rewrite, Henning will send text) I4 - Keep (rewrite, Henning and Patti McCalmont to collaborate on text) I5 - Delete (out of scope) I6 - Delete (out of scope) I7 - Keep (rewrite, Brian Rosen to send text) I8 - Keep (rewrite, Henning to send text) I9 - Keep (rewrite, Henning to send text) I10 - Keep (Brian to rewrite as standalone requirement) I11 - Delete (out of scope) I12 - Move (to Informational doc) I13 - Delete (out of scope) I14 - Delete (redundant, mapping can be done based on any PIDF-LO field = (see L9) I15 - Move (to Informational doc) I16 - Move (to Informational doc) I17 - Move (to Informational doc) I18 - Move (to Informational doc) I19 - Move (to Informational doc) I20 - Move (to Informational doc) I21 - Delete (per rewritten I3/I4 by henning) I22 - Move (to Informational doc) I23 - Delete I24 - Delete I25 - Keep (to be rewritten by Henning) I26 - Move (to Informational doc) I27 - Move (to Informational doc) I28 - Move (to Informational doc) I29 - Delete I30 - Move (to security document as an update) I31 - Keep (rewrite, Ted Hardie to send text) I32 - Delete I33 - Delete I34 - Move (to Informational doc) I35 - Delete (merged into I31) I36 - Move (to Informational doc, merge with Traceability) I37 - Delete (out of scope) I38 - Delete I39 - Delete (merge with L13) 7. Emergency Address Directory D1 - Keep (rewrite, Henning to send text) D2 - Move (to security doc) D3 - Move (to security doc) D4 - Delete (out of scope) D5 - Keep (rewrite, Marc Linsner to send text as, "to specify minimize = number of round trips rather than minimizing time") D6 - Delete (already covered in rewritten I3/I4 by Henning) D7 - Keep (rewrite, Henning to send text) D8 - Move (combine with D9) & Delete Motivation text D9 - Keep (rewrite to include D8) 8. Identifying the Caller C1 - Move (to Informational doc) C2 - Move (to Informational doc) C3 - Move (to Informational doc) 9. Call Setup and Call Features S1 - Move (to security doc) S2 - Move (to informational doc) S3 - Delete S4 - Move (to security doc) S5 - Move (to informational doc) S6 - Delete S7 - Move (to informational doc) S8 - Move (to informational doc) S9 - Delete (collapses into tracking and tracing I7) 10. Supplemental Information SD1 - Keep (rewrite, Tom Taylor to send extensibility requirement) SD2 - SD9 Delete (merge into rewritten SD1, above) 11. Security Considerations SEC1 - Move (to security document/discussion) SEC2 - Move (to security document/discussion) SEC3 - Move (to security document/discussion) [end of ecrit requirements I-D discussion for 5/18] Per chairs' instruction, please post rewrites (where noted) onto the = list for discussion by wg. Regards, Roger Marshall -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Tschofenig Hannes Sent: Friday, May 06, 2005 1:39 PM To: 'ecrit@ietf.org' Subject: [Ecrit] WG: I-D = ACTION:draft-schulzrinne-ecrit-requirements-00.txt hi all,=20 this document is an attempt to consolidate the requirements of the individual documents into a single document. as indicated at the ecrit working group meeting henning's document was used as the starting point. = the draft authors of the other requirements documents have tried to determine whether their requirements are already covered by henning's document. roger incorporated them if they weren't. roger also clean up = the terminology and removed non-relevant parts. thanks for the good work, = roger. please review the document carefully. we will spend some time at the = interim meeting to discuss the open issues.=20 ciao hannes -----Urspr=FCngliche Nachricht----- Von: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] Im Auftrag von Internet-Drafts@ietf.org Gesendet: Freitag, 6. Mai 2005 21:44 An: i-d-announce@ietf.org Betreff: I-D ACTION:draft-schulzrinne-ecrit-requirements-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Emergency Context Resolution=20 with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-schulzrinne-ecrit-requirements-00.txt Pages : 38 Date : 2005-5-6 =09 This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-= 00. txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schulzrinne-ecrit-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schulzrinne-ecrit-requirements-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 20 10:29:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ8VL-00079H-EN; Fri, 20 May 2005 10:29:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ8VK-00078M-Ca; Fri, 20 May 2005 10:29:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22096; Fri, 20 May 2005 10:29:31 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ8mg-0003Nb-Sf; Fri, 20 May 2005 10:47:31 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j4KESBQ09617; Fri, 20 May 2005 10:28:11 -0400 (EDT) Received: from [127.0.0.1] (acart536.ca.nortel.com [47.130.17.193]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29WLYVSM; Fri, 20 May 2005 10:28:46 -0400 Message-ID: <428DF41A.3030406@nortel.com> Date: Fri, 20 May 2005 10:28:42 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] RE: [Geopriv] Deployment models References: <200505171148.HAA11818@ietf.org> In-Reply-To: <200505171148.HAA11818@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I don't think the detailed access model matters to our work. IAP is an enetity that provides location information based on L1 and/or L2 knowledge. I don't think we in the IETF need to know the detailed structure of this entity, even though that structure can be of great practical importance. Brian Rosen wrote: >I agree with these model descriptions. I have problems with terminology. > >I think we all know and agree with the term "Internet Service Provider". A >customer has a direct relationship with his ISP. > >I have been using the term "Access Infrastructure Provider" for the entity >that actually owns the infrastructure. This may or may not be the ISP. >However, when the AIP and the ISP are not the same entity, the ISP >borrows/rents/leases facilities from the AIP. Location is always reported >to the subscriber by the ISP. The AIP is the entity that actually knows >where the subscriber is. Location is always originated by (and possibly >signed by) the AIP. There are cases where the infrastructure is split >between two entities. For example, one entity may actually own the wires, >and another the layer 2 infrastructure. Again, there are contractual >relationships between these parties. I'm calling the AIP the Layer 2 >entity. The ISP provides IP packet forwarding. > >I'm not sure what entity an IAP is. > >Brian > > > >>-----Original Message----- >>From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf >>Of Henning Schulzrinne >>Sent: Monday, May 16, 2005 11:06 PM >>To: geopriv@ietf.org; 'ecrit@ietf.org' >>Subject: [Geopriv] Deployment models >> >>We had discussed several deployment models (network architectures), >>including, roughly in order of challenge: >> >>(Vertical integration) Network access and call signaling (SIP) operated >>by the same entity or at least two entities with a close relationship; >>for example, the IAP operates an outbound proxy in each subnet that can >>insert or provide location information; >> >>(User cert) The IAP and VSP are separate entities that don't cooperate, >>but the IAP might operate an outbound proxy that provides identity >>assertion based on access identity. >> >>(Certified customer, no relationship) The IAP hands out customer >>certificates that allow a user to certify that they are known to a >>larger entity. Customers can give their private keys to their evil twins >>and shady friends, but they would presumably face some liability for >>this. The VSP is a separate entity in this case. >> >>(No relationship) The IAP and VSP have no relationship; one certifies >>location and maybe a customer name, the other an identity only. There is >>no long-term stable relationship between the access identifier and the >>voice identifier. (Indeed, there may not be any voice identifier as >>such, as the caller may just run its own SIP client, without the benefit >>of a Vonage-like entity.) >> >>The basic assumption is that the IAP provides location (and maybe >>identity), the VSP identity, but no location. Obviously, in the first >>case, they are the same, so the distinction is moot. >> >>This only matters if the receiver can discriminate under overload. If >>the receiving call center is somehow obligated to take all calls with >>equal probability, signing does not matter, except to prevent a bad >>actor from modifying in-transit signaling requests (for which channel >>security is probably a better approach). >> >>In all cases, it doesn't matter for this discussion whether the location >>is identified by a location object or some pointer to a location object. >> >> >>Henning >> >>_______________________________________________ >>Geopriv mailing list >>Geopriv@ietf.org >>https://www1.ietf.org/mailman/listinfo/geopriv >> >> >> > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 21 15:32:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZZiB-0007ME-1t; Sat, 21 May 2005 15:32:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZZi9-0007M3-Cl for ecrit@megatron.ietf.org; Sat, 21 May 2005 15:32:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19117 for ; Sat, 21 May 2005 15:32:33 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZZzj-0005Vu-ER for ecrit@ietf.org; Sat, 21 May 2005 15:50:48 -0400 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j4LJWTSa003212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 21 May 2005 15:32:29 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j4LJWQwJ032455 for ; Sat, 21 May 2005 15:32:28 -0400 Message-ID: <428F8CCB.5080702@cs.columbia.edu> Date: Sat, 21 May 2005 21:32:27 +0200 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Proposed requirement: split responsibility X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org We discussed towards the end at the interim meeting, but I don't think we have documented this requirement: Lx (?): Split responsibility The mapping protocol MUST allow that within a single level of the civic address hierarchy, multiple mapping servers handle subsets of the data elements. Motivation: For example, two directories for the same city or county may handle different streets within that city or county. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun May 22 11:03:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZrz2-000880-Cz; Sun, 22 May 2005 11:03:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZryy-00087s-8i for ecrit@megatron.ietf.org; Sun, 22 May 2005 11:03:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23354 for ; Sun, 22 May 2005 11:03:10 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZsGk-0005pp-IH for ecrit@ietf.org; Sun, 22 May 2005 11:21:35 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Sun, 22 May 2005 11:03:07 -0400 id 000FFC88.42909F2B.000012F1 In-Reply-To: <428F8CCB.5080702@cs.columbia.edu> References: <428F8CCB.5080702@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3f66d1f7a8b55c22b93a39203ab8c47f@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Proposed requirement: split responsibility Date: Sun, 22 May 2005 11:03:06 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On May 21, 2005, at 3:32 PM, Henning Schulzrinne wrote: > We discussed towards the end at the interim meeting, but I don't think > we have documented this requirement: > > Lx (?): Split responsibility > > The mapping protocol MUST allow that within a single level of the > civic address hierarchy, multiple mapping servers handle subsets of > the data elements. > > Motivation: For example, two directories for the same city or county > may handle different streets within that city or county. Why are you limiting this to civic? I would think that it would be just as important for geo as well. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun May 22 16:53:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZxRx-0000aX-Mj; Sun, 22 May 2005 16:53:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZxRv-0000ZR-OX for ecrit@megatron.ietf.org; Sun, 22 May 2005 16:53:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24932 for ; Sun, 22 May 2005 16:53:23 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZxji-0005W0-VH for ecrit@ietf.org; Sun, 22 May 2005 17:11:52 -0400 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j4MKrJSa021029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 22 May 2005 16:53:19 -0400 (EDT) Received: from [127.0.0.1] (razor.cs.columbia.edu [128.59.16.8]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j4MKrHLu014867; Sun, 22 May 2005 16:53:18 -0400 In-Reply-To: <3f66d1f7a8b55c22b93a39203ab8c47f@hxr.us> References: <428F8CCB.5080702@cs.columbia.edu> <3f66d1f7a8b55c22b93a39203ab8c47f@hxr.us> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Proposed requirement: split responsibility Date: Sun, 22 May 2005 16:53:26 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.728) X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_VERSION 0, __MIME_VERSION_APPLEMAIL 0, __MSGID_APPLEMAIL 0, __SANE_MSGID 0, __USER_AGENT_APPLEMAIL 0, __X_MAILER_APPLEMAIL 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > > >> We discussed towards the end at the interim meeting, but I don't >> think we have documented this requirement: >> >> Lx (?): Split responsibility >> >> The mapping protocol MUST allow that within a single level of the >> civic address hierarchy, multiple mapping servers handle subsets >> of the data elements. >> >> Motivation: For example, two directories for the same city or >> county may handle different streets within that city or county. >> >> > > Why are you limiting this to civic? I would think that it would be > just as important for geo as well. > > The "classical" example for this split responsibility was that, say, for one city, streets south of the railroad were part of PSAP1, while streets north were in PSAP2, usually based on PSTN wire center boundaries. This meant that you'd either have to have a directory that contains all streets (easy case) or have to have two directories and somehow direct requests to the right directory. Since geo doesn't have the civic hierarchy of country - state - county - city - street, it is less clear to me what the equivalent problem would be for geo. For this same case, in geo, you'd just have two polygons, one for the area north of the railroad, the other for the one south. You do sometimes have polygons with holes for coverage regions, e.g., where an airport has its own fire department/PSAP, while the surrounding county is served by the county sheriff, FD, etc. (A somewhat related, but different, topic is that of conflicting jurisdictions, the Kashmir and Jerusalem cases. They would indeed have multiple servers be responsible for exactly the same geographic area.) Can you give an example of what you had in mind? > -andy > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 23 11:55:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaFGh-00055H-H4; Mon, 23 May 2005 11:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaFGg-00054B-7G for ecrit@megatron.ietf.org; Mon, 23 May 2005 11:55:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08662 for ; Mon, 23 May 2005 11:55:00 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaFYf-0000uA-PS for ecrit@ietf.org; Mon, 23 May 2005 12:13:39 -0400 Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 23 May 2005 11:54:58 -0400 id 000FFCC3.4291FCD2.00005EC1 In-Reply-To: References: <428F8CCB.5080702@cs.columbia.edu> <3f66d1f7a8b55c22b93a39203ab8c47f@hxr.us> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5ba8d0aa8ac2d30963f9f4cf587ff23f@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Proposed requirement: split responsibility Date: Mon, 23 May 2005 11:54:57 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On May 22, 2005, at 4:53 PM, Henning Schulzrinne wrote: > Can you give an example of what you had in mind? In the example you gave, I would assume that just because "the powers that be" divided the PSAP along street north of the railroad vs south of the railroad still means that some users are gonna use geographical coordinates to give their location vs. a full civil address. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 23 13:09:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGR1-0005p3-ER; Mon, 23 May 2005 13:09:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGQz-0005oy-NS for ecrit@megatron.ietf.org; Mon, 23 May 2005 13:09:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14983 for ; Mon, 23 May 2005 13:09:43 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaGj0-0004AY-R3 for ecrit@ietf.org; Mon, 23 May 2005 13:28:23 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4NH9GCK017560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 May 2005 10:09:17 -0700 (PDT) Received: from [192.168.1.4] (vpn-10-50-16-97.qualcomm.com [10.50.16.97]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4NH9DJ9008743; Mon, 23 May 2005 10:09:14 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <5ba8d0aa8ac2d30963f9f4cf587ff23f@hxr.us> References: <428F8CCB.5080702@cs.columbia.edu> <3f66d1f7a8b55c22b93a39203ab8c47f@hxr.us> <5ba8d0aa8ac2d30963f9f4cf587ff23f@hxr.us> Date: Mon, 23 May 2005 10:09:11 -0700 To: Andrew Newton , Henning Schulzrinne From: Ted Hardie Subject: Re: [Ecrit] Proposed requirement: split responsibility Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 11:54 AM -0400 5/23/05, Andrew Newton wrote: >On May 22, 2005, at 4:53 PM, Henning Schulzrinne wrote: > >>Can you give an example of what you had in mind? > >In the example you gave, I would assume that just because "the >powers that be" divided the PSAP along street north of the railroad >vs south of the railroad still means that some users are gonna use >geographical coordinates to give their location vs. a full civil >address. > >-andy The question goes back to split responsibility of the mapping server, though. If a geoloc-capable mapping server said: I can be responsible for this set of polygons, but I'm going to refer you for the polygons you actually sent me, I think this meets the split responsibility case. Note that this doesn't necessarily map to the psap splits. A mapping server could have knowledge of a specific area, including which psaps served which numbers on the street, but split that responsibility with another server which also served different territory covered by the same psaps. As a thought experiment, imagine someone splitting a city into two geographically equal halves along east-west lines for the purposes of assigning mapping server responsibility. Unless the psap division followed exactly the same lines, each of the two would have territory that used a psap that also served territory under the other mapping server's responsibility. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 23 13:19:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGaa-0006gF-0I; Mon, 23 May 2005 13:19:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGaZ-0006gA-9A for ecrit@megatron.ietf.org; Mon, 23 May 2005 13:19:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15789 for ; Mon, 23 May 2005 13:19:36 -0400 (EDT) Message-Id: <200505231719.NAA15789@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaGsZ-0004Y3-KG for ecrit@ietf.org; Mon, 23 May 2005 13:38:16 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DaGaN-00076u-4P; Mon, 23 May 2005 12:19:27 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Proposed requirement: split responsibility Date: Mon, 23 May 2005 13:19:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVfr+lraxOhWVwUTSa/vlZPGejm/gAA1mgQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <5ba8d0aa8ac2d30963f9f4cf587ff23f@hxr.us> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree that we need BOTH civic and geo routing, and thus we need both civic and geo databases that determine boundaries. Civic is based on country, state/province, county, city, street, and house number. Geo is based on point-in-polygon algorithms. It's possible that we use a nested set of polygons (country, state, county, city, ...), but the number of polygons down to psap is thousands, perhaps a small number of 10,000s. That's small enough that a GIS system can store all of them and do an intersection against them all simultaneously. Most GIS systems are pretty smart about efficiently organizing such data. They can find the right polygon in a dozen milliseconds of compute time. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Andrew Newton > Sent: Monday, May 23, 2005 11:55 AM > To: Henning Schulzrinne > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Proposed requirement: split responsibility > > > On May 22, 2005, at 4:53 PM, Henning Schulzrinne wrote: > > > Can you give an example of what you had in mind? > > In the example you gave, I would assume that just because "the powers > that be" divided the PSAP along street north of the railroad vs south > of the railroad still means that some users are gonna use geographical > coordinates to give their location vs. a full civil address. > > -andy > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 23 13:28:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGjM-0007wb-OY; Mon, 23 May 2005 13:28:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGjM-0007wJ-7l for ecrit@megatron.ietf.org; Mon, 23 May 2005 13:28:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16629 for ; Mon, 23 May 2005 13:28:41 -0400 (EDT) Message-Id: <200505231728.NAA16629@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaH1N-00050m-JL for ecrit@ietf.org; Mon, 23 May 2005 13:47:21 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DaGjB-0007fY-9B; Mon, 23 May 2005 12:28:33 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Andrew Newton'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Proposed requirement: split responsibility Date: Mon, 23 May 2005 13:28:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVfuoA9ANk5zThcTuGtzoraJ6BWAwAASomA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org See my reply to Andrew on polygons; we probably don't need this complexity. Your example however is illustrative of how the NENA i2 mechanism works on civic boundaries. It assigns state/county/city areas to a specific part of the database. There is a "root server", which, when queried, returns a list of servers that have data for a specified city/county/state. Where the boundary doesn't exactly match the city/county/state boundary, you get more than one server in the response. Each of the servers can forward the request to the actual server, if it knows. I don't like this mechanism as much as the DNS proposal I have made, which always gets the query to the authoritative server with one request by the client, but it works. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Ted Hardie > Sent: Monday, May 23, 2005 1:09 PM > To: Andrew Newton; Henning Schulzrinne > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Proposed requirement: split responsibility > > At 11:54 AM -0400 5/23/05, Andrew Newton wrote: > >On May 22, 2005, at 4:53 PM, Henning Schulzrinne wrote: > > > >>Can you give an example of what you had in mind? > > > >In the example you gave, I would assume that just because "the > >powers that be" divided the PSAP along street north of the railroad > >vs south of the railroad still means that some users are gonna use > >geographical coordinates to give their location vs. a full civil > >address. > > > >-andy > > The question goes back to split responsibility of the mapping server, > though. > If a geoloc-capable mapping server said: I can be responsible for this > set of > polygons, but I'm going to refer you for the polygons you actually sent > me, > I think this meets the split responsibility case. > > Note that this doesn't necessarily map to the psap splits. A mapping > server could > have knowledge of a specific area, including which psaps served which > numbers > on the street, but split that responsibility with another server which > also > served different territory covered by the same psaps. As a thought > experiment, > imagine someone splitting a city into two geographically equal halves > along > east-west lines for the purposes of assigning mapping server > responsibility. > Unless the psap division followed exactly the same lines, each of the two > would have territory that used a psap that also served territory under the > other mapping server's responsibility. > Ted > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 23 13:52:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaH6P-0002Wu-Ho; Mon, 23 May 2005 13:52:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaH6P-0002Wp-3C for ecrit@megatron.ietf.org; Mon, 23 May 2005 13:52:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18864 for ; Mon, 23 May 2005 13:52:32 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaHOP-0005uU-Ll for ecrit@ietf.org; Mon, 23 May 2005 14:11:10 -0400 Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 23 May 2005 13:52:26 -0400 id 000FB9D4.4292185A.00007B8F In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <67af622eb20ea59a9d226f8a66cbb204@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Proposed requirement: split responsibility Date: Mon, 23 May 2005 13:52:24 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On May 23, 2005, at 1:28 PM, Brian Rosen wrote: > Your example however is illustrative of how the NENA i2 mechanism > works on > civic boundaries. It assigns state/county/city areas to a specific > part of > the database. There is a "root server", which, when queried, returns > a list > of servers that have data for a specified city/county/state. Where the > boundary doesn't exactly match the city/county/state boundary, you get > more > than one server in the response. Each of the servers can forward the > request to the actual server, if it knows. > > I don't like this mechanism as much as the DNS proposal I have made, > which > always gets the query to the authoritative server with one request by > the > client, but it works. Isn't this making an assumption that all such splits occur on the civil address boundaries? While I believe there are situations where such divisions are made based on artificial criteria such as streets marked "North" vs streets marked "South", it seems more reasonable that such things are based on major geographic features (a river that bisects a city), some artifact of location based on telco COs, the need of the population centers (more crime-ridden sections of a city probably require a greater number of resources), etc... -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 23 14:09:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHMe-0004Fe-AD; Mon, 23 May 2005 14:09:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHMc-0004FS-LV for ecrit@megatron.ietf.org; Mon, 23 May 2005 14:09:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20703 for ; Mon, 23 May 2005 14:09:17 -0400 (EDT) Message-Id: <200505231809.OAA20703@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaHee-0006bx-8Y for ecrit@ietf.org; Mon, 23 May 2005 14:27:56 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DaHMR-0000uv-L4; Mon, 23 May 2005 13:09:08 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] Proposed requirement: split responsibility Date: Mon, 23 May 2005 14:08:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVfwC3/7OJtjLEUTsextS4Aneqz4AAALMRg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <67af622eb20ea59a9d226f8a66cbb204@hxr.us> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'd hate to generalize beyond North America. Here, the boundary is defined in both civic and geo forms, regardless of what the boundary is chosen to be. The base form up to cell phone days was civic. They added polygons for mobile phone routing. Today, we have both; a precise civic and a precise geo. "Precise" is in the eyes of the beholder of course. It's not exactly easy, but given any street address, we can tell you which PSAP gets the call. It's a little more complex for geo, because, in North America, routing for cell phones is different in some areas than routing for wireline. There exists a complete set of polygons for mobile routing, and I am told that one firm has a complete, or nearly complete set of polygons for wireline geo routing. I suspect that in other countries that have more than one PSAP that gets the call, there are precise civic routing mechanisms, albeit they may be pretty historically derived, rather than having any boundary you might choose today. Nevertheless, in the cases I know, again allowing for some pretty arcane ways to get at the data, the actual boundaries are defined by civic addresses. There may be polygons available, but I know that there are differences in wireless and wireline routing in other countries too. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Monday, May 23, 2005 1:52 PM > To: Brian Rosen > Cc: ecrit@ietf.org; 'Ted Hardie'; 'Henning Schulzrinne' > Subject: Re: [Ecrit] Proposed requirement: split responsibility > > > On May 23, 2005, at 1:28 PM, Brian Rosen wrote: > > > Your example however is illustrative of how the NENA i2 mechanism > > works on > > civic boundaries. It assigns state/county/city areas to a specific > > part of > > the database. There is a "root server", which, when queried, returns > > a list > > of servers that have data for a specified city/county/state. Where the > > boundary doesn't exactly match the city/county/state boundary, you get > > more > > than one server in the response. Each of the servers can forward the > > request to the actual server, if it knows. > > > > I don't like this mechanism as much as the DNS proposal I have made, > > which > > always gets the query to the authoritative server with one request by > > the > > client, but it works. > > Isn't this making an assumption that all such splits occur on the civil > address boundaries? While I believe there are situations where such > divisions are made based on artificial criteria such as streets marked > "North" vs streets marked "South", it seems more reasonable that such > things are based on major geographic features (a river that bisects a > city), some artifact of location based on telco COs, the need of the > population centers (more crime-ridden sections of a city probably > require a greater number of resources), etc... > > -andy > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 23 14:40:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHqg-0000HI-3p; Mon, 23 May 2005 14:40:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHqe-0000HD-DF for ecrit@megatron.ietf.org; Mon, 23 May 2005 14:40:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26127 for ; Mon, 23 May 2005 14:40:19 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaI8f-0007zv-Ds for ecrit@ietf.org; Mon, 23 May 2005 14:58:58 -0400 Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 23 May 2005 14:40:17 -0400 id 000FB9D4.42922391.0000088D In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <297d0b2051bc20224fcbb2de4f4a933c@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Proposed requirement: split responsibility Date: Mon, 23 May 2005 14:40:15 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On May 23, 2005, at 2:08 PM, Brian Rosen wrote: > It's not exactly easy, but given any street address, we can tell you > which > PSAP gets the call. This says nothing about the split being based on civil address boundaries and does not mean that it is. Other than country code, this sounds like a fairly big assumption. And it has been pointed out that there are even parts of the world where the country code does not determine the split. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 23 15:10:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIJp-0005mt-Al; Mon, 23 May 2005 15:10:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIJn-0005mo-QL for ecrit@megatron.ietf.org; Mon, 23 May 2005 15:10:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29584 for ; Mon, 23 May 2005 15:10:26 -0400 (EDT) Message-Id: <200505231910.PAA29584@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaIbp-0000kg-0G for ecrit@ietf.org; Mon, 23 May 2005 15:29:06 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DaIJb-0002Zc-Rq; Mon, 23 May 2005 14:10:16 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] Proposed requirement: split responsibility Date: Mon, 23 May 2005 15:10:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVfxt3XJ3uxdn2STQiDneGewUN8zwAAJLUQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <297d0b2051bc20224fcbb2de4f4a933c@hxr.us> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andrew We seem to be talking past one another. If you mean "in the big picture, ignoring 100 years of telephony, how is a PSAP boundary actually defined?", then, clearly, many boundaries are defined by natural features such as rivers, and most are defined by political boundaries, which in turn may have boundaries based on natural features. If you mean "how is routing defined for emergency calls today", then most of the time, for the cases where there is more than one PSAP per country, it's defined in terms of wireline telephony footprints, with historical analomies tossed in. Many boundaries are (or maybe more accurately, were) really central office boundaries. These were all defined by street addresses; they didn't use polygons back then, and while they may have started with a map, they translated to where, on what street/number), the boundary lies. We have to build databases to make ecrit work. Unless we are going to believe we can translate civic to geo or vice versa with sufficient accuracy, we have to have BOTH civic and geo databases. Such databases exist in North America. I know that there is an effective equivalent in some other countries, but I don't know enough to even speculate about some areas. While in North America, we require a validation step, which implies that we need a complete database down to house number, we clearly can't get that immediately everywhere. Our solution has to deploy incrementally. If all calls within a country go one place, we want to have one entry in the geo and civic routing database for that country. If there are a couple of large regions, they are often defined on state/province boundaries, and we can put entries for every state/province in the civic, and a couple of polygons in the geo databases, to get started. If you have a case where most of the countryside goes one place, but one or more large cities have their own PSAPs, we put the high level entry in, and also have the lower level entry, and we need the mapping function to look for the most specific (longest prefix) match. In North America, boundaries may be very convoluted (all of a city, plus a couple of streets, minus some street numbers on one of those streets). But the bottom line is that routing data today is most often civic address based. Geo based routing is available in most places, applied mostly to mobiles, and may have different routing than wireline. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Monday, May 23, 2005 2:40 PM > To: Brian Rosen > Cc: ecrit@ietf.org; 'Ted Hardie'; 'Henning Schulzrinne' > Subject: Re: [Ecrit] Proposed requirement: split responsibility > > > On May 23, 2005, at 2:08 PM, Brian Rosen wrote: > > It's not exactly easy, but given any street address, we can tell you > > which > > PSAP gets the call. > > This says nothing about the split being based on civil address > boundaries and does not mean that it is. Other than country code, this > sounds like a fairly big assumption. And it has been pointed out that > there are even parts of the world where the country code does not > determine the split. > > -andy > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 23 18:03:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaL19-0002zu-4R; Mon, 23 May 2005 18:03:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaL17-0002zK-OW for ecrit@megatron.ietf.org; Mon, 23 May 2005 18:03:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02076 for ; Mon, 23 May 2005 18:03:18 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaLJ9-0005AG-8n for ecrit@ietf.org; Mon, 23 May 2005 18:22:00 -0400 Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 23 May 2005 18:03:17 -0400 id 000FB9F6.42925325.00004349 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <13fb4ff3e210f4df86df1d4c5fba424a@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Proposed requirement: split responsibility Date: Mon, 23 May 2005 18:03:15 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On May 23, 2005, at 3:10 PM, Brian Rosen wrote: > We seem to be talking past one another. I guess we can agree on this. :) > But the bottom line is that routing data today is most often civic > address > based. Geo based routing is available in most places, applied mostly > to > mobiles, and may have different routing than wireline. I'm not arguing against this. What I'm arguing against is an assumption being applied to our requirements that somehow mapping services are always going to fall cleanly across the civil address field boundaries (all those nice little elements in PIDF-LO that begin with "A"). As it so happens, my brother actually runs a PSAP and I get to bounce a lot of these ideas off of him. His big comment regarding this notion was that politicians usually don't take into consideration which PSAP answers the phone when they rename a street. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 23 22:51:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaPW8-0001zs-Nt; Mon, 23 May 2005 22:51:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaPW6-0001zn-RA for ecrit@megatron.ietf.org; Mon, 23 May 2005 22:51:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25612 for ; Mon, 23 May 2005 22:51:36 -0400 (EDT) Message-Id: <200505240251.WAA25612@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaPoB-0007OB-6N for ecrit@ietf.org; Mon, 23 May 2005 23:10:20 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DaPVq-0004Vd-Fu; Mon, 23 May 2005 21:51:22 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] Proposed requirement: split responsibility Date: Mon, 23 May 2005 22:51:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVf4zpI2E7cz3J8QyGpYmmqLBEC5gAJoa5w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <13fb4ff3e210f4df86df1d4c5fba424a@hxr.us> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The following applies to North America: Look at it this way: While a political boundary can in fact cut across a building (I know of a warehouse that has the front door in one county, and the back door in another), for responder purposes, the address of the building determines which PSAP responds to it. Mapping, at least today, always falls cleanly on a civil address field. In fact, while you CAN get a polygon that is as accurate as the civil address, in fact, in the cases I know about, the available polygons are not as accurate as the civil address boundary. Politicians cause all kinds of silly address analomies all the time. The way they are dealt with now is that the PSAP issues a change to the MSAG, which is the civil address database. At the present time, there is no organized way to get that change into the polygons, but presumably we'll be asking them to do that. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Monday, May 23, 2005 6:03 PM > To: Brian Rosen > Cc: ecrit@ietf.org; 'Ted Hardie'; 'Henning Schulzrinne' > Subject: Re: [Ecrit] Proposed requirement: split responsibility > > > On May 23, 2005, at 3:10 PM, Brian Rosen wrote: > > We seem to be talking past one another. > > I guess we can agree on this. :) > > > But the bottom line is that routing data today is most often civic > > address > > based. Geo based routing is available in most places, applied mostly > > to > > mobiles, and may have different routing than wireline. > > I'm not arguing against this. > > What I'm arguing against is an assumption being applied to our > requirements that somehow mapping services are always going to fall > cleanly across the civil address field boundaries (all those nice > little elements in PIDF-LO that begin with "A"). > > As it so happens, my brother actually runs a PSAP and I get to bounce a > lot of these ideas off of him. His big comment regarding this notion > was that politicians usually don't take into consideration which PSAP > answers the phone when they rename a street. > > -andy > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 24 07:52:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaXxx-0006id-2J; Tue, 24 May 2005 07:52:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaXxv-0006iY-6x for ecrit@megatron.ietf.org; Tue, 24 May 2005 07:52:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20435 for ; Tue, 24 May 2005 07:52:54 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaYG3-0008Gn-Az for ecrit@ietf.org; Tue, 24 May 2005 08:11:42 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 24 May 2005 07:52:50 -0400 id 000FB87A.42931592.00005CEE In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Proposed requirement: split responsibility Date: Tue, 24 May 2005 07:52:46 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On May 23, 2005, at 10:51 PM, Brian Rosen wrote: > Mapping, at least today, always falls cleanly on a civil address field. The mapping may break down cleanly, but the hierarchy of responsibility does not. To say that all roads that end with "North" will go to one PSAP and all roads that end with "South" go to another PSAP and that there will be no exceptions seems to be a very broad assumption. I live on a road with a "South" suffix. My neighbors 2 blocks down have an address that looks just like mine with the exception of the street number. But the county/city line is between us, and their 911 calls go to one place and mine go to another. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 24 08:45:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaYmo-0007Cb-Rr; Tue, 24 May 2005 08:45:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaYmn-0007CW-72 for ecrit@megatron.ietf.org; Tue, 24 May 2005 08:45:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26195 for ; Tue, 24 May 2005 08:45:27 -0400 (EDT) From: wilcox@e911.psd.state.vt.us Received: from static-64-222-94-65.burl.east.verizon.net ([64.222.94.65] helo=artemis.vt911.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaZ4y-0001rM-Lv for ecrit@ietf.org; Tue, 24 May 2005 09:04:17 -0400 content-class: urn:content-classes:message Subject: RE: [Ecrit] Proposed requirement: split responsibility MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 24 May 2005 08:48:32 -0400 Message-ID: Thread-Topic: [Ecrit] Proposed requirement: split responsibility Thread-Index: AcVf4zpI2E7cz3J8QyGpYmmqLBEC5gAJoa5wABUHccA= To: "Brian Rosen" , "Andrew Newton" X-Spam-Score: 0.3 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andrew et al; This is background information only: In my 15+ years in 9-1-1 I have never seen a community change its borders (or rename streets) without seriously considering the impact on 9-1-1 and correctly addressing it. The primary concern is dispatch response in most cases. Dispatch response scenarios can get rather fuzzy in some border areas and new roads can create dispatch confusion. It has never been a problem for PSAP call answering and I challenge you to provide specific proof of where this is occurring. So, it is not a matter of "which PSAP answers the phone" it is a matter of correctly identifying emergency responders (police, fire and EMS). To state that elected officials make road name changes without first considering emergency response scenarios (and call handling responsibilities) is a gross misrepresentation of the actual process. Also, ENHANCED 9-1-1 PSAP boundaries do not primarily align with telco rate centers (as was suggested in an earlier e-mail). The notion of E9-1-1 is to break the connection between telco rate center and political boundary. They mostly align with town and/or community boundaries. If a town plans to move a boundary or change a response scenario to a particular area, both police and fire officials are included in the planning process (same with road name changes). This naturally extends to the 9-1-1 call routing process as well and is carefully orchestrated with the 9-1-1 system service provider who, manages the changes in the MSAG.=20 On average in Vermont we move or change the PSAP footprints (mostly based on dispatch re-alignment) about once or twice a year and only for a few small communities. The bulk of the coverage area for a PSAP generally does not change. The challenge is going to be conveying those changes in coverage areas to any system now also responsible for determining location and routing 9-1-1 calls. Nate Wilcox Systems Administrator Vermont 9-1-1 802.828.4093 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Monday, May 23, 2005 10:51 PM To: 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] Proposed requirement: split responsibility The following applies to North America: Look at it this way: While a political boundary can in fact cut across a building (I know of a warehouse that has the front door in one county, and the back door in another), for responder purposes, the address of the building determines which PSAP responds to it. =20 Mapping, at least today, always falls cleanly on a civil address field. In fact, while you CAN get a polygon that is as accurate as the civil address, in fact, in the cases I know about, the available polygons are not as accurate as the civil address boundary. Politicians cause all kinds of silly address analomies all the time. The way they are dealt with now is that the PSAP issues a change to the MSAG, which is the civil address database. At the present time, there is no organized way to get that change into the polygons, but presumably we'll be asking them to do that. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Monday, May 23, 2005 6:03 PM > To: Brian Rosen > Cc: ecrit@ietf.org; 'Ted Hardie'; 'Henning Schulzrinne' > Subject: Re: [Ecrit] Proposed requirement: split responsibility >=20 >=20 > On May 23, 2005, at 3:10 PM, Brian Rosen wrote: > > We seem to be talking past one another. >=20 > I guess we can agree on this. :) >=20 > > But the bottom line is that routing data today is most often civic > > address > > based. Geo based routing is available in most places, applied mostly > > to > > mobiles, and may have different routing than wireline. >=20 > I'm not arguing against this. >=20 > What I'm arguing against is an assumption being applied to our > requirements that somehow mapping services are always going to fall > cleanly across the civil address field boundaries (all those nice > little elements in PIDF-LO that begin with "A"). >=20 > As it so happens, my brother actually runs a PSAP and I get to bounce a > lot of these ideas off of him. His big comment regarding this notion > was that politicians usually don't take into consideration which PSAP > answers the phone when they rename a street. >=20 > -andy >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 24 08:52:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaYt3-0008Ej-O6; Tue, 24 May 2005 08:51:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaYsw-0008BC-If for ecrit@megatron.ietf.org; Tue, 24 May 2005 08:51:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26455 for ; Tue, 24 May 2005 08:51:49 -0400 (EDT) Message-Id: <200505241251.IAA26455@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaZB7-0001zt-62 for ecrit@ietf.org; Tue, 24 May 2005 09:10:38 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DaYsh-0004CG-7h; Tue, 24 May 2005 07:51:35 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] Proposed requirement: split responsibility Date: Tue, 24 May 2005 08:51:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVgVx+wMBky1OWtTsG1XpS8pTVnigABjpsQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm not sure why you think that anyone proposes routing works the way you are describing. Perhaps you have some confusion on the part of the address called "street". There are a couple of components to "street": The pre-directional, the street name, suffix and post directional. Change any component, and you (potentially) have a different street. Routing can be different for a different combination, but you take the combination as one component, not the constituent parts. So, South Main Street may route differently than South Main Avenue, but we don't have anything that says all Streets route differently that all Avenues, and we don't have anything that says all "South" predirectionals route differently than all "North" predirectionals. In my DNS proposal, the rewriting rule creates a single component from the combination. So "123.S~Main#ST$NW.washington.~.dc.us.sos.arpa". Note that DC doesn't use counties, and there is no period in "S~Main#ST$NW". Using IRIS, you wouldn't need a rewriting rule, but the routing could be different for S Main ST and S Main AV when encoded in XML. Of course it could also be different for 100 S Main ST and 101 S Main ST. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, May 24, 2005 7:53 AM > To: Brian Rosen > Cc: ecrit@ietf.org; 'Ted Hardie'; 'Henning Schulzrinne' > Subject: Re: [Ecrit] Proposed requirement: split responsibility > > > On May 23, 2005, at 10:51 PM, Brian Rosen wrote: > > > Mapping, at least today, always falls cleanly on a civil address field. > > The mapping may break down cleanly, but the hierarchy of responsibility > does not. To say that all roads that end with "North" will go to one > PSAP and all roads that end with "South" go to another PSAP and that > there will be no exceptions seems to be a very broad assumption. I > live on a road with a "South" suffix. My neighbors 2 blocks down have > an address that looks just like mine with the exception of the street > number. But the county/city line is between us, and their 911 calls go > to one place and mine go to another. > > -andy > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 24 09:24:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaZOq-0005Zo-Nt; Tue, 24 May 2005 09:24:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaZOp-0005YG-CK for ecrit@megatron.ietf.org; Tue, 24 May 2005 09:24:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29109 for ; Tue, 24 May 2005 09:24:45 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaZgy-0003Es-6T for ecrit@ietf.org; Tue, 24 May 2005 09:43:35 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 24 May 2005 09:24:38 -0400 id 000FB884.42932B1A.00006F79 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Proposed requirement: split responsibility Date: Tue, 24 May 2005 09:24:35 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On May 24, 2005, at 8:51 AM, Brian Rosen wrote: > So, South Main Street may route differently than South Main Avenue, > but we > don't have anything that says all Streets route differently that all > Avenues, and we don't have anything that says all "South" > predirectionals > route differently than all "North" predirectionals. I think, you are saying there is no hierarchy... at least at the street level. I am arguing that there should not be a hierarchy. Let me refine that, no hierarchy should be imposed. Certainly there are many jurisdictions that have a hierarchy related to civic address fields, but I do not think they are the same hierarchy the world around. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 24 09:36:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaZaZ-0007iW-Mb; Tue, 24 May 2005 09:36:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaZaY-0007iQ-MO for ecrit@megatron.ietf.org; Tue, 24 May 2005 09:36:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00277 for ; Tue, 24 May 2005 09:36:53 -0400 (EDT) Message-Id: <200505241336.JAA00277@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaZsk-0003ZK-OI for ecrit@ietf.org; Tue, 24 May 2005 09:55:42 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DaZaK-0005j9-3A; Tue, 24 May 2005 08:36:40 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] Proposed requirement: split responsibility Date: Tue, 24 May 2005 09:36:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVgY/Id1NT0kynVQhCOCSFvDRZt8AAAPRiA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yes, I thing we are agreeing that at the street level, which includes street name, pre and post directionals, and suffix, there is no hierarchy. Similarly, there is no hierarchy for House Number and the House Number Suffix, the Landmark Name, etc. The only point in a hierarchy above that is to create some feasible mechanism to distribute the database. There are reasons to want to do that, and hierarchy makes sense at the city/county/state/country level. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, May 24, 2005 9:25 AM > To: Brian Rosen > Cc: ecrit@ietf.org; 'Ted Hardie'; 'Henning Schulzrinne' > Subject: Re: [Ecrit] Proposed requirement: split responsibility > > > On May 24, 2005, at 8:51 AM, Brian Rosen wrote: > > > So, South Main Street may route differently than South Main Avenue, > > but we > > don't have anything that says all Streets route differently that all > > Avenues, and we don't have anything that says all "South" > > predirectionals > > route differently than all "North" predirectionals. > > I think, you are saying there is no hierarchy... at least at the street > level. I am arguing that there should not be a hierarchy. Let me > refine that, no hierarchy should be imposed. Certainly there are many > jurisdictions that have a hierarchy related to civic address fields, > but I do not think they are the same hierarchy the world around. > > -andy > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 24 10:00:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaZww-0002iL-Ol; Tue, 24 May 2005 10:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaZwu-0002dq-M9 for ecrit@megatron.ietf.org; Tue, 24 May 2005 10:00:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01593 for ; Tue, 24 May 2005 09:59:50 -0400 (EDT) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaaEy-0004JT-Lf for ecrit@ietf.org; Tue, 24 May 2005 10:18:40 -0400 Received: from rrc-its-ieg01.cc.telcordia.com (rrc-its-ieg01.cc.telcordia.com [128.96.109.78]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id j4ODxgX17094; Tue, 24 May 2005 09:59:42 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-its-ieg01.cc.telcordia.com (SMSSMTP 4.0.5.66) with SMTP id M2005052409593918166 ; Tue, 24 May 2005 09:59:39 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 May 2005 09:59:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Proposed requirement: split responsibility Date: Tue, 24 May 2005 09:59:18 -0400 Message-ID: Thread-Topic: [Ecrit] Proposed requirement: split responsibility Thread-Index: AcVgY/Id1NT0kynVQhCOCSFvDRZt8AAAPRiAAADA7NA= From: "Abbott, Nadine B" To: "Brian Rosen" , "Andrew Newton" X-OriginalArrivalTime: 24 May 2005 13:59:42.0813 (UTC) FILETIME=[D5B3E8D0:01C56068] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, Actually, there are some metro areas even in the USA where the hierarchy you suggested breaks down (i.e., multiple counties in NYC), but I think it could still be modeled with multiple instances of NYC, one for each county. (As an aside, I think that a hierarchy may be one way to implement the mapping data base, but building a hierarchy in the query protocol is, I think, a bad idea. What if you guess wrong? Hard to fix, later.) Nadine -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, May 24, 2005 9:36 AM To: 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] Proposed requirement: split responsibility Yes, I thing we are agreeing that at the street level, which includes street name, pre and post directionals, and suffix, there is no hierarchy. Similarly, there is no hierarchy for House Number and the House Number Suffix, the Landmark Name, etc. The only point in a hierarchy above that is to create some feasible mechanism to distribute the database. There are reasons to want to do that, and hierarchy makes sense at the city/county/state/country level. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, May 24, 2005 9:25 AM > To: Brian Rosen > Cc: ecrit@ietf.org; 'Ted Hardie'; 'Henning Schulzrinne' > Subject: Re: [Ecrit] Proposed requirement: split responsibility >=20 >=20 > On May 24, 2005, at 8:51 AM, Brian Rosen wrote: >=20 > > So, South Main Street may route differently than South Main Avenue,=20 > > but we don't have anything that says all Streets route differently=20 > > that all Avenues, and we don't have anything that says all "South" > > predirectionals > > route differently than all "North" predirectionals. >=20 > I think, you are saying there is no hierarchy... at least at the=20 > street level. I am arguing that there should not be a hierarchy. Let > me refine that, no hierarchy should be imposed. Certainly there are=20 > many jurisdictions that have a hierarchy related to civic address=20 > fields, but I do not think they are the same hierarchy the world=20 > around. >=20 > -andy >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 24 10:36:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaaWZ-0008C6-7c; Tue, 24 May 2005 10:36:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaaWX-0008C1-JR for ecrit@megatron.ietf.org; Tue, 24 May 2005 10:36:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05484 for ; Tue, 24 May 2005 10:36:47 -0400 (EDT) Message-Id: <200505241436.KAA05484@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Daaoi-0005Nq-Jl for ecrit@ietf.org; Tue, 24 May 2005 10:55:38 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DaaWL-0007Yv-5c; Tue, 24 May 2005 09:36:38 -0500 From: "Brian Rosen" To: "'Abbott, Nadine B'" , "'Andrew Newton'" Subject: RE: [Ecrit] Proposed requirement: split responsibility Date: Tue, 24 May 2005 10:36:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVgY/Id1NT0kynVQhCOCSFvDRZt8AAAPRiAAADA7NAAAFesoA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Nadine Generally, I agree with you that hierarchy at the city level occasionally has problems, and I also agree there are straightforward work arounds for those problems. It's often the case that a PSAP serves more than one point in any hierarchy. An easy example is that often, a County PSAP serves all of a county except a large city. You can accomplish that by having entries for all of the cities, or you can "delegate" the county to one entity, and have it "delegate" the city to another. Your New York City example is similar. You need some rational way to split up the database. Doing it on City/County/State/Country boundaries is a good start, but insufficient, as you know. Your choices, when say, a part of a street are in a different PSAP from all the other streets in a city, are: 1. Allow the database to be split on arbitrary boundaries and have some mechanism such as referral, or delegation to route a query to the right server 2. Split the database on a city/county/state/country boundary and force the data to match this split 3. Duplicate coverage on city/county/state/country boundaries i.e. have more than one potential server, and search them in parallel or series. The thing about addresses is that they are very old, and we don't often change the way we address. We did add postal codes a while ago, but it's not like anything on the Internet. There is some danger that we don't adequately investigate existing practice, in some area of the world and subsequently discover some issues. Brian > -----Original Message----- > From: Abbott, Nadine B [mailto:nabbott@telcordia.com] > Sent: Tuesday, May 24, 2005 9:59 AM > To: Brian Rosen; Andrew Newton > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Proposed requirement: split responsibility > > Brian, > > Actually, there are some metro areas even in the USA where the hierarchy > you suggested breaks down (i.e., multiple counties in NYC), but I think > it could still be modeled with multiple instances of NYC, one for each > county. > > (As an aside, I think that a hierarchy may be one way to implement the > mapping data base, but building a hierarchy in the query protocol is, I > think, a bad idea. What if you guess wrong? Hard to fix, later.) > > Nadine > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Tuesday, May 24, 2005 9:36 AM > To: 'Andrew Newton' > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Proposed requirement: split responsibility > > > Yes, I thing we are agreeing that at the street level, which includes > street name, pre and post directionals, and suffix, there is no > hierarchy. > > Similarly, there is no hierarchy for House Number and the House Number > Suffix, the Landmark Name, etc. > > The only point in a hierarchy above that is to create some feasible > mechanism to distribute the database. There are reasons to want to do > that, and hierarchy makes sense at the city/county/state/country level. > > Brian > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Tuesday, May 24, 2005 9:25 AM > > To: Brian Rosen > > Cc: ecrit@ietf.org; 'Ted Hardie'; 'Henning Schulzrinne' > > Subject: Re: [Ecrit] Proposed requirement: split responsibility > > > > > > On May 24, 2005, at 8:51 AM, Brian Rosen wrote: > > > > > So, South Main Street may route differently than South Main Avenue, > > > but we don't have anything that says all Streets route differently > > > that all Avenues, and we don't have anything that says all "South" > > > predirectionals > > > route differently than all "North" predirectionals. > > > > I think, you are saying there is no hierarchy... at least at the > > street level. I am arguing that there should not be a hierarchy. Let > > > me refine that, no hierarchy should be imposed. Certainly there are > > many jurisdictions that have a hierarchy related to civic address > > fields, but I do not think they are the same hierarchy the world > > around. > > > > -andy > > > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 24 10:48:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaahW-0001ZI-6U; Tue, 24 May 2005 10:48:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaahV-0001Y6-Fv for ecrit@megatron.ietf.org; Tue, 24 May 2005 10:48:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06388 for ; Tue, 24 May 2005 10:48:07 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Daazg-0005tn-V7 for ecrit@ietf.org; Tue, 24 May 2005 11:06:58 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 24 May 2005 10:48:05 -0400 id 000FB9F3.42933EA5.00000371 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <49cd8c49a32661a63a114f3b9fa63d86@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Proposed requirement: split responsibility Date: Tue, 24 May 2005 10:48:02 -0400 To: wilcox@e911.psd.state.vt.us, Brian Rosen X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On May 24, 2005, at 9:36 AM, Brian Rosen wrote: > Yes, I thing we are agreeing that at the street level, which includes > street > name, pre and post directionals, and suffix, there is no hierarchy. > > Similarly, there is no hierarchy for House Number and the House Number > Suffix, the Landmark Name, etc. We have progress! :) > The only point in a hierarchy above that is to create some feasible > mechanism to distribute the database. There are reasons to want to do > that, > and hierarchy makes sense at the city/county/state/country level. As far as state and country, I agree. We have ISO 3166 to hang our hat on for this. I'm not sure city and county are concepts that easily adapt to the rest of the world. And I believe PIDF-LO has further categories such as city division (A4) and neighborhood (A5). While other standards bodies have struggled with defining categories for civc addresses and failed, we have simply defined what we know and moved on. And that seems fine as long as we can come back and modify it later when we find out we've goofed (such as our ability to later define PIDF_LO v2 and add a theoretical A4_5 element). However, the imposition of a hierarchy would seem to prolong any mistakes. I am also not sure this is relevant. As you have suggested, the same mechanism providing location information could also provide country information. I have suggested taking that one step further; the same mechanism providing location information could also provide a pointer (URI) to the mapping service (or perhaps a URI directly to the PSAP in simple cases, though I suspect that isn't as easy as it sounds). Since a URI can point anywhere, there is no need for hierarchy. On May 24, 2005, at 8:48 AM, wilcox@e911.psd.state.vt.us wrote: > In my 15+ years in 9-1-1 I have never seen a community change its > borders (or rename streets) without seriously considering the impact on > 9-1-1 and correctly addressing it. The primary concern is dispatch > response in most cases. Dispatch response scenarios can get rather > fuzzy > in some border areas and new roads can create dispatch confusion. It > has > never been a problem for PSAP call answering and I challenge you to > provide specific proof of where this is occurring. So, it is not a > matter of "which PSAP answers the phone" it is a matter of correctly > identifying emergency responders (police, fire and EMS). To state that > elected officials make road name changes without first considering > emergency response scenarios (and call handling responsibilities) is a > gross misrepresentation of the actual process. I did not mean to suggest that politics are always oblivious to the needs of 911 service. In the case I mentioned, it was conveyed to me that street name changes are communicated to the PSAP so that proper changes to the database may take place. But it was not conveyed as an approval process (I will seek clarification). I'm sure processes are different from country to country and, in the US, from state to state. > Also, ENHANCED 9-1-1 PSAP boundaries do not primarily align with telco > rate centers (as was suggested in an earlier e-mail). The notion of > E9-1-1 is to break the connection between telco rate center and > political boundary. They mostly align with town and/or community > boundaries. If a town plans to move a boundary or change a response > scenario to a particular area, both police and fire officials are > included in the planning process (same with road name changes). This > naturally extends to the 9-1-1 call routing process as well and is > carefully orchestrated with the 9-1-1 system service provider who, > manages the changes in the MSAG. I think both Brian and I were simply suggesting that historical boundaries are due to telco network layout, and not that present day boundaries are given these restrictions (or that they SHOULD). You have said that PSAP boundaries are "mostly" aligned with town or community boundaries. The imposition of a hierarchy means that "ALL" must be aligned on some boundary. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 24 11:43:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DabZ0-00066n-OE; Tue, 24 May 2005 11:43:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DabYy-00066K-CB for ecrit@megatron.ietf.org; Tue, 24 May 2005 11:43:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12554 for ; Tue, 24 May 2005 11:43:21 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DabrA-0008QX-Fm for ecrit@ietf.org; Tue, 24 May 2005 12:02:12 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j4OFh1v25339; Tue, 24 May 2005 11:43:01 -0400 (EDT) Received: from [127.0.0.1] (acart570.ca.nortel.com [47.130.17.227]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29WLZFBS; Tue, 24 May 2005 11:43:00 -0400 Message-ID: <42934B82.9080902@nortel.com> Date: Tue, 24 May 2005 11:42:58 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Proposed requirement: split responsibility References: <49cd8c49a32661a63a114f3b9fa63d86@hxr.us> In-Reply-To: <49cd8c49a32661a63a114f3b9fa63d86@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org How a given country sets up its database is up to that country. It could be centralized, distributed according to a hierarchy, or distributed but redundant. The key requirement is that PIDF-LO and the query protocol be able to capture the elements of information any specific database system needs to function properly. And of course, the database design will to a large extent be determined by what we provide in the way of query language. I have a question about WG scope. Is discovery of the appropriate mapping server a problem we are supposed to tackle? Andrew Newton wrote: > > On May 24, 2005, at 9:36 AM, Brian Rosen wrote: > >> Yes, I thing we are agreeing that at the street level, which includes >> street >> name, pre and post directionals, and suffix, there is no hierarchy. >> >> Similarly, there is no hierarchy for House Number and the House Number >> Suffix, the Landmark Name, etc. > > > We have progress! :) > >> The only point in a hierarchy above that is to create some feasible >> mechanism to distribute the database. There are reasons to want to >> do that, >> and hierarchy makes sense at the city/county/state/country level. > > > As far as state and country, I agree. We have ISO 3166 to hang our > hat on for this. I'm not sure city and county are concepts that > easily adapt to the rest of the world. And I believe PIDF-LO has > further categories such as city division (A4) and neighborhood (A5). > While other standards bodies have struggled with defining categories > for civc addresses and failed, we have simply defined what we know and > moved on. And that seems fine as long as we can come back and modify > it later when we find out we've goofed (such as our ability to later > define PIDF_LO v2 and add a theoretical A4_5 element). However, the > imposition of a hierarchy would seem to prolong any mistakes. > > I am also not sure this is relevant. As you have suggested, the same > mechanism providing location information could also provide country > information. I have suggested taking that one step further; the same > mechanism providing location information could also provide a pointer > (URI) to the mapping service (or perhaps a URI directly to the PSAP in > simple cases, though I suspect that isn't as easy as it sounds). > Since a URI can point anywhere, there is no need for hierarchy. > > > ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 24 11:56:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DablU-0000VN-Vo; Tue, 24 May 2005 11:56:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DablS-0000T2-RG for ecrit@megatron.ietf.org; Tue, 24 May 2005 11:56:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13556 for ; Tue, 24 May 2005 11:56:16 -0400 (EDT) Message-Id: <200505241556.LAA13556@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dac3f-0000Yg-RX for ecrit@ietf.org; Tue, 24 May 2005 12:15:08 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DablI-0001io-6e; Tue, 24 May 2005 10:56:08 -0500 From: "Brian Rosen" To: "'Tom Taylor'" , "'Andrew Newton'" Subject: RE: [Ecrit] Proposed requirement: split responsibility Date: Tue, 24 May 2005 11:55:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVgd0hIjUR5JF+eQNu51rgonr+7dAAAMJPA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <42934B82.9080902@nortel.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tom We have to specify how routing elements behave. It can't be country specific. The entity doing the mapping has to have a well defined procedure to determine the mapping, which includes how it starts, what it does if its first query fails, etc, which works regardless of where it is deployed. Similarly, we have to specify how it is possible for the database to be distributed that is implementable in a practical sense. North America is a hard case, because the boundaries are messy, and the existing databases match those messy boundaries. I agree each country will decide how to organize their database, but we have to supply the mechanisms that make it work for all the conceivable cases. Some countries are real simple; one URI for the entire country. Others, like in North America, are particularly complicated. Japan appears to be in between. I do hope this is in scope; it would be useless if it wasn't. I think scope starts with "you have a location" and ends with "you have a uri (or set of uri's) where signaling should be sent". Brian > -----Original Message----- > From: Tom Taylor [mailto:taylor@nortel.com] > Sent: Tuesday, May 24, 2005 11:43 AM > To: Andrew Newton > Cc: Brian Rosen; ecrit@ietf.org > Subject: Re: [Ecrit] Proposed requirement: split responsibility > > How a given country sets up its database is up to that country. It > could be centralized, distributed according to a hierarchy, or > distributed but redundant. The key requirement is that PIDF-LO and the > query protocol be able to capture the elements of information any > specific database system needs to function properly. And of course, the > database design will to a large extent be determined by what we provide > in the way of query language. > > I have a question about WG scope. Is discovery of the appropriate > mapping server a problem we are supposed to tackle? > > Andrew Newton wrote: > > > > > On May 24, 2005, at 9:36 AM, Brian Rosen wrote: > > > >> Yes, I thing we are agreeing that at the street level, which includes > >> street > >> name, pre and post directionals, and suffix, there is no hierarchy. > >> > >> Similarly, there is no hierarchy for House Number and the House Number > >> Suffix, the Landmark Name, etc. > > > > > > We have progress! :) > > > >> The only point in a hierarchy above that is to create some feasible > >> mechanism to distribute the database. There are reasons to want to > >> do that, > >> and hierarchy makes sense at the city/county/state/country level. > > > > > > As far as state and country, I agree. We have ISO 3166 to hang our > > hat on for this. I'm not sure city and county are concepts that > > easily adapt to the rest of the world. And I believe PIDF-LO has > > further categories such as city division (A4) and neighborhood (A5). > > While other standards bodies have struggled with defining categories > > for civc addresses and failed, we have simply defined what we know and > > moved on. And that seems fine as long as we can come back and modify > > it later when we find out we've goofed (such as our ability to later > > define PIDF_LO v2 and add a theoretical A4_5 element). However, the > > imposition of a hierarchy would seem to prolong any mistakes. > > > > I am also not sure this is relevant. As you have suggested, the same > > mechanism providing location information could also provide country > > information. I have suggested taking that one step further; the same > > mechanism providing location information could also provide a pointer > > (URI) to the mapping service (or perhaps a URI directly to the PSAP in > > simple cases, though I suspect that isn't as easy as it sounds). > > Since a URI can point anywhere, there is no need for hierarchy. > > > > > > > ... > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 24 12:41:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DacSs-0000gb-Mh; Tue, 24 May 2005 12:41:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DacSq-0000gW-KA for ecrit@megatron.ietf.org; Tue, 24 May 2005 12:41:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17577 for ; Tue, 24 May 2005 12:41:05 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dacl3-0002iG-Hq for ecrit@ietf.org; Tue, 24 May 2005 12:59:57 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j4OGeev29556; Tue, 24 May 2005 12:40:40 -0400 (EDT) Received: from [127.0.0.1] (acart570.ca.nortel.com [47.130.17.227]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29WLZFRY; Tue, 24 May 2005 12:40:25 -0400 Message-ID: <429358F7.2030503@nortel.com> Date: Tue, 24 May 2005 12:40:23 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Proposed requirement: split responsibility References: <200505241556.j4OFuR829571@zrtps0kk.us.nortel.com> In-Reply-To: <200505241556.j4OFuR829571@zrtps0kk.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I see the point about independence from point of deployment. I can't see any need for us to specify database design itself. This is surely a country-specific engineering question. However, a complete solution does require: -- possibility for the initial query response to direct a follow-up query (which we have covered in our requirements, I think) -- procedures for advertisement/discovery of the initial point of query (for which I asked the scope question). Brian Rosen wrote: >Tom > >We have to specify how routing elements behave. It can't be country >specific. The entity doing the mapping has to have a well defined procedure >to determine the mapping, which includes how it starts, what it does if its >first query fails, etc, which works regardless of where it is deployed. > >Similarly, we have to specify how it is possible for the database to be >distributed that is implementable in a practical sense. North America is a >hard case, because the boundaries are messy, and the existing databases >match those messy boundaries. > >I agree each country will decide how to organize their database, but we have >to supply the mechanisms that make it work for all the conceivable cases. >Some countries are real simple; one URI for the entire country. Others, >like in North America, are particularly complicated. Japan appears to be in >between. > >I do hope this is in scope; it would be useless if it wasn't. >I think scope starts with "you have a location" and ends with "you have a >uri (or set of uri's) where signaling should be sent". > > >Brian > > > > >>-----Original Message----- >>From: Tom Taylor [mailto:taylor@nortel.com] >>Sent: Tuesday, May 24, 2005 11:43 AM >>To: Andrew Newton >>Cc: Brian Rosen; ecrit@ietf.org >>Subject: Re: [Ecrit] Proposed requirement: split responsibility >> >>How a given country sets up its database is up to that country. It >>could be centralized, distributed according to a hierarchy, or >>distributed but redundant. The key requirement is that PIDF-LO and the >>query protocol be able to capture the elements of information any >>specific database system needs to function properly. And of course, the >>database design will to a large extent be determined by what we provide >>in the way of query language. >> >>I have a question about WG scope. Is discovery of the appropriate >>mapping server a problem we are supposed to tackle? >> >> >> ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 24 12:53:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dacf6-0002zp-UT; Tue, 24 May 2005 12:53:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dacf6-0002zk-3z for ecrit@megatron.ietf.org; Tue, 24 May 2005 12:53:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18487 for ; Tue, 24 May 2005 12:53:45 -0400 (EDT) Message-Id: <200505241653.MAA18487@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DacxJ-0003Bo-RQ for ecrit@ietf.org; Tue, 24 May 2005 13:12:38 -0400 Received: from acs-24-154-127-126.zoominternet.net ([24.154.127.126] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1Dacej-0003CK-8T; Tue, 24 May 2005 11:53:25 -0500 From: "Brian Rosen" To: "'Tom Taylor'" Subject: RE: [Ecrit] Proposed requirement: split responsibility Date: Tue, 24 May 2005 12:53:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVgf1mVjtdQk+hXR7iqU2kxDEiGHAAAaljw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <429358F7.2030503@nortel.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tom Basically, I agree. We must have a mechanism that works IF the database has "messy" boundaries. Referring the query to another server is one of them. Forwarding is another, and parallel or series forking is a third. Those are solutions, not requirements. Brian > -----Original Message----- > From: Tom Taylor [mailto:taylor@nortel.com] > Sent: Tuesday, May 24, 2005 12:40 PM > To: Brian Rosen > Cc: Tom-PT Taylor; 'Andrew Newton'; ecrit@ietf.org > Subject: Re: [Ecrit] Proposed requirement: split responsibility > > I see the point about independence from point of deployment. I can't > see any need for us to specify database design itself. This is surely a > country-specific engineering question. However, a complete solution > does require: > -- possibility for the initial query response to direct a follow-up > query (which we have covered in our requirements, I think) > -- procedures for advertisement/discovery of the initial point of > query (for which I asked the scope question). > > Brian Rosen wrote: > > >Tom > > > >We have to specify how routing elements behave. It can't be country > >specific. The entity doing the mapping has to have a well defined > procedure > >to determine the mapping, which includes how it starts, what it does if > its > >first query fails, etc, which works regardless of where it is deployed. > > > >Similarly, we have to specify how it is possible for the database to be > >distributed that is implementable in a practical sense. North America is > a > >hard case, because the boundaries are messy, and the existing databases > >match those messy boundaries. > > > >I agree each country will decide how to organize their database, but we > have > >to supply the mechanisms that make it work for all the conceivable cases. > >Some countries are real simple; one URI for the entire country. Others, > >like in North America, are particularly complicated. Japan appears to be > in > >between. > > > >I do hope this is in scope; it would be useless if it wasn't. > >I think scope starts with "you have a location" and ends with "you have a > >uri (or set of uri's) where signaling should be sent". > > > > > >Brian > > > > > > > > > >>-----Original Message----- > >>From: Tom Taylor [mailto:taylor@nortel.com] > >>Sent: Tuesday, May 24, 2005 11:43 AM > >>To: Andrew Newton > >>Cc: Brian Rosen; ecrit@ietf.org > >>Subject: Re: [Ecrit] Proposed requirement: split responsibility > >> > >>How a given country sets up its database is up to that country. It > >>could be centralized, distributed according to a hierarchy, or > >>distributed but redundant. The key requirement is that PIDF-LO and the > >>query protocol be able to capture the elements of information any > >>specific database system needs to function properly. And of course, the > >>database design will to a large extent be determined by what we provide > >>in the way of query language. > >> > >>I have a question about WG scope. Is discovery of the appropriate > >>mapping server a problem we are supposed to tackle? > >> > >> > >> > ... > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 24 13:21:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dad5R-0006jU-RU; Tue, 24 May 2005 13:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dad5Q-0006jP-Ih for ecrit@megatron.ietf.org; Tue, 24 May 2005 13:21:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20074 for ; Tue, 24 May 2005 13:20:57 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DadNd-0004AJ-0c for ecrit@ietf.org; Tue, 24 May 2005 13:39:50 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 May 2005 10:20:49 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4OHK6cO008216; Tue, 24 May 2005 10:20:45 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 10:20:44 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 10:20:43 -0700 From: "Marc Linsner" To: "'Tom Taylor'" Subject: RE: [Ecrit] Proposed requirement: split responsibility Date: Tue, 24 May 2005 13:20:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVgd8fWte9DF0AmR8aeU3hDHiG4CQADDWxg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <42934B82.9080902@nortel.com> Message-ID: X-OriginalArrivalTime: 24 May 2005 17:20:44.0011 (UTC) FILETIME=[EABCABB0:01C56084] X-Spam-Score: 1.1 (+) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tom, My opinion (subject to overrule) of your scope question is: Yes, discovery of the appropriate mapping server is within scope of ECRIT. I base this on: 'The group will show how the availability of location data and call routing information at different steps in session setup would enable communication between a user and a relevant emergency response center.' Coupling that with: 'any solution presented must be useful regardless of jurisdiction, and it must be possible to use without a single, central authority.' Matching location data with routing data without a central authority, imo, implies our requirement to explain/define the process of discovery of the appropriate mapping server. -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Tom Taylor > Sent: Tuesday, May 24, 2005 11:43 AM > To: Andrew Newton > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Proposed requirement: split responsibility > > How a given country sets up its database is up to that > country. It could be centralized, distributed according to a > hierarchy, or distributed but redundant. The key requirement > is that PIDF-LO and the query protocol be able to capture the > elements of information any specific database system needs to > function properly. And of course, the database design will > to a large extent be determined by what we provide in the way > of query language. > > I have a question about WG scope. Is discovery of the > appropriate mapping server a problem we are supposed to tackle? > > Andrew Newton wrote: > > > > > On May 24, 2005, at 9:36 AM, Brian Rosen wrote: > > > >> Yes, I thing we are agreeing that at the street level, > which includes > >> street name, pre and post directionals, and suffix, there is no > >> hierarchy. > >> > >> Similarly, there is no hierarchy for House Number and the House > >> Number Suffix, the Landmark Name, etc. > > > > > > We have progress! :) > > > >> The only point in a hierarchy above that is to create some > feasible > >> mechanism to distribute the database. There are reasons > to want to > >> do that, and hierarchy makes sense at the > city/county/state/country > >> level. > > > > > > As far as state and country, I agree. We have ISO 3166 to hang our > > hat on for this. I'm not sure city and county are concepts that > > easily adapt to the rest of the world. And I believe PIDF-LO has > > further categories such as city division (A4) and neighborhood (A5). > > While other standards bodies have struggled with defining > categories > > for civc addresses and failed, we have simply defined what > we know and > > moved on. And that seems fine as long as we can come back > and modify > > it later when we find out we've goofed (such as our ability > to later > > define PIDF_LO v2 and add a theoretical A4_5 element). > However, the > > imposition of a hierarchy would seem to prolong any mistakes. > > > > I am also not sure this is relevant. As you have > suggested, the same > > mechanism providing location information could also provide country > > information. I have suggested taking that one step > further; the same > > mechanism providing location information could also provide > a pointer > > (URI) to the mapping service (or perhaps a URI directly to > the PSAP in > > simple cases, though I suspect that isn't as easy as it sounds). > > Since a URI can point anywhere, there is no need for hierarchy. > > > > > > > ... > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 24 14:20:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dae0u-0001lE-MN; Tue, 24 May 2005 14:20:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dae0s-0001l0-Mb for ecrit@megatron.ietf.org; Tue, 24 May 2005 14:20:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28082 for ; Tue, 24 May 2005 14:20:21 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaeJ6-0007G0-6c for ecrit@ietf.org; Tue, 24 May 2005 14:39:13 -0400 Received: from [160.39.251.169] (dyn-160-39-251-169.dyn.columbia.edu [160.39.251.169]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4OIKEkw014416 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 24 May 2005 14:20:15 -0400 (EDT) In-Reply-To: <13fb4ff3e210f4df86df1d4c5fba424a@hxr.us> References: <13fb4ff3e210f4df86df1d4c5fba424a@hxr.us> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Proposed requirement: split responsibility Date: Tue, 24 May 2005 06:43:44 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.728) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.6 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > I think we are indeed talking past each other. This thread started with the assumption that you're stating below, namely that more than one mapping server may handle subsets of the same civic hierarchy level, such as a city. The assumption here is that the mapping server "above" this level doesn't keep track which child mapping server has what street. (This makes sense since the authority operating each street-level mapping server will generally be responsible for adding new streets, changing street names, or extending house number ranges. In New Jersey at least, coordinating such changes across jurisdictions would probably involve creating a State Department in each hamlet.) To avoid confusion, there was never a problem with having any number of PSAPs handled by the same mapping server, divided according to arbitrary algorithms. If necessary, you could have all house numbers divisible by 7 handled by the lucky PSAP and the rest by the unlucky one. Mapping servers operating on civic coordinates will always have the ability to have individual entries for each house number, and possibly even floor. The same problem doesn't quite exist in the same form for geo addresses, as the mapping hierarchically above the split city would simply have two polygons, one pointing to mapping server A and the other to to B. Since these polygons just describe boundaries, they are not likely to change. Adding a subdivision adds streets or numbers, but doesn't change the communal boundary. (I realize that towns annex unincorporated areas, but that generally means that some other polygon, say, for the county sheriff, shrinks, so this always requires some coordination.) Thus, while this problem can theoretically exist for geo boundaries, it seems far less likely. In any event, I don't have any objections to having a general requirement, but I'd want to make sure that the motivation doesn't obscure the likely problem. > What I'm arguing against is an assumption being applied to our > requirements that somehow mapping services are always going to fall > cleanly across the civil address field boundaries (all those nice > little elements in PIDF-LO that begin with "A"). > > As it so happens, my brother actually runs a PSAP and I get to > bounce a lot of these ideas off of him. His big comment regarding > this notion was that politicians usually don't take into > consideration which PSAP answers the phone when they rename a street. > > -andy > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 24 14:20:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dae0u-0001ld-S6; Tue, 24 May 2005 14:20:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dae0u-0001l9-5k for ecrit@megatron.ietf.org; Tue, 24 May 2005 14:20:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28087 for ; Tue, 24 May 2005 14:20:22 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaeJ7-0007GC-Nt for ecrit@ietf.org; Tue, 24 May 2005 14:39:14 -0400 Received: from [160.39.251.169] (dyn-160-39-251-169.dyn.columbia.edu [160.39.251.169]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4OIKEkx014416 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 24 May 2005 14:20:21 -0400 (EDT) In-Reply-To: <5ba8d0aa8ac2d30963f9f4cf587ff23f@hxr.us> References: <428F8CCB.5080702@cs.columbia.edu> <3f66d1f7a8b55c22b93a39203ab8c47f@hxr.us> <5ba8d0aa8ac2d30963f9f4cf587ff23f@hxr.us> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0ACD20FF-3B88-45D6-9B5D-E79D132A06CF@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Proposed requirement: split responsibility Date: Tue, 24 May 2005 06:50:59 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.728) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.6 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > Certainly. These two coordinate systems are largely independent and you could even have two separate mapping server hierarchies (referral chains) for each type of coordinate. In other words, as Brian noted, you could have a single geo-based mapping server for a whole state/ province and a hierarchy of county, city and borough for civic. Maybe this is another requirement that needs to be made explicit. (There's some argument to be made for such differences. Geospatial boundaries are likely going to be more stable. As an example, town boundaries in New Jersey probably haven't changed since the 1800's and geographic PSAP service areas since the advent of 911, while we still get new streets and subdivisions as the last farm plots are converted to McMansions.) This doesn't affect the issue at hand, however. See my longer message for details. > In the example you gave, I would assume that just because "the > powers that be" divided the PSAP along street north of the railroad > vs south of the railroad still means that some users are gonna use > geographical coordinates to give their location vs. a full civil > address. > > -andy > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 24 20:04:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DajO3-0005t3-EP; Tue, 24 May 2005 20:04:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DajO2-0005sy-Ae for ecrit@megatron.ietf.org; Tue, 24 May 2005 20:04:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07692 for ; Tue, 24 May 2005 20:04:37 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DajgI-0007dF-RL for ecrit@ietf.org; Tue, 24 May 2005 20:23:32 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 24 May 2005 20:04:34 -0400 id 000FB87A.4293C112.00001760 In-Reply-To: <7E012DC3-0EF0-4DC5-8285-1F06C93664B7@cs.columbia.edu> References: <7E012DC3-0EF0-4DC5-8285-1F06C93664B7@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5d4503bec2ea06a344fb37528fd78f60@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] I3, I4, I8 Date: Tue, 24 May 2005 20:04:32 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning, comments in-line: On May 18, 2005, at 10:20 AM, Henning Schulzrinne wrote: > I3: Multi-stage resolution > > The mapping protocol MUST be able to resolve a location to a URL > incrementally, i.e., provide a URL that represents a larger geographic > area, where another invocation of the mapping protocol then provides a > more fine-grained resolution. I'm not exactly sure what you mean by this. "The mapping protocol" is a specification for bits on the wire and not any particular actor in the system. How does it take the action of "resolution"? Which actors in the system are doing the resolution? > Motivation: In some cases, an initial mapping may provide a single URL > for a large geographic area. The ESRP identified by that URL then > re-invokes the mapping protocol on a different database to obtain > another URL for an ESRP or PSAP covering a smaller area. I've not seen ESRP defined in the document (unless I missed it). Google tells me it means "Eldora Special Recreation Program"... which is interesting but not particularly useful. > I4: Return multiple PSAPs > > The mapping protocol MUST be able to return multiple URLs for > different PSAPs that cover the same area. > > The mapping protocol MUST provide additional information that allows > the querying entity to determine relevant properties of the URL. > > Motivation: In some cases, the same geographic area is served by > several PSAPs, for example, a corporate campus might be served by both > a corporate security department and the municipal PSAP. The mapping > protocol should then return URLs for both, with information allowing > the querying entity to choose one or the other. The choice would > typically be made by an ESRP based on local policy, not by a human > user. Again, ESRP is not defined. And I keep getting caught up on the "allows" wording in the second sentence. Perhaps "for the purpose of using". It's a small hair to split. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 25 08:38:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dav9Z-0006nq-QZ; Wed, 25 May 2005 08:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dav9X-0006nl-UZ for ecrit@megatron.ietf.org; Wed, 25 May 2005 08:38:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06603 for ; Wed, 25 May 2005 08:38:26 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DavRu-0004of-3T for ecrit@ietf.org; Wed, 25 May 2005 08:57:28 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4PCcMLW026089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 May 2005 08:38:22 -0400 (EDT) Message-ID: <429471BC.9050003@cs.columbia.edu> Date: Wed, 25 May 2005 08:38:20 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Proposed requirement: split responsibility References: <49cd8c49a32661a63a114f3b9fa63d86@hxr.us> In-Reply-To: <49cd8c49a32661a63a114f3b9fa63d86@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm certainly not suggesting that there is a single hierarchy of PIDF-LO elements or that all levels of that hierarchy are populated in all cases. I am suggesting that there is a general hierarchy, with different tree depths in different countries, but that this is not a simple hierarchy with a fixed referral mechanism. As Brian indicated, in some civic address cases, the next resolution step may under some circumstances not be determinable by simply looking at the address. Again, let me repeat my example: Imagine the city of Smalltown, NJ that is divided by a river, where parts of the city are covered by mapping server A and other parts by mapping server B. (Mapping server A and B may each contain references to any number of ESZs or PSAPs.) For example, streets east of the river are covered by mapping server A, streets west by mapping server B, but the precise division makes no difference. Smalltown, NJ is part of Jefferson County. Jefferson County maintains a mapping server that has an entry for Smalltown, NJ, but it needs to send a query to either server A or server B (or both), since it does not keep track of whether Oak Avenue is east or west of the river (or whether Oak Avenue exists at all). The county mapping server could provide two mapping server URLs to the querier, but that's just one of several possible solutions. The protocol machinery has to support this case unless we explicitly rule it out. The equivalent problem is not likely to exist in geo coordinates. For the geo mapping, the county server would simply have two polygons, one covering the service area east of the river, the other the one west of the river. As long as the river stays in place, this is unlikely to change. In any event, once you support this functionality for civic, the same mechanism is likely to work for geo coordinates. > > As far as state and country, I agree. We have ISO 3166 to hang our hat > on for this. I'm not sure city and county are concepts that easily > adapt to the rest of the world. And I believe PIDF-LO has further > categories such as city division (A4) and neighborhood (A5). While > other standards bodies have struggled with defining categories for civc > addresses and failed, we have simply defined what we know and moved on. > And that seems fine as long as we can come back and modify it later > when we find out we've goofed (such as our ability to later define > PIDF_LO v2 and add a theoretical A4_5 element). However, the imposition > of a hierarchy would seem to prolong any mistakes. > > I am also not sure this is relevant. As you have suggested, the same > mechanism providing location information could also provide country > information. I have suggested taking that one step further; the same > mechanism providing location information could also provide a pointer > (URI) to the mapping service (or perhaps a URI directly to the PSAP in > simple cases, though I suspect that isn't as easy as it sounds). Since > a URI can point anywhere, there is no need for hierarchy. There is no need for a single hierarchy, but there will be a hierarchical graph, unless you assume that every server in the world stores every street address. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 25 11:59:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DayIV-0002wh-0x; Wed, 25 May 2005 11:59:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DayIS-0002wW-WE for ecrit@megatron.ietf.org; Wed, 25 May 2005 11:59:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23590 for ; Wed, 25 May 2005 11:59:50 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dayaq-0001IA-NA for ecrit@ietf.org; Wed, 25 May 2005 12:18:55 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 25 May 2005 11:59:45 -0400 id 000FBA07.4294A0F2.0000456A In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8041ce88a3bd15b3dc999fe55d31a315@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Proposed requirement: split responsibility Date: Wed, 25 May 2005 11:59:44 -0400 To: Marc Linsner , Henning Schulzrinne X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: "'ecrit@ietf.org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org [ Responses to Marc and Henning to avoid clogging the list... ] Not that I disagree with your conclusion, but I take away different meanings from what you have quoted. Comments in-line: On May 24, 2005, at 1:20 PM, Marc Linsner wrote: > 'The group will show how the availability of location data and call > routing information at different steps in session setup would enable > communication between a user and a relevant emergency response > center.' Going back through what has been said in the BoF and WG sessions, I thought this was speaking to the ability of making an emergency call before location information is available. As in, determination of which PSAP to contact should not have to wait on the 30 seconds it takes to get a GPS lock. > 'any solution presented must be useful > regardless of jurisdiction, and it must be possible to use without a > single, central authority.' All I get out of this is that the system shouldn't require a centralized database for any jurisdiction that wishes to break up the data into multiple mapping services. > Matching location data with routing data without a central authority, > imo, > implies our requirement to explain/define the process of discovery of > the > appropriate mapping server. Again, I'm not disagreeing with your conclusion (just a little puzzled about how you arrived at it). But this does bring up a process question: does putting discovery in scope mean that we are to write requirements regarding the discovery mechanism in other protocols, write requirements regarding the interaction between the discovery mechanism and the mapping service, and/or simply write about the discovery mechanism in the OBTW document (we really need a name for that)? I see the last two items as being unproblematic from the "plays well with others" standpoint. However, the first item touches back on the issue of ECRIT going around and telling others what to do based on our requirements (which in some areas is about as welcome as a poke in the eye). In the spirit of writing requirements regarding the interaction between the discovery mechanism and the mapping service (number 2 from above), I propose the following: The mechanism for discovery of a mapping service MUST NOT impose upon the query interface of the mapping service, and the two SHOULD be separable. On May 25, 2005, at 8:38 AM, Henning Schulzrinne wrote: > I'm certainly not suggesting that there is a single hierarchy of > PIDF-LO elements or that all levels of that hierarchy are populated in > all cases. I am suggesting that there is a general hierarchy, with > different tree depths in different countries, but that this is not a > simple hierarchy with a fixed referral mechanism. Perhaps I'm missing the point, but such genericism seems to obviate the imposition of this hierarchy. > As Brian indicated, in some civic address cases, the next resolution > step may under some circumstances not be determinable by simply > looking at the address. Again, let me repeat my example: Imagine the > city of Smalltown, NJ that is divided by a river, where parts of the > city are covered by mapping server A and other parts by mapping server > B. (Mapping server A and B may each contain references to any number > of ESZs or PSAPs.) > > For example, streets east of the river are covered by mapping server > A, streets west by mapping server B, but the precise division makes no > difference. > > Smalltown, NJ is part of Jefferson County. Jefferson County maintains > a mapping server that has an entry for Smalltown, NJ, but it needs to > send a query to either server A or server B (or both), since it does > not keep track of whether Oak Avenue is east or west of the river (or > whether Oak Avenue exists at all). The county mapping server could > provide two mapping server URLs to the querier, but that's just one of > several possible solutions. The protocol machinery has to support this > case unless we explicitly rule it out. If I'm reading this right, you are suggesting the following scenario may be necessary: a) client queries mapping server A b) mapping server A says "I don't know, go query both server B and server C because one of them MAY have the answer" c) client queries both mapping server B and mapping server C If so, that's interesting. I wouldn't say this needs to be ruled out, but it certainly sounds less than ideal. > The equivalent problem is not likely to exist in geo coordinates. For > the geo mapping, the county server would simply have two polygons, one > covering the service area east of the river, the other the one west of > the river. As long as the river stays in place, this is unlikely to > change. In any event, once you support this functionality for civic, > the same mechanism is likely to work for geo coordinates. And I'm still asking myself why you need to care about imposing a hierarchy to do this. What in the referral mechanism is dependent on that? Perhaps the requirement would better be changed to: The mapping protocol MUST NOT inhibit the ability of a mapping provider to distribute mapping service across multiple, distinctly named mapping servers. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 25 15:53:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db1wy-0003fo-Fq; Wed, 25 May 2005 15:53:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db1wv-0003f4-OA for ecrit@megatron.ietf.org; Wed, 25 May 2005 15:53:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16179 for ; Wed, 25 May 2005 15:53:52 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db2FJ-0007Yg-95 for ecrit@ietf.org; Wed, 25 May 2005 16:12:58 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 25 May 2005 12:53:40 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4PJrCmA007113; Wed, 25 May 2005 12:53:37 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 12:53:36 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 12:53:35 -0700 From: "Marc Linsner" To: "'Andrew Newton'" , Subject: RE: [Ecrit] Proposed requirement: split responsibility Date: Wed, 25 May 2005 15:53:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVhT5kraLWjiYerSDG2MHvsMeYIfAAE8Ppw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Message-ID: X-OriginalArrivalTime: 25 May 2005 19:53:35.0598 (UTC) FILETIME=[6FD788E0:01C56163] X-Spam-Score: 1.1 (+) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org No -Marc- > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Wednesday, May 25, 2005 1:31 PM > To: Marc Linsner > Subject: Re: [Ecrit] Proposed requirement: split responsibility > > Did you intentionally mean to exclude the ecrit list in your reply? > > -andy > > > On May 25, 2005, at 1:16 PM, Marc Linsner wrote: > > > Andy, > > > > In-line are 'some' comments, reserving the right to think > about this > > for more than 30 seconds and come back at a later time. > > > > -Marc- > > > >> > >> Not that I disagree with your conclusion, but I take away > different > >> meanings from what you have quoted. Comments in-line: > >> > >> On May 24, 2005, at 1:20 PM, Marc Linsner wrote: > >>> 'The group will show how the availability of location > data and call > >>> routing information at different steps in session setup > >> would enable > >>> communication between a user and a relevant emergency response > >>> center.' > >> > >> Going back through what has been said in the BoF and WG > sessions, I > >> thought this was speaking to the ability of making an > emergency call > >> before location information is available. As in, determination of > >> which PSAP to contact should not have to wait on the 30 seconds it > >> takes to get a GPS lock. > > > > Let's look at the basics. Unlike the PSTN or cellular, unless you > > have some hint as to where to terminate the call, one cannot even > > start the IP call routing process (same address, many destinations) > > prior to knowing location. > > It's easy with the PSTN even if the ALI record process is not > > complete, you simply route to the default for that particular end > > office. Likewise with cellular, you route based on the tower > > location. If you guessed wrong, at least the PSAP that answers can > > transfer the call to their neighboring PSAP. > > So, to accomplish what you describe, you must have some > information in > > order to begin the routing process. But then, the PSAPs have a > > requirement to change the routing db dynamically at their > descretion. > > If you supply an 'early hint' as to how to route the call while > > waiting on your gps, you would have to: > > > > 1) Advise the client via ?? (dhcp?) to a hint for 'early routing' > > > > This would kind of defeat the PSAP requirement for db > change as they > > have to deal with all the dhcp servers that pass out > information for > > their jurisdiction? > > > > 2) Have the VoIP SP maintain a state machine as to your 'location'? > > > > Kind of flies in the face of location privacy??? > > > > Do we need yet a third mechanism for 'get ya close' routing > based on > > source IP address???? > > > >> > >>> 'any solution presented must be useful regardless of > >> jurisdiction, and > >>> it must be possible to use without a single, central authority.' > >> > >> All I get out of this is that the system shouldn't require a > >> centralized database for any jurisdiction that wishes to > break up the > >> data into multiple mapping services. > > > > Going back to Tom's original scope question, is the > discovery of the > > mapping server an ECRIT problem, here are my thoughts. > ECRIT is going > > to describe how to use already defined mechanisms, or > create new ones, > > to solve the problem of emergency context routing. If all we > > accomplish in ECRIT is to pick apart the problem and throw > things over > > the wall to other wgs, we haven't met our goal of providing a > > solution. Even if locating a mapping service is a simply > as: take the > > country code you got via dhcp and stuff in a dns query > > www.us.sos.arpa, so be it. But to state that xyz wg is > going to solve > > that, I don't believe is what the ADs had in mind when they > approved > > the charter. Hence, finding the mapping service in order > to complete > > the emergency context routing process in within scope imo. > Hey, this > > may be a good use for DDDS...... > > > > Afterall, I'm a little surprise the geopriv chair(s) took > all the crap > > ecrit threw at them.......you're just too easy! > > > >> > >>> Matching location data with routing data without a central > >> authority, > >>> imo, implies our requirement to explain/define the process of > >>> discovery of the appropriate mapping server. > >> > >> Again, I'm not disagreeing with your conclusion (just a little > >> puzzled about how you arrived at it). But this does bring up a > >> process > >> question: does putting discovery in scope mean that we are > to write > >> requirements regarding the discovery mechanism in other protocols, > >> write requirements regarding the interaction between the discovery > >> mechanism and the mapping service, and/or simply write about the > >> discovery mechanism in the OBTW document (we really need a > name for > >> that)? I see the last two items as being unproblematic from the > >> "plays well with others" standpoint. However, the first > item touches > >> back on the issue of ECRIT going around and telling others > what to do > >> based on our requirements (which in some areas is about as > welcome as > >> a poke in the eye). > > > > I agree. Given multiple choices with equal functionality, ECRIT > > should choose the path of least resistance. If discovery > of location > > mapping service can use an already proven mechanism vs. > asking dns for > > a rearchitecture (as an example, not a proposed solution!), use the > > existing one. If ECRIT finds that it can't meet the > requirements at > > all levels without rework, we'll start buying beers for other wg > > chairs and ADs. > > > > We may not be able to accomplish our task without involving > > others...... > > > >> > >> In the spirit of writing requirements regarding the interaction > >> between the discovery mechanism and the mapping service (number 2 > >> from above), I propose the following: The mechanism for > discovery of > >> a mapping service MUST NOT impose upon the query interface of the > >> mapping service, and the two SHOULD be separable. > > > > I like that! > > > >> > >> On May 25, 2005, at 8:38 AM, Henning Schulzrinne wrote: > >> > >>> I'm certainly not suggesting that there is a single hierarchy of > >>> PIDF-LO elements or that all levels of that hierarchy are > >> populated in > >>> all cases. I am suggesting that there is a general > hierarchy, with > >>> different tree depths in different countries, but that this > >> is not a > >>> simple hierarchy with a fixed referral mechanism. > >> > >> Perhaps I'm missing the point, but such genericism seems > to obviate > >> the imposition of this hierarchy. > >> > >>> As Brian indicated, in some civic address cases, the next > >> resolution > >>> step may under some circumstances not be determinable by simply > >>> looking at the address. Again, let me repeat my example: > >> Imagine the > >>> city of Smalltown, NJ that is divided by a river, where > >> parts of the > >>> city are covered by mapping server A and other parts by > >> mapping server > >>> B. (Mapping server A and B may each contain references to > >> any number > >>> of ESZs or PSAPs.) > >>> > >>> For example, streets east of the river are covered by > >> mapping server > >>> A, streets west by mapping server B, but the precise > >> division makes no > >>> difference. > >>> > >>> Smalltown, NJ is part of Jefferson County. Jefferson County > >> maintains > >>> a mapping server that has an entry for Smalltown, NJ, but > >> it needs to > >>> send a query to either server A or server B (or both), > >> since it does > >>> not keep track of whether Oak Avenue is east or west of the > >> river (or > >>> whether Oak Avenue exists at all). The county mapping > server could > >>> provide two mapping server URLs to the querier, but that's > >> just one of > >>> several possible solutions. The protocol machinery has to > >> support this > >>> case unless we explicitly rule it out. > >> > >> If I'm reading this right, you are suggesting the > following scenario > >> may be necessary: > >> a) client queries mapping server A > >> b) mapping server A says "I don't know, go query both > server B and > >> server C because one of them MAY have the answer" > >> c) client queries both mapping server B and mapping server C > >> > >> If so, that's interesting. I wouldn't say this needs to be ruled > >> out, but it certainly sounds less than ideal. > >> > >>> The equivalent problem is not likely to exist in geo > >> coordinates. For > >>> the geo mapping, the county server would simply have two > >> polygons, one > >>> covering the service area east of the river, the other the > >> one west of > >>> the river. As long as the river stays in place, this is > unlikely to > >>> change. In any event, once you support this functionality > >> for civic, > >>> the same mechanism is likely to work for geo coordinates. > >> > >> And I'm still asking myself why you need to care about imposing a > >> hierarchy to do this. What in the referral mechanism is > dependent on > >> that? > >> > >> Perhaps the requirement would better be changed to: The mapping > >> protocol MUST NOT inhibit the ability of a mapping provider to > >> distribute mapping service across multiple, distinctly > named mapping > >> servers. > >> > >> -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 25 17:53:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db3oW-0004gt-3X; Wed, 25 May 2005 17:53:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db3oV-0004gl-0m for ecrit@megatron.ietf.org; Wed, 25 May 2005 17:53:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01800 for ; Wed, 25 May 2005 17:53:16 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db46w-0004Lw-UW for ecrit@ietf.org; Wed, 25 May 2005 18:12:24 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 25 May 2005 17:53:14 -0400 id 000FB87A.4294F3CB.00000ECC In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Proposed requirement: split responsibility Date: Wed, 25 May 2005 17:53:09 -0400 To: "Marc Linsner" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Marc, comments in-line: On May 25, 2005, at 3:53 PM, Marc Linsner wrote: >>> >>> Let's look at the basics. Unlike the PSTN or cellular, unless you >>> have some hint as to where to terminate the call, one cannot even >>> start the IP call routing process (same address, many destinations) >>> prior to knowing location. >>> It's easy with the PSTN even if the ALI record process is not >>> complete, you simply route to the default for that particular end >>> office. Likewise with cellular, you route based on the tower >>> location. If you guessed wrong, at least the PSAP that answers can >>> transfer the call to their neighboring PSAP. This assumption has vexed me from the start. There seems to be a notion that IP networks are made up entirely of intangible elements. Is this true? Are there no relationships between IP routes and copper or fiber? >>> So, to accomplish what you describe, you must have some >> information in >>> order to begin the routing process. But then, the PSAPs have a >>> requirement to change the routing db dynamically at their >> descretion. >>> If you supply an 'early hint' as to how to route the call while >>> waiting on your gps, you would have to: >>> >>> 1) Advise the client via ?? (dhcp?) to a hint for 'early routing' >>> >>> This would kind of defeat the PSAP requirement for db >> change as they >>> have to deal with all the dhcp servers that pass out >> information for >>> their jurisdiction? When you say 'dynamic' here, what is the frequency? By the minute or by the month? >>> Going back to Tom's original scope question, is the >> discovery of the >>> mapping server an ECRIT problem, here are my thoughts. >> ECRIT is going >>> to describe how to use already defined mechanisms, or >> create new ones, >>> to solve the problem of emergency context routing. If all we >>> accomplish in ECRIT is to pick apart the problem and throw >> things over >>> the wall to other wgs, we haven't met our goal of providing a >>> solution. Even if locating a mapping service is a simply >> as: take the >>> country code you got via dhcp and stuff in a dns query >>> www.us.sos.arpa, so be it. But to state that xyz wg is >> going to solve >>> that, I don't believe is what the ADs had in mind when they >> approved >>> the charter. Hence, finding the mapping service in order >> to complete >>> the emergency context routing process in within scope imo. >> Hey, this >>> may be a good use for DDDS...... Actually, the qualities you are seeking are for a federated DNS namespace... which require DNS registries... who are acting as central authorities... of which can be argued as being explicitly out of scope by the ECRIT charter text. But we're not talking about solution space yet, are we? >>> If ECRIT finds that it can't meet the >> requirements at >>> all levels without rework, we'll start buying beers for other wg >>> chairs and ADs. Meet you in the bar! -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 25 18:29:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db4NT-0002O8-Kg; Wed, 25 May 2005 18:29:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db4NR-0002O0-BI for ecrit@megatron.ietf.org; Wed, 25 May 2005 18:29:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04904 for ; Wed, 25 May 2005 18:29:22 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db4fs-00053V-JW for ecrit@ietf.org; Wed, 25 May 2005 18:48:31 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 25 May 2005 15:29:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4PMSpmC014801; Wed, 25 May 2005 15:29:11 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 15:29:05 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 15:29:05 -0700 From: "Marc Linsner" To: "'Andrew Newton'" Subject: RE: [Ecrit] Proposed requirement: split responsibility Date: Wed, 25 May 2005 18:29:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVhdH4fA+YMIZZDSbmZXBkOazxEAQAASJJg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Message-ID: X-OriginalArrivalTime: 25 May 2005 22:29:05.0508 (UTC) FILETIME=[28E6D240:01C56179] X-Spam-Score: 1.1 (+) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > > On May 25, 2005, at 3:53 PM, Marc Linsner wrote: > >>> > >>> Let's look at the basics. Unlike the PSTN or cellular, > unless you > >>> have some hint as to where to terminate the call, one cannot even > >>> start the IP call routing process (same address, many > destinations) > >>> prior to knowing location. > >>> It's easy with the PSTN even if the ALI record process is not > >>> complete, you simply route to the default for that particular end > >>> office. Likewise with cellular, you route based on the tower > >>> location. If you guessed wrong, at least the PSAP that > answers can > >>> transfer the call to their neighboring PSAP. > > This assumption has vexed me from the start. There seems to > be a notion that IP networks are made up entirely of > intangible elements. > Is this true? Are there no relationships between IP routes > and copper or fiber? This is the assumption. With VPNs, there is no relationship between physical and IP location. > > >>> So, to accomplish what you describe, you must have some > >> information in > >>> order to begin the routing process. But then, the PSAPs have a > >>> requirement to change the routing db dynamically at their > >> descretion. > >>> If you supply an 'early hint' as to how to route the call while > >>> waiting on your gps, you would have to: > >>> > >>> 1) Advise the client via ?? (dhcp?) to a hint for 'early routing' > >>> > >>> This would kind of defeat the PSAP requirement for db > >> change as they > >>> have to deal with all the dhcp servers that pass out > >> information for > >>> their jurisdiction? > > When you say 'dynamic' here, what is the frequency? By the > minute or by the month? The common scenario is the responder that normal utilizes a bridge to reach it's jurisdiction wants calls to route differently if the bridge were to fail. How often does this happen? No very often, but it's not predicable and needs to work on very short notice. > > >>> Going back to Tom's original scope question, is the > >> discovery of the > >>> mapping server an ECRIT problem, here are my thoughts. > >> ECRIT is going > >>> to describe how to use already defined mechanisms, or > >> create new ones, > >>> to solve the problem of emergency context routing. If all we > >>> accomplish in ECRIT is to pick apart the problem and throw > >> things over > >>> the wall to other wgs, we haven't met our goal of providing a > >>> solution. Even if locating a mapping service is a simply > >> as: take the > >>> country code you got via dhcp and stuff in a dns query > >>> www.us.sos.arpa, so be it. But to state that xyz wg is > >> going to solve > >>> that, I don't believe is what the ADs had in mind when they > >> approved > >>> the charter. Hence, finding the mapping service in order > >> to complete > >>> the emergency context routing process in within scope imo. > >> Hey, this > >>> may be a good use for DDDS...... > > Actually, the qualities you are seeking are for a federated > DNS namespace... which require DNS registries... who are > acting as central authorities... of which can be argued as > being explicitly out of scope by the ECRIT charter text. But > we're not talking about solution space yet, are we? I only mentioned DDDS as it's already been discussed. I've not proposed any solution. -Marc- > > >>> If ECRIT finds that it can't meet the > >> requirements at > >>> all levels without rework, we'll start buying beers for other wg > >>> chairs and ADs. > > Meet you in the bar! > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 25 20:06:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db5tf-0001Yo-8k; Wed, 25 May 2005 20:06:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db5te-0001Yj-NY for ecrit@megatron.ietf.org; Wed, 25 May 2005 20:06:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10121 for ; Wed, 25 May 2005 20:06:43 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db6C5-0006sQ-QK for ecrit@ietf.org; Wed, 25 May 2005 20:25:51 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4Q06XXc023599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 May 2005 20:06:33 -0400 (EDT) Message-ID: <42951304.2010408@cs.columbia.edu> Date: Wed, 25 May 2005 20:06:28 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] Proposed requirement: split responsibility References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > This is the assumption. With VPNs, there is no relationship between > physical and IP location. Also, while in non-VPN cases, there may be some connection to location, often, a whole enterprise has the same IP address range. As a local example, the Columbia conference/retreat center, Arden House, shares the same IP address range as the main campus in Manhattan, which happens to be about 54 miles south and in a different county. Some geo-mapping software puts me in Jersey City, which is probably about 20 miles away. Some cable systems probably span a county, while each town in New Jersey has its own PSAP (in addition to its own foreign policy and customs offices). _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 25 20:24:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db6Ad-0003lo-1n; Wed, 25 May 2005 20:24:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db6Ab-0003le-IA for ecrit@megatron.ietf.org; Wed, 25 May 2005 20:24:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11306 for ; Wed, 25 May 2005 20:24:16 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db6T5-0007Ck-Ts for ecrit@ietf.org; Wed, 25 May 2005 20:43:24 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4Q0M9uV025425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 May 2005 20:22:09 -0400 (EDT) Message-ID: <429516AC.3000707@cs.columbia.edu> Date: Wed, 25 May 2005 20:22:04 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Proposed requirement: split responsibility References: <8041ce88a3bd15b3dc999fe55d31a315@hxr.us> In-Reply-To: <8041ce88a3bd15b3dc999fe55d31a315@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: "'ecrit@ietf.org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > Going back through what has been said in the BoF and WG sessions, I > thought this was speaking to the ability of making an emergency call > before location information is available. As in, determination of which > PSAP to contact should not have to wait on the 30 seconds it takes to > get a GPS lock. Sure. In many cases, you might be able to get a rough location fix, e.g., by having DHCP provide you with the (WiMax/WiFi) tower location on boot/movement into range. This would be available before the emergency, without delay. But I don't see how this affects ECRIT. > >> 'any solution presented must be useful >> regardless of jurisdiction, and it must be possible to use without a >> single, central authority.' > > > All I get out of this is that the system shouldn't require a centralized > database for any jurisdiction that wishes to break up the data into > multiple mapping services. Which, given alternative proposals elsewhere, may seem obvious to you and me, but may not be. > requirements regarding the discovery mechanism in other protocols, write > requirements regarding the interaction between the discovery mechanism > and the mapping service, and/or simply write about the discovery > mechanism in the OBTW document (we really need a name for that)? I see However this is done, we need to be able to tell a complete story and can't just say "and then magic happens". For example, we defined the appropriate discovery mechanism (inter alia, a DHCP option) for SIP, for example. While there might be several mechanism, not offering a reasonable set of viable choices means that we don't get a useful mapping protocol. > > Perhaps I'm missing the point, but such genericism seems to obviate the > imposition of this hierarchy. It simply means that the referral relationship of mapping servers has to be a tree, not a general graph. Otherwise, you'd get referral loops, for example. Again, this is probably pretty obvious to most of the participants, but not necessarily to the world at large. > If I'm reading this right, you are suggesting the following scenario may > be necessary: > a) client queries mapping server A > b) mapping server A says "I don't know, go query both server B and > server C because one of them MAY have the answer" > c) client queries both mapping server B and mapping server C Server A may not even know that there's B (as opposed to C, D, through Z). In this example, Jefferson County has to know. Thus, it may provide this informatin. > > If so, that's interesting. I wouldn't say this needs to be ruled out, > but it certainly sounds less than ideal. I wouldn't build a system like that, but we're defining requirements for the mapping protocol, not designing server graphs. If we rule out this condition, all of the end-of-interim discussion about lame delegations becomes moot, for example. > And I'm still asking myself why you need to care about imposing a > hierarchy to do this. What in the referral mechanism is dependent on that? The ability to return more than one next-step URL, for example. > > Perhaps the requirement would better be changed to: The mapping protocol > MUST NOT inhibit the ability of a mapping provider to distribute mapping > service across multiple, distinctly named mapping servers. Again, the real problem only occurs if the 'parent' server can't know which server is responsible for the next layer down. Thus, while your generic requirement isn't wrong, it obscures the difficult case. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 25 21:40:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db7Ly-0005OT-L0; Wed, 25 May 2005 21:40:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db7Lu-0005Jz-Es for ecrit@megatron.ietf.org; Wed, 25 May 2005 21:40:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20795 for ; Wed, 25 May 2005 21:40:00 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db7eP-0001ht-CQ for ecrit@ietf.org; Wed, 25 May 2005 21:59:09 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 25 May 2005 21:39:55 -0400 id 000FBA11.429528EB.00003D4B In-Reply-To: <429516AC.3000707@cs.columbia.edu> References: <8041ce88a3bd15b3dc999fe55d31a315@hxr.us> <429516AC.3000707@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Proposed requirement: split responsibility Date: Wed, 25 May 2005 21:39:54 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: "'ecrit@ietf.org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On May 25, 2005, at 8:22 PM, Henning Schulzrinne wrote: >> Going back through what has been said in the BoF and WG sessions, I >> thought this was speaking to the ability of making an emergency call >> before location information is available. As in, determination of >> which PSAP to contact should not have to wait on the 30 seconds it >> takes to get a GPS lock. > > Sure. In many cases, you might be able to get a rough location fix, > e.g., by having DHCP provide you with the (WiMax/WiFi) tower location > on boot/movement into range. This would be available before the > emergency, without delay. But I don't see how this affects ECRIT. Given that this part of the thread is about what is and is not part of the charter for ECRIT, it would seem directly relevant to how it affects ECRIT. I don't really care about this, so I'm gonna drop it. >> Perhaps I'm missing the point, but such genericism seems to obviate >> the imposition of this hierarchy. > > It simply means that the referral relationship of mapping servers has > to be a tree, not a general graph. Otherwise, you'd get referral > loops, for example. Tree structures that make references to the top of the tree need to guard against referral loops too. And referral loop detection is not that hard in a general graph when the nodes are distinctly named. Besides, in the case you have stated with URLs being passed back to be acted upon again, the client SHOULD be doing referral loop detection if it knows what's good for itself. > I wouldn't build a system like that, but we're defining requirements > for the mapping protocol, not designing server graphs. If we rule out > this condition, all of the end-of-interim discussion about lame > delegations becomes moot, for example. Not in the geo case, which is actually where I started the discussion at the interim. >> Perhaps the requirement would better be changed to: The mapping >> protocol MUST NOT inhibit the ability of a mapping provider to >> distribute mapping service across multiple, distinctly named mapping >> servers. > > Again, the real problem only occurs if the 'parent' server can't know > which server is responsible for the next layer down. Thus, while your > generic requirement isn't wrong, it obscures the difficult case. Ah! Now we're getting somewhere. But this still doesn't necessitate an ECRIT defined hierarchy. There is nothing to say that Server A can't formulate a referral based on the given location information to Server B where all the servers in that jurisdiction have accepted a certain naming convention. They can come to this agreement regarding their own jurisdictional based tree structure without causing the whole world to do the same. Even better, they can decide to change that tree structure without having to reconfigure every client that may come into contact with their services. Thanks for your patience. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 25 21:47:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db7TK-0006Zm-W9; Wed, 25 May 2005 21:47:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db7TK-0006Zh-H9 for ecrit@megatron.ietf.org; Wed, 25 May 2005 21:47:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21104 for ; Wed, 25 May 2005 21:47:40 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db7lo-0001pd-Ky for ecrit@ietf.org; Wed, 25 May 2005 22:06:49 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4Q1lZ3q003992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 May 2005 21:47:36 -0400 (EDT) Message-ID: <42952AAE.4020808@cs.columbia.edu> Date: Wed, 25 May 2005 21:47:26 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] I3, I4, I8 References: <7E012DC3-0EF0-4DC5-8285-1F06C93664B7@cs.columbia.edu> <5d4503bec2ea06a344fb37528fd78f60@hxr.us> In-Reply-To: <5d4503bec2ea06a344fb37528fd78f60@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andrew Newton wrote: > Henning, comments in-line: > > On May 18, 2005, at 10:20 AM, Henning Schulzrinne wrote: > >> I3: Multi-stage resolution >> >> The mapping protocol MUST be able to resolve a location to a URL >> incrementally, i.e., provide a URL that represents a larger geographic >> area, where another invocation of the mapping protocol then provides a >> more fine-grained resolution. > > > I'm not exactly sure what you mean by this. "The mapping protocol" is a > specification for bits on the wire and not any particular actor in the > system. How does it take the action of "resolution"? Which actors in > the system are doing the resolution? We need to agree on terminology. The mapping server, maybe? > >> Motivation: In some cases, an initial mapping may provide a single URL >> for a large geographic area. The ESRP identified by that URL then >> re-invokes the mapping protocol on a different database to obtain >> another URL for an ESRP or PSAP covering a smaller area. > > > I've not seen ESRP defined in the document (unless I missed it). Google > tells me it means "Eldora Special Recreation Program"... which is > interesting but not particularly useful. I thought we agreed at the interim that this Emergency Services Routing Proxy was to be added to the definition list, but maybe I misremember. > >> I4: Return multiple PSAPs >> >> The mapping protocol MUST be able to return multiple URLs for >> different PSAPs that cover the same area. >> >> The mapping protocol MUST provide additional information that allows >> the querying entity to determine relevant properties of the URL. >> >> Motivation: In some cases, the same geographic area is served by >> several PSAPs, for example, a corporate campus might be served by both >> a corporate security department and the municipal PSAP. The mapping >> protocol should then return URLs for both, with information allowing >> the querying entity to choose one or the other. The choice would >> typically be made by an ESRP based on local policy, not by a human user. > > > Again, ESRP is not defined. And I keep getting caught up on the > "allows" wording in the second sentence. Perhaps "for the purpose of > using". It's a small hair to split. > > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 25 22:13:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db7sY-0002pL-Be; Wed, 25 May 2005 22:13:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db7sX-0002pE-AW for ecrit@megatron.ietf.org; Wed, 25 May 2005 22:13:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22867 for ; Wed, 25 May 2005 22:13:43 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db8B2-0002Qx-Js for ecrit@ietf.org; Wed, 25 May 2005 22:32:52 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 25 May 2005 22:13:43 -0400 id 000FBA14.429530D7.0000433D In-Reply-To: <42952AAE.4020808@cs.columbia.edu> References: <7E012DC3-0EF0-4DC5-8285-1F06C93664B7@cs.columbia.edu> <5d4503bec2ea06a344fb37528fd78f60@hxr.us> <42952AAE.4020808@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <451965ca361283873a51b3d60aa0ed51@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] I3, I4, I8 Date: Wed, 25 May 2005 22:13:41 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On May 25, 2005, at 9:47 PM, Henning Schulzrinne wrote: > Andrew Newton wrote: >> Henning, comments in-line: >> On May 18, 2005, at 10:20 AM, Henning Schulzrinne wrote: >>> I3: Multi-stage resolution >>> >>> The mapping protocol MUST be able to resolve a location to a URL >>> incrementally, i.e., provide a URL that represents a larger >>> geographic area, where another invocation of the mapping protocol >>> then provides a more fine-grained resolution. >> I'm not exactly sure what you mean by this. "The mapping protocol" >> is a specification for bits on the wire and not any particular actor >> in the system. How does it take the action of "resolution"? Which >> actors in the system are doing the resolution? > > We need to agree on terminology. The mapping server, maybe? I don't think this is a terminology issue. The statement should be about some high level function that the protocol MUST/SHOULD support, and I doubt that high-level function is incremental URL resolution. If the requirement is that the a mapping server for a large geographic area should be able to refer clients to mapping servers responsible for subsets of the geographic area, then let's say that. However, a statement that speaks of passing around URL's so that they may be reiteratively invoked seems to be speaking to a solution and not a functional requirement. >>> Motivation: In some cases, an initial mapping may provide a single >>> URL for a large geographic area. The ESRP identified by that URL >>> then re-invokes the mapping protocol on a different database to >>> obtain another URL for an ESRP or PSAP covering a smaller area. >> I've not seen ESRP defined in the document (unless I missed it). >> Google tells me it means "Eldora Special Recreation Program"... which >> is interesting but not particularly useful. > > I thought we agreed at the interim that this Emergency Services > Routing Proxy was to be added to the definition list, but maybe I > misremember. Its possible we did agree on that, and I just zoned it out. What exactly is it suppose to do and which protocol is related to? Is it to speak the same language as the mapping protocol or is it more specific to a using protocol? What are the properties associated with its proxy function? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 25 22:36:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db8Eh-0007Nn-4y; Wed, 25 May 2005 22:36:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db8Ef-0007Ni-Pg for ecrit@megatron.ietf.org; Wed, 25 May 2005 22:36:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24611 for ; Wed, 25 May 2005 22:36:35 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db8XA-00031G-DZ for ecrit@ietf.org; Wed, 25 May 2005 22:55:45 -0400 Received: from [192.168.0.31] (pool-138-89-100-232.mad.east.verizon.net [138.89.100.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4Q2aXNg025214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 May 2005 22:36:34 -0400 (EDT) Message-ID: <42953627.5010503@cs.columbia.edu> Date: Wed, 25 May 2005 22:36:23 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton , ecrit@ietf.org Subject: Re: [Ecrit] I3, I4, I8 References: <7E012DC3-0EF0-4DC5-8285-1F06C93664B7@cs.columbia.edu> <5d4503bec2ea06a344fb37528fd78f60@hxr.us> <42952AAE.4020808@cs.columbia.edu> <451965ca361283873a51b3d60aa0ed51@hxr.us> In-Reply-To: <451965ca361283873a51b3d60aa0ed51@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andrew Newton wrote: > > I don't think this is a terminology issue. The statement should be > about some high level function that the protocol MUST/SHOULD support, > and I doubt that high-level function is incremental URL resolution. If > the requirement is that the a mapping server for a large geographic area > should be able to refer clients to mapping servers responsible for > subsets of the geographic area, then let's say that. However, a Works for me. > statement that speaks of passing around URL's so that they may be > reiteratively invoked seems to be speaking to a solution and not a > functional requirement. > > Its possible we did agree on that, and I just zoned it out. What > exactly is it suppose to do and which protocol is related to? Is it to > speak the same language as the mapping protocol or is it more specific > to a using protocol? What are the properties associated with its proxy > function? It's the logical entity that routes call signaling and is one of the logical entities invoking the mapping protocol as well as an entity that would be identified (by URL, presumably) as the output of the mapping protocol. In SIP terms: it's a proxy server. Could be the proxy server for a whole emergency services region (county, country, state) or for a single PSAP. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 26 19:08:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbRSw-0002d9-Uh; Thu, 26 May 2005 19:08:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbRSv-0002cs-RJ for ecrit@megatron.ietf.org; Thu, 26 May 2005 19:08:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22457 for ; Thu, 26 May 2005 19:08:34 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbRlb-0001Pl-1w for ecrit@ietf.org; Thu, 26 May 2005 19:27:56 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4QN87CK014046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 May 2005 16:08:07 -0700 (PDT) Received: from [192.168.1.4] (vpn-10-50-0-75.qualcomm.com [10.50.0.75]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j4QN83J9003866; Thu, 26 May 2005 16:08:05 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <42953627.5010503@cs.columbia.edu> References: <7E012DC3-0EF0-4DC5-8285-1F06C93664B7@cs.columbia.edu> <5d4503bec2ea06a344fb37528fd78f60@hxr.us> <42952AAE.4020808@cs.columbia.edu> <451965ca361283873a51b3d60aa0ed51@hxr.us> <42953627.5010503@cs.columbia.edu> Date: Thu, 26 May 2005 16:08:01 -0700 To: Henning Schulzrinne , Andrew Newton , ecrit@ietf.org From: Ted Hardie Subject: Re: [Ecrit] I3, I4, I8 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 10:36 PM -0400 5/25/05, Henning Schulzrinne wrote: > >It's the logical entity that routes call signaling and is one of the >logical entities invoking the mapping protocol as well as an entity >that would be identified (by URL, presumably) as the output of the >mapping protocol. > >In SIP terms: it's a proxy server. Could be the proxy server for a >whole emergency services region (county, country, state) or for a >single PSAP. > So this might be used in any protocol that appears in a contact URI that might be returned by the mapping server? It might be worth capturing that. The example I'm thinking of is one in which the user experiencing the emergency constructs a special-purpose indicator that tells the next-upstream network element that it had not yet done the mapping and that it needed the mapping done for it. So a SIP URI with a target like sos:fire, or an XMMP URI with a similar target. But the ESRP you reach by each contact method is likely to be distinct. It seems like almost everything about the ESRPs will need to be passed back to the protocol-specfic groups, though. regards, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 27 10:23:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbfk7-0004OE-Ps; Fri, 27 May 2005 10:23:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbfk6-0004M1-Di for ecrit@megatron.ietf.org; Fri, 27 May 2005 10:23:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15806 for ; Fri, 27 May 2005 10:23:16 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbg2u-0004NG-Nx for ecrit@ietf.org; Fri, 27 May 2005 10:42:45 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 10:23:06 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4REN3l6001193; Fri, 27 May 2005 10:23:03 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 10:22:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] I3, I4, I8 Date: Fri, 27 May 2005 10:22:58 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E334685F@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] I3, I4, I8 Thread-Index: AcVhnRDdq2zBpawCR2yxxhrg/jBGMQBKfyXA From: "Michael Hammer \(mhammer\)" To: "Henning Schulzrinne" , "Andrew Newton" , X-OriginalArrivalTime: 27 May 2005 14:22:59.0819 (UTC) FILETIME=[959F5BB0:01C562C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning, I must have missed something that was not posted to the mail list. Is the ESRP a substitute for the Selective Router, once the TDM components are gone? That is, a route server (proxy) serving the calling party routes calls to the ESRP that can terminate to the called PSAP? Mike =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Henning Schulzrinne > Sent: Wednesday, May 25, 2005 10:36 PM > To: Andrew Newton; ecrit@ietf.org > Subject: Re: [Ecrit] I3, I4, I8 >=20 > Andrew Newton wrote: > >=20 >=20 > > I don't think this is a terminology issue. The statement should be=20 > > about some high level function that the protocol=20 > MUST/SHOULD support,=20 > > and I doubt that high-level function is incremental URL=20 > resolution. =20 > > If the requirement is that the a mapping server for a large=20 > geographic=20 > > area should be able to refer clients to mapping servers responsible=20 > > for subsets of the geographic area, then let's say that. However, a >=20 > Works for me. >=20 >=20 > > statement that speaks of passing around URL's so that they may be=20 > > reiteratively invoked seems to be speaking to a solution and not a=20 > > functional requirement. > >=20 > > Its possible we did agree on that, and I just zoned it out. What=20 > > exactly is it suppose to do and which protocol is related=20 > to? Is it=20 > > to speak the same language as the mapping protocol or is it more=20 > > specific to a using protocol? What are the properties=20 > associated with=20 > > its proxy function? >=20 > It's the logical entity that routes call signaling and is one=20 > of the logical entities invoking the mapping protocol as well=20 > as an entity that would be identified (by URL, presumably) as=20 > the output of the mapping protocol. >=20 > In SIP terms: it's a proxy server. Could be the proxy server=20 > for a whole emergency services region (county, country,=20 > state) or for a single PSAP. >=20 >=20 >=20 > >=20 > > -andy >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 27 10:35:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbfvj-0006Zm-Lq; Fri, 27 May 2005 10:35:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbfvi-0006Zc-N8 for ecrit@megatron.ietf.org; Fri, 27 May 2005 10:35:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16928 for ; Fri, 27 May 2005 10:35:16 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbgEV-0004du-P3 for ecrit@ietf.org; Fri, 27 May 2005 10:54:45 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j4REYwmD009219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 May 2005 10:34:59 -0400 (EDT) Message-ID: <4297300D.3050503@cs.columbia.edu> Date: Fri, 27 May 2005 10:34:53 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Ecrit] I3, I4, I8 References: <072C5B76F7CEAB488172C6F64B30B5E334685F@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E334685F@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Michael Hammer (mhammer) wrote: > Henning, > > I must have missed something that was not posted to the mail list. > > Is the ESRP a substitute for the Selective Router, once the TDM > components are gone? I'm somewhat loath to use TDM analogies as they never quite fit, but in some very rough sense, yes. > > That is, a route server (proxy) serving the calling party routes calls > to the ESRP that can terminate to the called PSAP? Not quite. The ESRP is the call routing entity that invokes the location-to-URL mapping, which in turn may return either the URL for another ESRP or the PSAP. In a SIP system, the ESRP would typically be a SIP proxy, but I suspect it could also be a B2BUA if you subscribe to that particular religion. (To avoid needless "but" messages: We all recognize that the end system can also invoke the mapping function.) > > Mike > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 27 11:47:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbh38-0004dV-II; Fri, 27 May 2005 11:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbh36-0004dN-OJ for ecrit@megatron.ietf.org; Fri, 27 May 2005 11:47:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21855 for ; Fri, 27 May 2005 11:46:58 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbhLu-0006Cg-TB for ecrit@ietf.org; Fri, 27 May 2005 12:06:28 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j4RFkomD012892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 May 2005 11:46:51 -0400 (EDT) Message-ID: <429740E4.8070300@cs.columbia.edu> Date: Fri, 27 May 2005 11:46:44 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] I3, I4, I8 References: <7E012DC3-0EF0-4DC5-8285-1F06C93664B7@cs.columbia.edu> <5d4503bec2ea06a344fb37528fd78f60@hxr.us> <42952AAE.4020808@cs.columbia.edu> <451965ca361283873a51b3d60aa0ed51@hxr.us> <42953627.5010503@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At least in the SIP case, I don't see how this would be needed. To make this concrete, a fictitious example: - Caller uses ECRIT mapping protocol to translate "123 Main Street, Anytown, Jefferson County, NY, USA" to sip:somebody@emergency.ny.gov, the NY state emergency services ESRP. - Routes calls to sip:somebody@emergency.ny.gov (ESRP), using standard SIP mechanisms. - ESRP at sip:somebody@emergency.ny.gov takes address and converts (via mapping protocol, but a different "private" database) this to sip:foo@jefferson-county.gov. Call gets routed there by standard SIP mechanisms. - ESRP at sip:foo@jefferson-county.gov repeats process and gets sip:fire@anytown-ny.gov, the PSAP. Quite a few emergency services folks have asked for this type of iterative resolution. Thus, no resolution indicators are needed. It's obvious from the SIP request URL. Adding one would simply add a failure case, namely contradiction between apparent and claimed resolution. > So this might be used in any protocol that appears in a contact URI > that might be returned by the mapping server? It might be worth > capturing that. > > The example I'm thinking of is one in which the user experiencing the > emergency constructs a special-purpose indicator that tells the > next-upstream > network element that it had not yet done the mapping and that it needed > the mapping done for it. So a SIP URI with a target like sos:fire, or an > XMMP URI with a similar target. But the ESRP you reach by each contact > method is likely to be distinct. > > It seems like almost everything about the ESRPs will need to be passed > back to the protocol-specfic groups, though. > regards, > Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 27 16:48:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbllA-0003IV-Lr; Fri, 27 May 2005 16:48:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbll8-0003IN-P9 for ecrit@megatron.ietf.org; Fri, 27 May 2005 16:48:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02867 for ; Fri, 27 May 2005 16:48:44 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dbm40-0002Am-25 for ecrit@ietf.org; Fri, 27 May 2005 17:08:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] I3, I4, I8 Date: Fri, 27 May 2005 22:51:38 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BED0@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] I3, I4, I8 Thread-Index: AcVi1C0ReBrOMNofS2OVSQyPWiZ4SAAKMB7o From: "Stastny Richard" To: "Henning Schulzrinne" , "Ted Hardie" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I basically like this approach, because it also contains the possiblitly to deviate at any point to national specifics and also to feed into national specific TDM solutions via ESRP=20 acting as gateways, hiding the mapping and routing required totally from IP based emergency calls. =20 Just a minor question (maybe I missed it, I was recently busy with other things and trying to catch up): =20 What is the meaning of the somebody and foo userparts in the sip URI.? Shouldn't this be sos or sos:fire? =20 best regards Richard ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Henning Schulzrinne Gesendet: Fr 27.05.2005 17:46 An: Ted Hardie Cc: ecrit@ietf.org Betreff: Re: [Ecrit] I3, I4, I8 At least in the SIP case, I don't see how this would be needed. To make this concrete, a fictitious example: - Caller uses ECRIT mapping protocol to translate "123 Main Street, Anytown, Jefferson County, NY, USA" to sip:somebody@emergency.ny.gov, the NY state emergency services ESRP. - Routes calls to sip:somebody@emergency.ny.gov (ESRP), using standard SIP mechanisms. - ESRP at sip:somebody@emergency.ny.gov takes address and converts (via mapping protocol, but a different "private" database) this to sip:foo@jefferson-county.gov. Call gets routed there by standard SIP mechanisms. - ESRP at sip:foo@jefferson-county.gov repeats process and gets sip:fire@anytown-ny.gov, the PSAP. Quite a few emergency services folks have asked for this type of iterative resolution. Thus, no resolution indicators are needed. It's obvious from the SIP request URL. Adding one would simply add a failure case, namely contradiction between apparent and claimed resolution. > So this might be used in any protocol that appears in a contact URI > that might be returned by the mapping server? It might be worth > capturing that. > > The example I'm thinking of is one in which the user experiencing the > emergency constructs a special-purpose indicator that tells the > next-upstream > network element that it had not yet done the mapping and that it = needed > the mapping done for it. So a SIP URI with a target like sos:fire, or = an > XMMP URI with a similar target. But the ESRP you reach by each = contact > method is likely to be distinct. > > It seems like almost everything about the ESRPs will need to be passed > back to the protocol-specfic groups, though. > regards, > Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 27 17:28:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbmN7-0002oP-0N; Fri, 27 May 2005 17:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbmN5-0002nj-VA for ecrit@megatron.ietf.org; Fri, 27 May 2005 17:28:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06145 for ; Fri, 27 May 2005 17:27:57 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbmfw-000374-8K for ecrit@ietf.org; Fri, 27 May 2005 17:47:30 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j4RLRhmD001617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 May 2005 17:27:44 -0400 (EDT) Message-ID: <429790CA.7060207@cs.columbia.edu> Date: Fri, 27 May 2005 17:27:38 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Ecrit] I3, I4, I8 References: <32755D354E6B65498C3BD9FD496C7D4613BED0@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BED0@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Stastny Richard wrote: > I basically like this approach, because it also contains the > possiblitly to deviate at any point to national specifics and > also to feed into national specific TDM solutions via ESRP > acting as gateways, hiding the mapping and routing required > totally from IP based emergency calls. > > Just a minor question (maybe I missed it, I was recently busy > with other things and trying to catch up): > > What is the meaning of the somebody and foo userparts in the > sip URI.? Shouldn't this be sos or sos:fire? Not necessarily. The 'sos' designation is only necessary until the call reaches the first ESRP. After that, the receiving ESRPs presumably can recognize the limited set of URLs as being an emergency service vs. the general PSAP administrator. Obviously, there's nothing wrong with using sip:sos@emergency.ny.gov. Implementations clearly have to be careful not to lose information, e.g., about the emergency service originally requested, for jurisdictions where fire and police, for example, use different identifiers. The media feature tag (sip.emergency-service) described in the 'sos' draft can ensure that. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 27 17:48:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbmgi-0006s1-Vq; Fri, 27 May 2005 17:48:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbmgg-0006rw-Vp for ecrit@megatron.ietf.org; Fri, 27 May 2005 17:48:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07545 for ; Fri, 27 May 2005 17:48:12 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DbmzY-0003Zs-Aw for ecrit@ietf.org; Fri, 27 May 2005 18:07:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] I3, I4, I8 Date: Fri, 27 May 2005 23:51:14 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BED1@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] I3, I4, I8 Thread-Index: AcVjA2c17N8SCnJYSZeAZZ0Y8I8BeQAAaTr6 From: "Stastny Richard" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thanks Henning for the clarification =20 This is very important information because it allows special ESRPs or mapping servers interworking with the PSTN to replace the=20 sos.fire with the special phone number required on the PoI to feed into the emergency service routing system eg in our case sip:4321133@gw.foo.net to call e.g police in a certain PSAP area. =20 Richard Stastny Richard wrote: > I basically like this approach, because it also contains the > possiblitly to deviate at any point to national specifics and > also to feed into national specific TDM solutions via ESRP > acting as gateways, hiding the mapping and routing required > totally from IP based emergency calls. >=20 > Just a minor question (maybe I missed it, I was recently busy > with other things and trying to catch up): >=20 > What is the meaning of the somebody and foo userparts in the > sip URI.? Shouldn't this be sos or sos:fire? Not necessarily. The 'sos' designation is only necessary until the call reaches the first ESRP. After that, the receiving ESRPs presumably can recognize the limited set of URLs as being an emergency service vs. the general PSAP administrator. Obviously, there's nothing wrong with using sip:sos@emergency.ny.gov. Implementations clearly have to be careful not to lose information, e.g., about the emergency service originally requested, for jurisdictions where fire and police, for example, use different identifiers. The media feature tag (sip.emergency-service) described in the 'sos' draft can ensure that. >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 30 16:31:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcqua-0006Tp-WE; Mon, 30 May 2005 16:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcquZ-0006Tk-ME for ecrit@megatron.ietf.org; Mon, 30 May 2005 16:30:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11830 for ; Mon, 30 May 2005 16:30:57 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcrE2-0008Rg-9M for ecrit@ietf.org; Mon, 30 May 2005 16:51:07 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j4UKUmhv014515 for ; Mon, 30 May 2005 22:30:48 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j4UKUmf9012830 for ; Mon, 30 May 2005 22:30:48 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 May 2005 22:30:48 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 30 May 2005 22:30:47 +0200 Message-ID: Thread-Topic: interim meeting minutes Thread-Index: AcVlVnIBfPSYrtkaQ4OuY2xztop84g== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 30 May 2005 20:30:48.0170 (UTC) FILETIME=[769FBCA0:01C56556] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] interim meeting minutes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 here is a first version of the meeting minutes.=20 please take a look at:=20 http://www.ietf-ecrit.org/Interim2005/ECRIT-Meeting-Minutes.txt please take a look at the participant list since i wasn't able to read all names listed on the blue sheet.=20 ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit