From ecrit-bounces@ietf.org Sun Apr 02 21:10:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDam-0006Ip-Fe; Sun, 02 Apr 2006 21:10:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDal-0006Ij-HO for ecrit@ietf.org; Sun, 02 Apr 2006 21:10:51 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQDak-000441-8T for ecrit@ietf.org; Sun, 02 Apr 2006 21:10:51 -0400 Received: from [192.168.0.41] (pool-138-89-69-211.mad.east.verizon.net [138.89.69.211]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.6/8.13.0) with ESMTP id k331An0f015704 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 2 Apr 2006 21:10:49 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v746.3) 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: Sun, 2 Apr 2006 21:10:51 -0400 X-Mailer: Apple Mail (2.746.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Ecrit] draft-ietf-ecrit-service-urn-02 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: , Errors-To: ecrit-bounces@ietf.org I have submitted a new edition of the service URN draft to the I-D editor. Until it appears in the archives, you can find versions at http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service- urn-02.html http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service- urn-02.txt The major changes are based on discussions in Dallas and the mailing list: - removed the Accept-Contact mechanism; as discussed, the general idea is that the request-URI will be used as the marker for emergency calls and the actual PSAP URL will be inserted after the mapping has been performed via preloaded Route headers. - simplified the mapping mechanism using S-NAPTR. I think this is now reasonably clean, while allowing a separate service resolution mechanism for each top-level service in each domain. The discovery of servers for LoST, for example, will obviously be discussed in the LoST document. I took the mailing list consensus to be that we wanted this extra level of indirection. - addressed Jonathan's comments; some issues had become moot due to the removal of the Accept-Contact header and the rewriting of the NAPTR mechanism. I believe that the precise description of how this works in SIP, e.g., the use of Route headers, belongs in the phone BCP, as it is fairly SIP-specific and does not define a new protocol mechanism but rather a "best current practice". The draft is a bit fuzzy on how the NAPTR domain is determined. Currently, the draft simply talks about the "home domain" of the entity doing the resolution. I made this as a pragmatic choice, as it avoids having to define some kind of globally-valid NAPTR label. The phone BCP could discuss alternatives, such as using DHCP (to obtain the preference of the network provider) or SIP configuration (VSP). Comments are appreciated. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 05 08:08:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR6oa-00013m-LR; Wed, 05 Apr 2006 08:08:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQuLa-0005Y6-JN; Tue, 04 Apr 2006 18:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQuLa-00057A-3s; Tue, 04 Apr 2006 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k34Mo1vP029726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Apr 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FQuLZ-0001ZQ-Jn; Tue, 04 Apr 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 04 Apr 2006 18:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-Mailman-Approved-At: Wed, 05 Apr 2006 08:08:47 -0400 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-service-urn-02.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: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : A Uniform Resource Name (URN) for Services Author(s) : H. Schulzrinne Filename : draft-ietf-ecrit-service-urn-02.txt Pages : 13 Date : 2006-4-4 The content of many communication services depend on the context, such as the user's location. We describe a 'service' URN that allows to register such context-dependent services that can be resolved in a distributed manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-02.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-ietf-ecrit-service-urn-02.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-ietf-ecrit-service-urn-02.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-4171811.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-service-urn-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-service-urn-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-4171811.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From ecrit-bounces@ietf.org Wed Apr 05 10:48:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9Iv-0003FH-6f; Wed, 05 Apr 2006 10:48:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9It-0003F9-HV for ecrit@ietf.org; Wed, 05 Apr 2006 10:48:15 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR9It-0001NZ-9O for ecrit@ietf.org; Wed, 05 Apr 2006 10:48:15 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k35ElqBW020890; Wed, 5 Apr 2006 14:47:52 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 10:47:50 -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 Date: Wed, 5 Apr 2006 10:47:46 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-ecrit-service-urn-02 Thread-Index: AcZYv+bPpaF1oz2YTm23huHL8DTQWg== From: "Rosen, Brian" To: "Henning Schulzrinne" , X-OriginalArrivalTime: 05 Apr 2006 14:47:50.0445 (UTC) FILETIME=[E96695D0:01C658BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Subject: [Ecrit] Review of draft-ietf-ecrit-service-urn-02 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: , Errors-To: ecrit-bounces@ietf.org I have reviewed service-urn-02 and have the following comments: A little concerned about 1-800-LAWYER as an example. The problem here is that there is no obvious mechanism to translate the e.164 1-800-LAWYER to the service urn. I suppose someone could propose an enumservice for this purpose, but until they do, we might consider removing this particular example You need a statement that points out the obvious: since the service urn is a protocol labeling mechanism, it has no i18n implications. My biggest problem is the DDDS stuff (section 3). There is no discussion of what domain you query the DNS for. This is an area well worked over by other emergency stuff, and 'fragile' because what you normally want is your "local" (as in access network) domain, and it's not all that easy to determine what that is. Read the HELD and LCP documents, and the discussion about this point. I think this document needs to handle this. I think whatever it says is likely to have to be the same as any other similar mechanism in the milieu (for example, how you find your LoST server). We need to decide what this text is, and copy it into all the relevant documents. =20 I am confused by the "Validation Mechanism" in Section 2. First of all the word "resource" is used here for the first time. I am assuming it has the meaning of 3406 resource. The real problem is that the section in 3406 that talks about validity defines it as "is there a valid service" rather than "is the service available". Using the DDDS mechanism would only tell you if a service was available (in the sense of configured, rather than in the sense of functioning) within a domain. While I think you could keep most of this text if you qualify it, I think the actual answer is that the validation mechanism is IANA assignment. I think Section 4.2 for the registration of the 3958 Service Tag should be expanded a bit to more formally match the registration requirements of 3958. The document currently calls it a "Service Label" which is incorrect. I think you should be more clear that effectively, you are creating a subregistry under SURN, but the contents of that subregistry is the same as the registry you create in 4.1 Consider the following issue: there is sos.police. In most areas of the world, there are several kinds of police services that are related to the hierarchy of the jurisdictions. In North America, you typically have local police, county police, state police and national police (FBI). Some other services have this characteristic. Do we want to allow a subservice under police? An alternative is to allow a query to a higher level civic address (a LoST query to a1=3Dus, a2=3Dpa for sos.police gets you the Pennsylvania State Police). That wouldn't work for a geo query. Appendix A starts out badly. I think this is some kind of copy/paste problem. I think you need to start saying "A number of alternatives were considered in developing this solution. "sos" SIP reserved user name Using a SIP uri of the form "sos@example.com" follows the convention of RFC 2142[8] Nits: Section 1, missing space in "United States),telephone" Section 1, bad English in "allows to define". Probably "allows us to define" Section 1, English could be better: "Also, such identifiers allow to delegate routing decisions to third parties and mark certain" could be "allow delegation of routing decisions to third parties and marking certain.." Section 1, bad English: " URN allows to identify services". Should probably be "URN identifies services" In Section 2, the ABNF attempts to limit the top level name to 27 characters by using *25let-dig-hyp In Section 2, under "Process of Identifier Assignment" the reference to IANA Considerations needs "in" in front of it (esp look at how the HTML version reads). Actually, I note that IANA Considerations is Section 4, and note how the references in Process of Identifier Assignment is made vs "Identifier Uniqueness Considerations" above it. In Section 2 " Identifier persistence considerations" spelling error in=20 "The 'service' URN for the same service is expected to be persisent". Should be persistent. In Section 2, "Process for Identifier Resolution" references NAPTR rather than S-NAPTR. This might be okay (an S-NAPTR is sort of a NAPTR, right?) but think about it. In Section 2, "Conformance with URN Syntax" you say there are none, but Section 4.1 says top level names must be less than 27 characters. The ABNF restricts it. Section 4.3, which/that confusion in " The generic 'sos' service reaches a public safety answering point (PSAP), that" If these problems were addressed, I would think this document could be WGLC'd Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 06 05:17:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQcO-0007nF-QJ; Thu, 06 Apr 2006 05:17:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQcO-0007nA-4X for ecrit@ietf.org; Thu, 06 Apr 2006 05:17:32 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRQcM-00087a-Ne for ecrit@ietf.org; Thu, 06 Apr 2006 05:17:32 -0400 Received: (qmail invoked by alias); 06 Apr 2006 09:17:21 -0000 Received: from ip-80-226-152-31.vodafone-net.de (EHLO [10.227.148.205]) [80.226.152.31] by mail.gmx.net (mp020) with SMTP; 06 Apr 2006 11:17:21 +0200 X-Authenticated: #29516787 Message-ID: <4434DC82.1040609@gmx.net> Date: Thu, 06 Apr 2006 11:16:50 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) 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-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ecrit] ECRIT Requirements Draft WGLC Status 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: , Errors-To: ecrit-bounces@ietf.org Hi all, during the WGLC for we have received a number of comments. Roger has addressed editorial comments already with the most recent draft submission () We have added the open issues to the issue tracker and Roger has already worked on the resolution of them. Please find them at: http://www.ietf-ecrit.org:8080/ecrit-req/ Thanks Roger for the quick reaction. Please take a look at the raised issues. After we resolved all open issues there will be another draft version and then we are restarting a short WGLC. We think that this is necessary given the modifications the document has seen. Ciao Hannes & Marc PS: Henning did a serious review based on the previous draft version. Please find it at: http://www.ietf-ecrit.org/TEMP/draft-ietf-ecrit-requirements-05_review.pdf Note that the editorial comments have been addressed already with the most recent draft update. The technical issues have been addressed to the issue tracker. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 06 08:46:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTsI-00018Q-7D; Thu, 06 Apr 2006 08:46:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTsF-00018D-VI; Thu, 06 Apr 2006 08:46:07 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRTsF-00073q-PX; Thu, 06 Apr 2006 08:46:07 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 06 Apr 2006 08:45:08 -0400 id 0158819E.44350D54.00004C34 Message-ID: <44350D93.7070509@hxr.us> Date: Thu, 06 Apr 2006 08:46:11 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5 (Windows/20051201) 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-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Ecrit] static location on a mobile device 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: , Errors-To: ecrit-bounces@ietf.org [ This is being cross-posted to both GEOPRIV and ECRIT. The use case is for emergency services but it deals with location. ] Despite our best efforts, I believe in less than ideal situations (and there will be many) we may end up with mobile devices configured with static locations. Here is the scenario as the world works today in some situations: A user signs up for voip service. In the process of getting voip service, their location is determined (either by asking the user or some database lookup). This location is based on the endpoint of the users broadband connection. Now, the user takes the device associated with that location to his friends house. If a call is placed, the location conveyed will be different than the location of the actual device. This is simply a fact of life. It will happen. I was thinking that it would be a good thing if the location could be conveyed to the PSAP with the following note, "This location has been configured statically, but the device may have been moved." Naturally, an actual english message is not the best thing... a well-known tag would work better the world over. Before I jump into the solution space, I was wondering what people thought of the idea. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 06 09:09:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRUFJ-0003MD-T8; Thu, 06 Apr 2006 09:09:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRUFH-0003Ls-Qc; Thu, 06 Apr 2006 09:09:55 -0400 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.43) id 1FRUFE-0007nM-PX; Thu, 06 Apr 2006 09:09:55 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 06 Apr 2006 06:09:52 -0700 X-IronPort-AV: i="4.04,93,1144047600"; d="scan'208"; a="319123782:sNHT26218352" 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 k36D9qw1005898; Thu, 6 Apr 2006 06:09:52 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Apr 2006 06:09:52 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Apr 2006 06:09:51 -0700 From: "Marc Linsner" To: "'Andrew Newton'" , , Date: Thu, 6 Apr 2006 09:09:49 -0400 Message-ID: <004401c6597b$6310c250$1f0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZZeBiUyUS5+uoNQ1ypFV5kD1vwHQAAs9yA In-Reply-To: <44350D93.7070509@hxr.us> X-OriginalArrivalTime: 06 Apr 2006 13:09:51.0516 (UTC) FILETIME=[63B2F5C0:01C6597B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Subject: [Ecrit] RE: [Geopriv] static location on a mobile device 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: , Errors-To: ecrit-bounces@ietf.org Obviously the use case is valid. Are you suggesting that the 'Manual' pidf-lo method is not sufficient to cover this use case? -Marc- > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, April 06, 2006 8:46 AM > To: geopriv@ietf.org; ecrit@ietf.org > Subject: [Geopriv] static location on a mobile device > > [ This is being cross-posted to both GEOPRIV and ECRIT. The > use case is for emergency services but it deals with location. ] > > > Despite our best efforts, I believe in less than ideal > situations (and > there will be many) we may end up with mobile devices configured with > static locations. Here is the scenario as the world works > today in some > situations: > > A user signs up for voip service. In the process of getting voip > service, their location is determined (either by asking the > user or some > database lookup). This location is based on the endpoint of > the users > broadband connection. > Now, the user takes the device associated with that > location to his > friends house. If a call is placed, the location conveyed will be > different than the location of the actual device. > > This is simply a fact of life. It will happen. I was > thinking that it > would be a good thing if the location could be conveyed to > the PSAP with > the following note, "This location has been configured > statically, but > the device may have been moved." Naturally, an actual > english message > is not the best thing... a well-known tag would work better > the world over. > > Before I jump into the solution space, I was wondering what people > thought of the idea. > > -andy > > > > _______________________________________________ > 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 Thu Apr 06 10:23:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVOh-00008K-I7; Thu, 06 Apr 2006 10:23:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVOg-00008F-4G for ecrit@ietf.org; Thu, 06 Apr 2006 10:23:42 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRVOe-0001e8-Mk for ecrit@ietf.org; Thu, 06 Apr 2006 10:23:42 -0400 Received: (qmail invoked by alias); 06 Apr 2006 14:23:39 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp017) with SMTP; 06 Apr 2006 16:23:39 +0200 X-Authenticated: #29516787 Message-ID: <44352464.8020002@gmx.net> Date: Thu, 06 Apr 2006 16:23:32 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) 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-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ecrit] ECRIT Security Threats Draft Status 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: , Errors-To: ecrit-bounces@ietf.org Hi all, following the discussions at the last IETF meeting here is a short status report regarding . Tom had two modifications in mind: a) During the meeting we concluded that the requirements language was not quite right in all places. b) Steven Kent raised a security aspect to the subject regarding the ESRP using a mapping server subject to a business arrangement. Tom is working on a draft update. Thanks Tom! After we see the new draft we should think about a WGLC for this document as well. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 06 10:25:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVQr-0000LG-7G; Thu, 06 Apr 2006 10:25:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVN0-0008Vv-HD; Thu, 06 Apr 2006 10:21:58 -0400 Received: from [65.67.130.186] (helo=911.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRVN0-0001af-5D; Thu, 06 Apr 2006 10:21:58 -0400 X-SEF-Processed: 5_0_0_816__2006_04_06_09_23_26 Received: from Unknown [192.168.6.230] by mail1.911.org - SurfControl E-mail Filter (5.0.1); Thu, 06 Apr 2006 09:23:26 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Apr 2006 09:21:56 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] static location on a mobile device Thread-Index: AcZZeBiUyUS5+uoNQ1ypFV5kD1vwHQAAs9yAAAJ9M2A= From: "Marc Berryman" To: "Marc Linsner" , "Andrew Newton" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-Mailman-Approved-At: Thu, 06 Apr 2006 10:25:55 -0400 Cc: Subject: [Ecrit] RE: [Geopriv] static location on a mobile device 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: , Errors-To: ecrit-bounces@ietf.org In the best of all worlds, the mobile device would "know" it has been moved and request the location information be updated (either by manual update or obtaining the location from the new connection point e.g. wiremap). Of course this may would be the best case and not necessarily the common case.=20 While it is out of the scope of this WG, we need to make sure there is a consumer education / awareness aspect so the end users will know this may happen, and to update their location every time they move. Marc B -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com]=20 Sent: Thursday, April 06, 2006 8:10 AM To: 'Andrew Newton'; geopriv@ietf.org; ecrit@ietf.org Subject: RE: [Geopriv] static location on a mobile device Obviously the use case is valid. Are you suggesting that the 'Manual' pidf-lo method is not sufficient to cover this use case? -Marc- > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > Sent: Thursday, April 06, 2006 8:46 AM > To: geopriv@ietf.org; ecrit@ietf.org > Subject: [Geopriv] static location on a mobile device >=20 > [ This is being cross-posted to both GEOPRIV and ECRIT. The=20 > use case is for emergency services but it deals with location. ] >=20 >=20 > Despite our best efforts, I believe in less than ideal=20 > situations (and=20 > there will be many) we may end up with mobile devices configured with=20 > static locations. Here is the scenario as the world works=20 > today in some=20 > situations: >=20 > A user signs up for voip service. In the process of getting voip=20 > service, their location is determined (either by asking the=20 > user or some=20 > database lookup). This location is based on the endpoint of=20 > the users=20 > broadband connection. > Now, the user takes the device associated with that=20 > location to his=20 > friends house. If a call is placed, the location conveyed will be=20 > different than the location of the actual device. >=20 > This is simply a fact of life. It will happen. I was=20 > thinking that it=20 > would be a good thing if the location could be conveyed to=20 > the PSAP with=20 > the following note, "This location has been configured=20 > statically, but=20 > the device may have been moved." Naturally, an actual=20 > english message=20 > is not the best thing... a well-known tag would work better=20 > the world over. >=20 > Before I jump into the solution space, I was wondering what people=20 > thought of the idea. >=20 > -andy >=20 >=20 >=20 > _______________________________________________ > 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 Thu Apr 06 10:31:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVVl-0000sr-Dl; Thu, 06 Apr 2006 10:31:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVVk-0000rL-2F; Thu, 06 Apr 2006 10:31:00 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRVVi-0001n6-Gv; Thu, 06 Apr 2006 10:31:00 -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 Date: Thu, 6 Apr 2006 16:35:00 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4EC5@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] static location on a mobile device Thread-Index: AcZZeBiUyUS5+uoNQ1ypFV5kD1vwHQAAs9yAAAJ9M2AAAGkqoA== From: "Stastny Richard" To: "Marc Berryman" , "Marc Linsner" , "Andrew Newton" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Subject: [Ecrit] RE: [Geopriv] static location on a mobile device 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: , Errors-To: ecrit-bounces@ietf.org I consider a tag or warning useful not only with static configuration, but also with dynamic configuration Brian is proposing in his I-D ecrit-phonebcp, that a device immediately gets his location at attachment time, and each time the device is moved The device may detect this by some means, e.g. change of IP address or change of hotspot, etc. What may happen here is that the device is not able to retrieve the location at this time, so the location information may be tagged as out-dated until a new location information may be retrieved The same could be done with manual configuration, if the device detects a potential change in location. Richard > -----Original Message----- > From: Marc Berryman [mailto:MBerryman@911.org] > Sent: Thursday, April 06, 2006 4:22 PM > To: Marc Linsner; Andrew Newton; geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] static location on a mobile device >=20 > In the best of all worlds, the mobile device would "know" it has been > moved and request the location information be updated (either by manual > update or obtaining the location from the new connection point e.g. > wiremap). Of course this may would be the best case and not necessarily > the common case. >=20 > While it is out of the scope of this WG, we need to make sure there is a > consumer education / awareness aspect so the end users will know this > may happen, and to update their location every time they move. >=20 > Marc B >=20 > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Thursday, April 06, 2006 8:10 AM > To: 'Andrew Newton'; geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] static location on a mobile device >=20 > Obviously the use case is valid. >=20 > Are you suggesting that the 'Manual' pidf-lo method is not sufficient to > cover this use case? >=20 > -Marc- >=20 > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Thursday, April 06, 2006 8:46 AM > > To: geopriv@ietf.org; ecrit@ietf.org > > Subject: [Geopriv] static location on a mobile device > > > > [ This is being cross-posted to both GEOPRIV and ECRIT. The > > use case is for emergency services but it deals with location. ] > > > > > > Despite our best efforts, I believe in less than ideal > > situations (and > > there will be many) we may end up with mobile devices configured with > > static locations. Here is the scenario as the world works > > today in some > > situations: > > > > A user signs up for voip service. In the process of getting voip > > service, their location is determined (either by asking the > > user or some > > database lookup). This location is based on the endpoint of > > the users > > broadband connection. > > Now, the user takes the device associated with that > > location to his > > friends house. If a call is placed, the location conveyed will be > > different than the location of the actual device. > > > > This is simply a fact of life. It will happen. I was > > thinking that it > > would be a good thing if the location could be conveyed to > > the PSAP with > > the following note, "This location has been configured > > statically, but > > the device may have been moved." Naturally, an actual > > english message > > is not the best thing... a well-known tag would work better > > the world over. > > > > Before I jump into the solution space, I was wondering what people > > thought of the idea. > > > > -andy > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 >=20 > _______________________________________________ > 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 Thu Apr 06 11:30:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWQp-0007G5-Eo; Thu, 06 Apr 2006 11:29:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWQn-000712-Ak; Thu, 06 Apr 2006 11:29:57 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRWQn-0004Mu-1Z; Thu, 06 Apr 2006 11:29:57 -0400 Received: from lion.cs.columbia.edu (IDENT:zkxzX+t7Fdd8h7MBt7cPj0E/kdAlW9+i@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k36FTbcL024367 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 6 Apr 2006 11:29:37 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k36FTYjN021311 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 Apr 2006 11:29:37 -0400 Message-ID: <443533D9.2020702@cs.columbia.edu> Date: Thu, 06 Apr 2006 11:29:29 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Marc Berryman References: 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_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: geopriv@ietf.org, ecrit@ietf.org Subject: [Ecrit] Re: [Geopriv] static location on a mobile device 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: , Errors-To: ecrit-bounces@ietf.org This is fairly easy to determine automatically, as a move almost always implies a change in (public) IP address or, at least, a change in the 802.11 AP address. For wired devices in large-scale enterprise LANs, loss of Ethernet carrier is a good indication, although with false positives. Marc Berryman wrote: > In the best of all worlds, the mobile device would "know" it has been > moved and request the location information be updated (either by manual > update or obtaining the location from the new connection point e.g. > wiremap). Of course this may would be the best case and not necessarily > the common case. > > While it is out of the scope of this WG, we need to make sure there is a > consumer education / awareness aspect so the end users will know this > may happen, and to update their location every time they move. > > Marc B > > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Thursday, April 06, 2006 8:10 AM > To: 'Andrew Newton'; geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] static location on a mobile device > > Obviously the use case is valid. > > Are you suggesting that the 'Manual' pidf-lo method is not sufficient to > cover this use case? > > -Marc- > >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Thursday, April 06, 2006 8:46 AM >> To: geopriv@ietf.org; ecrit@ietf.org >> Subject: [Geopriv] static location on a mobile device >> >> [ This is being cross-posted to both GEOPRIV and ECRIT. The >> use case is for emergency services but it deals with location. ] >> >> >> Despite our best efforts, I believe in less than ideal >> situations (and >> there will be many) we may end up with mobile devices configured with >> static locations. Here is the scenario as the world works >> today in some >> situations: >> >> A user signs up for voip service. In the process of getting voip >> service, their location is determined (either by asking the >> user or some >> database lookup). This location is based on the endpoint of >> the users >> broadband connection. >> Now, the user takes the device associated with that >> location to his >> friends house. If a call is placed, the location conveyed will be >> different than the location of the actual device. >> >> This is simply a fact of life. It will happen. I was >> thinking that it >> would be a good thing if the location could be conveyed to >> the PSAP with >> the following note, "This location has been configured >> statically, but >> the device may have been moved." Naturally, an actual >> english message >> is not the best thing... a well-known tag would work better >> the world over. >> >> Before I jump into the solution space, I was wondering what people >> thought of the idea. >> >> -andy >> >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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 Thu Apr 06 12:10:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRX3n-0007jL-NO; Thu, 06 Apr 2006 12:10:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRX3l-0007ir-UN; Thu, 06 Apr 2006 12:10:13 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRX3k-00069N-OA; Thu, 06 Apr 2006 12:10:13 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 06 Apr 2006 12:09:13 -0400 id 01588162.44353D2A.00006FD7 Message-ID: <44353D69.5070305@hxr.us> Date: Thu, 06 Apr 2006 12:10:17 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Marc Linsner References: <004401c6597b$6310c250$1f0d0d0a@amer.cisco.com> In-Reply-To: <004401c6597b$6310c250$1f0d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: geopriv@ietf.org, ecrit@ietf.org Subject: [Ecrit] Re: [Geopriv] static location on a mobile device 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: , Errors-To: ecrit-bounces@ietf.org Marc Linsner wrote: > Obviously the use case is valid. > > Are you suggesting that the 'Manual' pidf-lo method is not sufficient to > cover this use case? > > -Marc- That doesn't necessarily give the whole story. My current tower PC workstation has a UA on it and can be manually configured and is unlikely to be moved. However, those handy dandy wifi phones coming out will almost certainly roam from one location to another. I'm thinking that perhaps when the registration of the device is given, there is also a mobility capability registered with it. So the manual configuration of location in the wifi phones says "this is a mobile device" and my tower PC says "this is an immobile device". -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 06 12:43:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRXZR-0007Oi-3o; Thu, 06 Apr 2006 12:42:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRXZP-0007Oa-S4; Thu, 06 Apr 2006 12:42:55 -0400 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRXZP-0007EA-IE; Thu, 06 Apr 2006 12:42:55 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 06 Apr 2006 09:42:54 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k36Ggsw1002987; Thu, 6 Apr 2006 09:42:54 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Apr 2006 09:42:54 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.20.13]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Apr 2006 09:42:54 -0700 Message-Id: <4.3.2.7.2.20060406113115.03835cd0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Apr 2006 11:42:51 -0500 To: Andrew Newton , geopriv@ietf.org, ecrit@ietf.org From: "James M. Polk" In-Reply-To: <44350D93.7070509@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 06 Apr 2006 16:42:54.0273 (UTC) FILETIME=[26D0E310:01C65999] X-Spam-Score: 1.8 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Ecrit] Re: [Geopriv] static location on a mobile device 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: , Errors-To: ecrit-bounces@ietf.org At 08:46 AM 4/6/2006 -0400, Andrew Newton wrote: >[ This is being cross-posted to both GEOPRIV and ECRIT. The use case is >for emergency services but it deals with location. ] > > >Despite our best efforts, I believe in less than ideal situations (and >there will be many) we may end up with mobile devices configured with >static locations. Here is the scenario as the world works today in some >situations: > > A user signs up for voip service. In the process of getting voip > service, their location is determined (either by asking the user or some > database lookup). This location is based on the endpoint of the users > broadband connection. One very large VoIP provider asks the customer at service sign-up to enter a street address of where they want any 911 call to be routed "as if they were at that location". This is not a dynamic mapping, and can be anywhere, even a bad address - since there is no verification process. I literally witnessed my friend sign up for this service at CES this past January. His intent is to use this new phone at his home and office (in two different cities in California). I told him it wouldn't be long before he forgets which address he entered, and he asked the rep for the company who replied "just enter whichever one you prefer". hmmmm > Now, the user takes the device associated with that location to his > friends house. If a call is placed, the location conveyed will be > different than the location of the actual device. > >This is simply a fact of life. It will happen. "...is..." >-andy >_______________________________________________ >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 Thu Apr 06 13:00:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRXq6-0006ly-Kj; Thu, 06 Apr 2006 13:00:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRXq5-0006ll-PD; Thu, 06 Apr 2006 13:00:09 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRXq5-0007bi-FF; Thu, 06 Apr 2006 13:00:09 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FRXpx-0002dG-Oo; Thu, 06 Apr 2006 12:00:02 -0500 From: "Brian Rosen" To: "'James M. Polk'" , "'Andrew Newton'" , , Subject: RE: [Ecrit] Re: [Geopriv] static location on a mobile device Date: Thu, 6 Apr 2006 13:00:05 -0400 Message-ID: <022001c6599b$8f05e910$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4.3.2.7.2.20060406113115.03835cd0@email.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZmShwrPMf5itVToiZixo70MB/SQAAWA6g X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We call this "self reported location". Right now, it's the only thing we have. We are trying to specify, and then deploy "automatic location determination" which doesn't ask the user anything and works automatically. Self reported location doesn't work. We know that. We know there will be corner cases in every environment where automatic location fails. Probably, most vendors will provide some kind of an escape mechanism, if only to avoid liability issues ("I TOLD them I had run 10000' of wire and my phone was not at 123 Main, but at 136 Main, but they didn't do anything and my son choked and the ambulance went to the wrong location"). We need a way for the carrier to mark that as being self reported so that the PSAP knows what has happened and the liability issues are kept straight. So, SOME form of self reported location will be needed, but for 99.9999% of the cases, it won't be used. Brian -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Thursday, April 06, 2006 12:43 PM To: Andrew Newton; geopriv@ietf.org; ecrit@ietf.org Subject: [Ecrit] Re: [Geopriv] static location on a mobile device At 08:46 AM 4/6/2006 -0400, Andrew Newton wrote: >[ This is being cross-posted to both GEOPRIV and ECRIT. The use case is >for emergency services but it deals with location. ] > > >Despite our best efforts, I believe in less than ideal situations (and >there will be many) we may end up with mobile devices configured with >static locations. Here is the scenario as the world works today in some >situations: > > A user signs up for voip service. In the process of getting voip > service, their location is determined (either by asking the user or some > database lookup). This location is based on the endpoint of the users > broadband connection. One very large VoIP provider asks the customer at service sign-up to enter a street address of where they want any 911 call to be routed "as if they were at that location". This is not a dynamic mapping, and can be anywhere, even a bad address - since there is no verification process. I literally witnessed my friend sign up for this service at CES this past January. His intent is to use this new phone at his home and office (in two different cities in California). I told him it wouldn't be long before he forgets which address he entered, and he asked the rep for the company who replied "just enter whichever one you prefer". hmmmm > Now, the user takes the device associated with that location to his > friends house. If a call is placed, the location conveyed will be > different than the location of the actual device. > >This is simply a fact of life. It will happen. "...is..." >-andy >_______________________________________________ >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 Thu Apr 06 13:53:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRYfp-0004I6-9w; Thu, 06 Apr 2006 13:53:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRYfo-0004Hy-H4; Thu, 06 Apr 2006 13:53:36 -0400 Received: from test-iport-3.cisco.com ([171.71.176.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRYfm-00010t-Ry; Thu, 06 Apr 2006 13:53:36 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 06 Apr 2006 10:53:33 -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 k36HrX7V015605; Thu, 6 Apr 2006 10:53:33 -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); Thu, 6 Apr 2006 10:53:33 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.20.13]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Apr 2006 10:53:32 -0700 Message-Id: <4.3.2.7.2.20060406125136.03857ae8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Apr 2006 12:53:31 -0500 To: br@brianrosen.net, "'Andrew Newton'" , , From: "James M. Polk" Subject: RE: [Ecrit] Re: [Geopriv] static location on a mobile device In-Reply-To: <022001c6599b$8f05e910$640fa8c0@cis.neustar.com> References: <4.3.2.7.2.20060406113115.03835cd0@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 06 Apr 2006 17:53:32.0682 (UTC) FILETIME=[051AC6A0:01C659A3] X-Spam-Score: 1.8 (+) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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: , Errors-To: ecrit-bounces@ietf.org This gets kinda tricky beacuse this is not a validated location (because the user may not be there), even though there is a location that can be validated at this address. I doubt too many will be willing to allow a PIDF-LO to be marked in a way that indicates this. At 01:00 PM 4/6/2006 -0400, Brian Rosen wrote: >We call this "self reported location". Right now, it's the only thing we >have. We are trying to specify, and then deploy "automatic location >determination" which doesn't ask the user anything and works automatically. >Self reported location doesn't work. > >We know that. > >We know there will be corner cases in every environment where automatic >location fails. Probably, most vendors will provide some kind of an escape >mechanism, if only to avoid liability issues ("I TOLD them I had run 10000' >of wire and my phone was not at 123 Main, but at 136 Main, but they didn't >do anything and my son choked and the ambulance went to the wrong >location"). We need a way for the carrier to mark that as being self >reported so that the PSAP knows what has happened and the liability issues >are kept straight. > >So, SOME form of self reported location will be needed, but for 99.9999% of >the cases, it won't be used. > >Brian > > > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Thursday, April 06, 2006 12:43 PM >To: Andrew Newton; geopriv@ietf.org; ecrit@ietf.org >Subject: [Ecrit] Re: [Geopriv] static location on a mobile device > >At 08:46 AM 4/6/2006 -0400, Andrew Newton wrote: > >[ This is being cross-posted to both GEOPRIV and ECRIT. The use case is > >for emergency services but it deals with location. ] > > > > > >Despite our best efforts, I believe in less than ideal situations (and > >there will be many) we may end up with mobile devices configured with > >static locations. Here is the scenario as the world works today in some > >situations: > > > > A user signs up for voip service. In the process of getting voip > > service, their location is determined (either by asking the user or some > > database lookup). This location is based on the endpoint of the users > > broadband connection. > >One very large VoIP provider asks the customer at service sign-up to enter >a street address of where they want any 911 call to be routed "as if they >were at that location". This is not a dynamic mapping, and can be >anywhere, even a bad address - since there is no verification process. > >I literally witnessed my friend sign up for this service at CES this past >January. His intent is to use this new phone at his home and office (in two >different cities in California). I told him it wouldn't be long before he >forgets which address he entered, and he asked the rep for the company who >replied "just enter whichever one you prefer". > >hmmmm > > > Now, the user takes the device associated with that location to his > > friends house. If a call is placed, the location conveyed will be > > different than the location of the actual device. > > > >This is simply a fact of life. It will happen. > >"...is..." > > > >-andy > >_______________________________________________ > >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 > > >_______________________________________________ >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 Thu Apr 06 15:16:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRZxr-0003WZ-R5; Thu, 06 Apr 2006 15:16:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRZxr-0003WE-4o; Thu, 06 Apr 2006 15:16:19 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRZxq-0003vm-PY; Thu, 06 Apr 2006 15:16:19 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k36JGCmS017951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Apr 2006 12:16:13 -0700 Received: from [10.0.1.4] (dhcp-campbell-28.qualcomm.com [129.46.225.88]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k36JGBND005826; Thu, 6 Apr 2006 12:16:12 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <44350D93.7070509@hxr.us> References: <44350D93.7070509@hxr.us> Date: Thu, 6 Apr 2006 12:16:09 -0700 To: Andrew Newton , geopriv@ietf.org, ecrit@ietf.org From: Ted Hardie Subject: Re: [Ecrit] static location on a mobile device Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: , Errors-To: ecrit-bounces@ietf.org At 8:46 AM -0400 4/6/06, Andrew Newton wrote: >Despite our best efforts, I believe in less than ideal situations (and there will be many) we may end up with mobile devices configured with static locations. Here is the scenario as the world works today in some situations: > > A user signs up for voip service. In the process of getting voip service, their location is determined (either by asking the user or some database lookup). This location is based on the endpoint of the users broadband connection. > Now, the user takes the device associated with that location to his friends house. If a call is placed, the location conveyed will be different than the location of the actual device. Not to be pedantic, but I think it is common to use the term "nomadic" rather than "mobile" for use cases like this. This is because the use case requires the system to handle service from multiple, discrete locations, but does not require it to handle the topologies of MobileIP or the hand-off problems. I agree that this will likely happen; I'm not sure I would call these static locations (since they could be presumably be changed manually in the same way the were originally entered or the database updated), but it's clear that the need for update is nowhere being triggered or acted upon. Are you thinking of a message to this effect that is not part of the pidf-lo? Or a method carried within the pidf-lo? regards, Ted >This is simply a fact of life. It will happen. I was thinking that it would be a good thing if the location could be conveyed to the PSAP with the following note, "This location has been configured statically, but the device may have been moved." Naturally, an actual english message is not the best thing... a well-known tag would work better the world over. > >Before I jump into the solution space, I was wondering what people thought of the idea. > >-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 Thu Apr 06 15:19:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRa0o-0004G9-Mi; Thu, 06 Apr 2006 15:19:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRa0n-0004G4-NU for ecrit@ietf.org; Thu, 06 Apr 2006 15:19:21 -0400 Received: from mail44.messagelabs.com ([216.82.249.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRa0l-00043G-Lr for ecrit@ietf.org; Thu, 06 Apr 2006 15:19:21 -0400 X-VirusChecked: Checked X-Env-Sender: kamran.aquil@mitretek.org X-Msg-Ref: server-19.tower-44.messagelabs.com!1144351156!17314895!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [66.10.26.57] Received: (qmail 26054 invoked from network); 6 Apr 2006 19:19:16 -0000 Received: from mtk-news1.mitretek.org (HELO mtk-news1.mitretek.org) (66.10.26.57) by server-19.tower-44.messagelabs.com with SMTP; 6 Apr 2006 19:19:16 -0000 Received: from email1.mitretek.org (email1.mitretek.org [172.16.49.40]) by mtk-news1.mitretek.org (8.12.10/8.12.10) with ESMTP id k36JJFQc012708 for ; Thu, 6 Apr 2006 15:19:15 -0400 (EDT) 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 Date: Thu, 6 Apr 2006 15:19:14 -0400 Message-ID: <88C80871CC296F438124F37C5656BDAF010594F2@email1.mitretek.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:[Geopriv] static location on a mobile device Thread-Index: AcZZk1ONQV6hDtkLTbqO0gMba0esUwAGkv/g From: "Aquil, Kamran" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e9051aca6d23a9cf6df09e1ef4738712 Subject: [Ecrit] RE:[Geopriv] static location on a mobile device 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: , Errors-To: ecrit-bounces@ietf.org The dual mode Handset (802.11/Cellular) will be able to carry the same VOIP session with same IP address when handing off between either network. The location change trigger mechanism cannot be based on changing IP address in this scenario. Also the ISP or the access provider is better situated to provide some sort location update trigger based on Pull or Push request instead of ASP/VSP. Kamran=20 -----Original Message----- From: ecrit-request@ietf.org [mailto:ecrit-request@ietf.org]=20 Sent: Thursday, April 06, 2006 12:00 PM To: ecrit@ietf.org Subject: Ecrit Digest, Vol 15, Issue 3 Send Ecrit mailing list submissions to ecrit@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/ecrit or, via email, send a message with subject or body 'help' to ecrit-request@ietf.org You can reach the person managing the list at ecrit-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Ecrit digest..." Today's Topics: 1. ECRIT Requirements Draft WGLC Status (Hannes Tschofenig) 2. static location on a mobile device (Andrew Newton) 3. RE: [Geopriv] static location on a mobile device (Marc Linsner) 4. ECRIT Security Threats Draft Status (Hannes Tschofenig) 5. RE: [Geopriv] static location on a mobile device (Marc Berryman) 6. RE: [Geopriv] static location on a mobile device (Stastny Richard) 7. Re: [Geopriv] static location on a mobile device (Henning Schulzrinne) ---------------------------------------------------------------------- Message: 1 Date: Thu, 06 Apr 2006 11:16:50 +0200 From: Hannes Tschofenig Subject: [Ecrit] ECRIT Requirements Draft WGLC Status To: ecrit@ietf.org Message-ID: <4434DC82.1040609@gmx.net> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Hi all, during the WGLC for we have received a number of comments. Roger has addressed editorial comments already with the most recent draft submission () We have added the open issues to the issue tracker and Roger has already worked on the resolution of them. Please find them at: http://www.ietf-ecrit.org:8080/ecrit-req/ Thanks Roger for the quick reaction. Please take a look at the raised issues. After we resolved all open issues there will be another draft version and then we are restarting a short WGLC. We think that this is necessary given the modifications the document has seen. Ciao Hannes & Marc PS: Henning did a serious review based on the previous draft version.=20 Please find it at:=20 http://www.ietf-ecrit.org/TEMP/draft-ietf-ecrit-requirements-05_review.p df Note that the editorial comments have been addressed already with the most recent draft update. The technical issues have been addressed to the issue tracker. ------------------------------ Message: 2 Date: Thu, 06 Apr 2006 08:46:11 -0400 From: Andrew Newton Subject: [Ecrit] static location on a mobile device To: geopriv@ietf.org, ecrit@ietf.org Message-ID: <44350D93.7070509@hxr.us> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed [ This is being cross-posted to both GEOPRIV and ECRIT. The use case is for emergency services but it deals with location. ] Despite our best efforts, I believe in less than ideal situations (and=20 there will be many) we may end up with mobile devices configured with=20 static locations. Here is the scenario as the world works today in some situations: A user signs up for voip service. In the process of getting voip=20 service, their location is determined (either by asking the user or some database lookup). This location is based on the endpoint of the users=20 broadband connection. Now, the user takes the device associated with that location to his=20 friends house. If a call is placed, the location conveyed will be=20 different than the location of the actual device. This is simply a fact of life. It will happen. I was thinking that it=20 would be a good thing if the location could be conveyed to the PSAP with the following note, "This location has been configured statically, but=20 the device may have been moved." Naturally, an actual english message=20 is not the best thing... a well-known tag would work better the world over. Before I jump into the solution space, I was wondering what people=20 thought of the idea. -andy ------------------------------ Message: 3 Date: Thu, 6 Apr 2006 09:09:49 -0400 From: "Marc Linsner" Subject: [Ecrit] RE: [Geopriv] static location on a mobile device To: "'Andrew Newton'" , , Message-ID: <004401c6597b$6310c250$1f0d0d0a@amer.cisco.com> Content-Type: text/plain; charset=3D"us-ascii" Obviously the use case is valid. Are you suggesting that the 'Manual' pidf-lo method is not sufficient to cover this use case? -Marc- > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > Sent: Thursday, April 06, 2006 8:46 AM > To: geopriv@ietf.org; ecrit@ietf.org > Subject: [Geopriv] static location on a mobile device >=20 > [ This is being cross-posted to both GEOPRIV and ECRIT. The=20 > use case is for emergency services but it deals with location. ] >=20 >=20 > Despite our best efforts, I believe in less than ideal=20 > situations (and=20 > there will be many) we may end up with mobile devices configured with=20 > static locations. Here is the scenario as the world works=20 > today in some=20 > situations: >=20 > A user signs up for voip service. In the process of getting voip=20 > service, their location is determined (either by asking the=20 > user or some=20 > database lookup). This location is based on the endpoint of=20 > the users=20 > broadband connection. > Now, the user takes the device associated with that=20 > location to his=20 > friends house. If a call is placed, the location conveyed will be=20 > different than the location of the actual device. >=20 > This is simply a fact of life. It will happen. I was=20 > thinking that it=20 > would be a good thing if the location could be conveyed to=20 > the PSAP with=20 > the following note, "This location has been configured=20 > statically, but=20 > the device may have been moved." Naturally, an actual=20 > english message=20 > is not the best thing... a well-known tag would work better=20 > the world over. >=20 > Before I jump into the solution space, I was wondering what people=20 > thought of the idea. >=20 > -andy >=20 >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ------------------------------ Message: 4 Date: Thu, 06 Apr 2006 16:23:32 +0200 From: Hannes Tschofenig Subject: [Ecrit] ECRIT Security Threats Draft Status To: ecrit@ietf.org Message-ID: <44352464.8020002@gmx.net> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Hi all, following the discussions at the last IETF meeting here is a short=20 status report regarding . Tom had two modifications in mind: a) During the meeting we concluded that the requirements language was=20 not quite right in all places. b) Steven Kent raised a security aspect to the subject regarding the=20 ESRP using a mapping server subject to a business arrangement. Tom is working on a draft update. Thanks Tom! After we see the new draft we should think about a WGLC for this=20 document as well. Ciao Hannes ------------------------------ Message: 5 Date: Thu, 6 Apr 2006 09:21:56 -0500 From: "Marc Berryman" Subject: [Ecrit] RE: [Geopriv] static location on a mobile device To: "Marc Linsner" , "Andrew Newton" , , Message-ID: Content-Type: text/plain; charset=3D"US-ASCII" In the best of all worlds, the mobile device would "know" it has been moved and request the location information be updated (either by manual update or obtaining the location from the new connection point e.g. wiremap). Of course this may would be the best case and not necessarily the common case.=20 While it is out of the scope of this WG, we need to make sure there is a consumer education / awareness aspect so the end users will know this may happen, and to update their location every time they move. Marc B -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com]=20 Sent: Thursday, April 06, 2006 8:10 AM To: 'Andrew Newton'; geopriv@ietf.org; ecrit@ietf.org Subject: RE: [Geopriv] static location on a mobile device Obviously the use case is valid. Are you suggesting that the 'Manual' pidf-lo method is not sufficient to cover this use case? -Marc- > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > Sent: Thursday, April 06, 2006 8:46 AM > To: geopriv@ietf.org; ecrit@ietf.org > Subject: [Geopriv] static location on a mobile device >=20 > [ This is being cross-posted to both GEOPRIV and ECRIT. The=20 > use case is for emergency services but it deals with location. ] >=20 >=20 > Despite our best efforts, I believe in less than ideal=20 > situations (and=20 > there will be many) we may end up with mobile devices configured with=20 > static locations. Here is the scenario as the world works=20 > today in some=20 > situations: >=20 > A user signs up for voip service. In the process of getting voip=20 > service, their location is determined (either by asking the=20 > user or some=20 > database lookup). This location is based on the endpoint of=20 > the users=20 > broadband connection. > Now, the user takes the device associated with that=20 > location to his=20 > friends house. If a call is placed, the location conveyed will be=20 > different than the location of the actual device. >=20 > This is simply a fact of life. It will happen. I was=20 > thinking that it=20 > would be a good thing if the location could be conveyed to=20 > the PSAP with=20 > the following note, "This location has been configured=20 > statically, but=20 > the device may have been moved." Naturally, an actual=20 > english message=20 > is not the best thing... a well-known tag would work better=20 > the world over. >=20 > Before I jump into the solution space, I was wondering what people=20 > thought of the idea. >=20 > -andy >=20 >=20 >=20 > _______________________________________________ > 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 ------------------------------ Message: 6 Date: Thu, 6 Apr 2006 16:35:00 +0200 From: "Stastny Richard" Subject: [Ecrit] RE: [Geopriv] static location on a mobile device To: "Marc Berryman" , "Marc Linsner" , "Andrew Newton" , , Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4EC5@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=3D"us-ascii" I consider a tag or warning useful not only with static configuration, but also with dynamic configuration Brian is proposing in his I-D ecrit-phonebcp, that a device immediately gets his location at attachment time, and each time the device is moved The device may detect this by some means, e.g. change of IP address or change of hotspot, etc. What may happen here is that the device is not able to retrieve the location at this time, so the location information may be tagged as out-dated until a new location information may be retrieved The same could be done with manual configuration, if the device detects a potential change in location. Richard > -----Original Message----- > From: Marc Berryman [mailto:MBerryman@911.org] > Sent: Thursday, April 06, 2006 4:22 PM > To: Marc Linsner; Andrew Newton; geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] static location on a mobile device >=20 > In the best of all worlds, the mobile device would "know" it has been > moved and request the location information be updated (either by manual > update or obtaining the location from the new connection point e.g. > wiremap). Of course this may would be the best case and not necessarily > the common case. >=20 > While it is out of the scope of this WG, we need to make sure there is a > consumer education / awareness aspect so the end users will know this > may happen, and to update their location every time they move. >=20 > Marc B >=20 > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Thursday, April 06, 2006 8:10 AM > To: 'Andrew Newton'; geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] static location on a mobile device >=20 > Obviously the use case is valid. >=20 > Are you suggesting that the 'Manual' pidf-lo method is not sufficient to > cover this use case? >=20 > -Marc- >=20 > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Thursday, April 06, 2006 8:46 AM > > To: geopriv@ietf.org; ecrit@ietf.org > > Subject: [Geopriv] static location on a mobile device > > > > [ This is being cross-posted to both GEOPRIV and ECRIT. The > > use case is for emergency services but it deals with location. ] > > > > > > Despite our best efforts, I believe in less than ideal > > situations (and > > there will be many) we may end up with mobile devices configured with > > static locations. Here is the scenario as the world works > > today in some > > situations: > > > > A user signs up for voip service. In the process of getting voip > > service, their location is determined (either by asking the > > user or some > > database lookup). This location is based on the endpoint of > > the users > > broadband connection. > > Now, the user takes the device associated with that > > location to his > > friends house. If a call is placed, the location conveyed will be > > different than the location of the actual device. > > > > This is simply a fact of life. It will happen. I was > > thinking that it > > would be a good thing if the location could be conveyed to > > the PSAP with > > the following note, "This location has been configured > > statically, but > > the device may have been moved." Naturally, an actual > > english message > > is not the best thing... a well-known tag would work better > > the world over. > > > > Before I jump into the solution space, I was wondering what people > > thought of the idea. > > > > -andy > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ------------------------------ Message: 7 Date: Thu, 06 Apr 2006 11:29:29 -0400 From: Henning Schulzrinne Subject: [Ecrit] Re: [Geopriv] static location on a mobile device To: Marc Berryman Cc: geopriv@ietf.org, ecrit@ietf.org Message-ID: <443533D9.2020702@cs.columbia.edu> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed This is fairly easy to determine automatically, as a move almost always=20 implies a change in (public) IP address or, at least, a change in the=20 802.11 AP address. For wired devices in large-scale enterprise LANs,=20 loss of Ethernet carrier is a good indication, although with false=20 positives. Marc Berryman wrote: > In the best of all worlds, the mobile device would "know" it has been > moved and request the location information be updated (either by manual > update or obtaining the location from the new connection point e.g. > wiremap). Of course this may would be the best case and not necessarily > the common case.=20 >=20 > While it is out of the scope of this WG, we need to make sure there is a > consumer education / awareness aspect so the end users will know this > may happen, and to update their location every time they move. >=20 > Marc B >=20 > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com]=20 > Sent: Thursday, April 06, 2006 8:10 AM > To: 'Andrew Newton'; geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] static location on a mobile device >=20 > Obviously the use case is valid. >=20 > Are you suggesting that the 'Manual' pidf-lo method is not sufficient to > cover this use case? >=20 > -Marc- >=20 >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us]=20 >> Sent: Thursday, April 06, 2006 8:46 AM >> To: geopriv@ietf.org; ecrit@ietf.org >> Subject: [Geopriv] static location on a mobile device >> >> [ This is being cross-posted to both GEOPRIV and ECRIT. The=20 >> use case is for emergency services but it deals with location. ] >> >> >> Despite our best efforts, I believe in less than ideal=20 >> situations (and=20 >> there will be many) we may end up with mobile devices configured with >> static locations. Here is the scenario as the world works=20 >> today in some=20 >> situations: >> >> A user signs up for voip service. In the process of getting voip=20 >> service, their location is determined (either by asking the=20 >> user or some=20 >> database lookup). This location is based on the endpoint of=20 >> the users=20 >> broadband connection. >> Now, the user takes the device associated with that=20 >> location to his=20 >> friends house. If a call is placed, the location conveyed will be=20 >> different than the location of the actual device. >> >> This is simply a fact of life. It will happen. I was=20 >> thinking that it=20 >> would be a good thing if the location could be conveyed to=20 >> the PSAP with=20 >> the following note, "This location has been configured=20 >> statically, but=20 >> the device may have been moved." Naturally, an actual=20 >> english message=20 >> is not the best thing... a well-known tag would work better=20 >> the world over. >> >> Before I jump into the solution space, I was wondering what people=20 >> thought of the idea. >> >> -andy >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 >=20 > _______________________________________________ > 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 End of Ecrit Digest, Vol 15, Issue 3 ************************************ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 06 15:25:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRa6m-0008Oq-O8; Thu, 06 Apr 2006 15:25:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRa6l-0008OV-GT; Thu, 06 Apr 2006 15:25:31 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRa6k-0004As-9k; Thu, 06 Apr 2006 15:25:31 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 06 Apr 2006 15:24:31 -0400 id 01588355.44356AEF.000015D0 Message-ID: <44356B2E.6000407@hxr.us> Date: Thu, 06 Apr 2006 15:25:34 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Geopriv] Re: [Ecrit] static location on a mobile device References: <44350D93.7070509@hxr.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: ecrit-bounces@ietf.org Ted Hardie wrote: > Not to be pedantic, but I think it is common to use the term "nomadic" rather than "mobile" for use cases like this. This is because the use case requires the system > to handle service from multiple, discrete locations, but does not require it to > handle the topologies of MobileIP or the hand-off problems. "Nomadic" is fine by me. > I agree that this will likely happen; I'm not sure I would call these static locations > (since they could be presumably be changed manually in the same way the were originally entered or the database updated), but it's clear that the need for update > is nowhere being triggered or acted upon. There are likely two use cases: 1) The UA is configured locally (such as a web page on one of the handy Cisco/Linksys thingys). 2) The VSP inserts location into the call flow because that is the location the customer gave them (either at account setup time or during account maintenance). Obviously, the VSP can be smart enough not to insert location if one already exists, but that is another matter. I doubt many people will remember to manually update location, either on the UA or at the VSP, every time they take it out for a walk. This will be especially true of those nifty wifi handsets. > Are you thinking of a message to this effect that is not part of the pidf-lo? Or a > method carried within the pidf-lo? I don't know. I'd rather get the scenario nailed down and then figure out where to put the info. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 06 15:29:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaAo-0002N2-1P; Thu, 06 Apr 2006 15:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaAn-0002Mw-8b for ecrit@ietf.org; Thu, 06 Apr 2006 15:29:41 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRaAn-0004Qc-3N for ecrit@ietf.org; Thu, 06 Apr 2006 15:29:41 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 06 Apr 2006 15:28:42 -0400 id 01588352.44356BEA.000016C4 Message-ID: <44356C29.9060104@hxr.us> Date: Thu, 06 Apr 2006 15:29:45 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Aquil, Kamran" Subject: Re: [Ecrit] RE:[Geopriv] static location on a mobile device References: <88C80871CC296F438124F37C5656BDAF010594F2@email1.mitretek.org> In-Reply-To: <88C80871CC296F438124F37C5656BDAF010594F2@email1.mitretek.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: ecrit-bounces@ietf.org Aquil, Kamran wrote: > The dual mode Handset (802.11/Cellular) will be able to carry the same > VOIP session with same IP address when handing off between either > network. The location change trigger mechanism cannot be based on > changing IP address in this scenario. Also the ISP or the access > provider is better situated to provide some sort location update trigger > based on Pull or Push request instead of ASP/VSP. I 100% agree. This is just an attempt to cover the less than ideal situation. I'm not advocating the less than ideal situation, just trying to cover the bases when the ideal situation cannot be achieved. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 06 15:41:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaLi-0007oD-H8; Thu, 06 Apr 2006 15:40:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaLg-0007ns-Or; Thu, 06 Apr 2006 15:40:56 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRaLg-0004yU-F9; Thu, 06 Apr 2006 15:40:56 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k36JepQm023388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Apr 2006 12:40:51 -0700 Received: from [10.0.1.4] (dhcp-campbell-28.qualcomm.com [129.46.225.88]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k36Jem5X025219; Thu, 6 Apr 2006 12:40:50 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <44356B2E.6000407@hxr.us> References: <44350D93.7070509@hxr.us> <44356B2E.6000407@hxr.us> Date: Thu, 6 Apr 2006 12:40:47 -0700 To: Andrew Newton From: Ted Hardie Subject: Re: [Geopriv] Re: [Ecrit] static location on a mobile device Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: ecrit-bounces@ietf.org At 3:25 PM -0400 4/6/06, Andrew Newton wrote: > >I doubt many people will remember to manually update location, either on the UA or at the VSP, every time they take it out for a walk. This will be especially true of those nifty wifi handsets. Agreed that people will likely not remember. The wifi sets have a better shot at DHCP location for carrier-owned WiFi (e.g. Starbuck's wifi locations), but probably not for the case where they have simply gone to a neighbor's house. > >>Are you thinking of a message to this effect that is not part of the pidf-lo? Or a >>method carried within the pidf-lo? > >I don't know. I'd rather get the scenario nailed down and then figure out where to put the info. Let me re-phrase this, then. Do you think it will ever be important to say to a PSAP "I picked you based on a location that might be wrong"? If not, I think the other cases covering "This location might be wrong" can always go with the location, which simplifies things a good bit. regards, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 06 15:51:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaVl-0004rs-5A; Thu, 06 Apr 2006 15:51:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaVk-0004rn-48 for ecrit@ietf.org; Thu, 06 Apr 2006 15:51:20 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRaVg-00054o-F2 for ecrit@ietf.org; Thu, 06 Apr 2006 15:51:20 -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] RE:[Geopriv] static location on a mobile device Date: Thu, 6 Apr 2006 21:55:17 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4976@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RE:[Geopriv] static location on a mobile device Thread-Index: AcZZk1ONQV6hDtkLTbqO0gMba0esUwAGkv/gAAFUtJM= From: "Stastny Richard" To: "Aquil, Kamran" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3bef755d9f4ba0b7ac474570b36ffadb 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: , Errors-To: ecrit-bounces@ietf.org >The dual mode Handset (802.11/Cellular) will be able to carry the same >VOIP session with same IP address when handing off between either >network. The location change trigger mechanism cannot be based on >changing IP address in this scenario. =20 I cannot imagine that the UNDERLYING IP address is NOT changing if you hand of between an celllar network and a WiFi hotspot. If I am in the US using GPRS I get an Austrian IP address form my Austrian cellular provider . If I change to a WiFi hotspot in the hotel. I get an = US=20 IP address. =20 Could you please explain what you mean the IP address is not changing? =20 Richard ________________________________ Von: Aquil, Kamran [mailto:kamran.aquil@mitretek.org] Gesendet: Do 06.04.2006 21:19 An: ecrit@ietf.org Betreff: [Ecrit] RE:[Geopriv] static location on a mobile device The dual mode Handset (802.11/Cellular) will be able to carry the same VOIP session with same IP address when handing off between either network. The location change trigger mechanism cannot be based on changing IP address in this scenario. Also the ISP or the access provider is better situated to provide some sort location update trigger based on Pull or Push request instead of ASP/VSP. Kamran -----Original Message----- From: ecrit-request@ietf.org [mailto:ecrit-request@ietf.org] Sent: Thursday, April 06, 2006 12:00 PM To: ecrit@ietf.org Subject: Ecrit Digest, Vol 15, Issue 3 Send Ecrit mailing list submissions to ecrit@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/ecrit or, via email, send a message with subject or body 'help' to ecrit-request@ietf.org You can reach the person managing the list at ecrit-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Ecrit digest..." Today's Topics: 1. ECRIT Requirements Draft WGLC Status (Hannes Tschofenig) 2. static location on a mobile device (Andrew Newton) 3. RE: [Geopriv] static location on a mobile device (Marc Linsner) 4. ECRIT Security Threats Draft Status (Hannes Tschofenig) 5. RE: [Geopriv] static location on a mobile device (Marc Berryman) 6. RE: [Geopriv] static location on a mobile device (Stastny Richard) 7. Re: [Geopriv] static location on a mobile device (Henning Schulzrinne) ---------------------------------------------------------------------- Message: 1 Date: Thu, 06 Apr 2006 11:16:50 +0200 From: Hannes Tschofenig Subject: [Ecrit] ECRIT Requirements Draft WGLC Status To: ecrit@ietf.org Message-ID: <4434DC82.1040609@gmx.net> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Hi all, during the WGLC for we have received a number of comments. Roger has addressed editorial comments already with the most recent draft submission () We have added the open issues to the issue tracker and Roger has already worked on the resolution of them. Please find them at: http://www.ietf-ecrit.org:8080/ecrit-req/ Thanks Roger for the quick reaction. Please take a look at the raised issues. After we resolved all open issues there will be another draft version and then we are restarting a short WGLC. We think that this is necessary given the modifications the document has seen. Ciao Hannes & Marc PS: Henning did a serious review based on the previous draft version. Please find it at: http://www.ietf-ecrit.org/TEMP/draft-ietf-ecrit-requirements-05_review.p df Note that the editorial comments have been addressed already with the most recent draft update. The technical issues have been addressed to the issue tracker. ------------------------------ Message: 2 Date: Thu, 06 Apr 2006 08:46:11 -0400 From: Andrew Newton Subject: [Ecrit] static location on a mobile device To: geopriv@ietf.org, ecrit@ietf.org Message-ID: <44350D93.7070509@hxr.us> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed [ This is being cross-posted to both GEOPRIV and ECRIT. The use case is for emergency services but it deals with location. ] Despite our best efforts, I believe in less than ideal situations (and there will be many) we may end up with mobile devices configured with static locations. Here is the scenario as the world works today in some situations: A user signs up for voip service. In the process of getting voip service, their location is determined (either by asking the user or some database lookup). This location is based on the endpoint of the users broadband connection. Now, the user takes the device associated with that location to his friends house. If a call is placed, the location conveyed will be different than the location of the actual device. This is simply a fact of life. It will happen. I was thinking that it would be a good thing if the location could be conveyed to the PSAP with the following note, "This location has been configured statically, but the device may have been moved." Naturally, an actual english message is not the best thing... a well-known tag would work better the world over. Before I jump into the solution space, I was wondering what people thought of the idea. -andy ------------------------------ Message: 3 Date: Thu, 6 Apr 2006 09:09:49 -0400 From: "Marc Linsner" Subject: [Ecrit] RE: [Geopriv] static location on a mobile device To: "'Andrew Newton'" , , Message-ID: <004401c6597b$6310c250$1f0d0d0a@amer.cisco.com> Content-Type: text/plain; charset=3D"us-ascii" Obviously the use case is valid. Are you suggesting that the 'Manual' pidf-lo method is not sufficient to cover this use case? -Marc- > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, April 06, 2006 8:46 AM > To: geopriv@ietf.org; ecrit@ietf.org > Subject: [Geopriv] static location on a mobile device > > [ This is being cross-posted to both GEOPRIV and ECRIT. The > use case is for emergency services but it deals with location. ] > > > Despite our best efforts, I believe in less than ideal > situations (and > there will be many) we may end up with mobile devices configured with > static locations. Here is the scenario as the world works > today in some > situations: > > A user signs up for voip service. In the process of getting voip > service, their location is determined (either by asking the > user or some > database lookup). This location is based on the endpoint of > the users > broadband connection. > Now, the user takes the device associated with that > location to his > friends house. If a call is placed, the location conveyed will be > different than the location of the actual device. > > This is simply a fact of life. It will happen. I was > thinking that it > would be a good thing if the location could be conveyed to > the PSAP with > the following note, "This location has been configured > statically, but > the device may have been moved." Naturally, an actual > english message > is not the best thing... a well-known tag would work better > the world over. > > Before I jump into the solution space, I was wondering what people > thought of the idea. > > -andy > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ------------------------------ Message: 4 Date: Thu, 06 Apr 2006 16:23:32 +0200 From: Hannes Tschofenig Subject: [Ecrit] ECRIT Security Threats Draft Status To: ecrit@ietf.org Message-ID: <44352464.8020002@gmx.net> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Hi all, following the discussions at the last IETF meeting here is a short status report regarding . Tom had two modifications in mind: a) During the meeting we concluded that the requirements language was not quite right in all places. b) Steven Kent raised a security aspect to the subject regarding the ESRP using a mapping server subject to a business arrangement. Tom is working on a draft update. Thanks Tom! After we see the new draft we should think about a WGLC for this document as well. Ciao Hannes ------------------------------ Message: 5 Date: Thu, 6 Apr 2006 09:21:56 -0500 From: "Marc Berryman" Subject: [Ecrit] RE: [Geopriv] static location on a mobile device To: "Marc Linsner" , "Andrew Newton" , , Message-ID: Content-Type: text/plain; charset=3D"US-ASCII" In the best of all worlds, the mobile device would "know" it has been moved and request the location information be updated (either by manual update or obtaining the location from the new connection point e.g. wiremap). Of course this may would be the best case and not necessarily the common case. While it is out of the scope of this WG, we need to make sure there is a consumer education / awareness aspect so the end users will know this may happen, and to update their location every time they move. Marc B -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Thursday, April 06, 2006 8:10 AM To: 'Andrew Newton'; geopriv@ietf.org; ecrit@ietf.org Subject: RE: [Geopriv] static location on a mobile device Obviously the use case is valid. Are you suggesting that the 'Manual' pidf-lo method is not sufficient to cover this use case? -Marc- > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, April 06, 2006 8:46 AM > To: geopriv@ietf.org; ecrit@ietf.org > Subject: [Geopriv] static location on a mobile device > > [ This is being cross-posted to both GEOPRIV and ECRIT. The > use case is for emergency services but it deals with location. ] > > > Despite our best efforts, I believe in less than ideal > situations (and > there will be many) we may end up with mobile devices configured with > static locations. Here is the scenario as the world works > today in some > situations: > > A user signs up for voip service. In the process of getting voip > service, their location is determined (either by asking the > user or some > database lookup). This location is based on the endpoint of > the users > broadband connection. > Now, the user takes the device associated with that > location to his > friends house. If a call is placed, the location conveyed will be > different than the location of the actual device. > > This is simply a fact of life. It will happen. I was > thinking that it > would be a good thing if the location could be conveyed to > the PSAP with > the following note, "This location has been configured > statically, but > the device may have been moved." Naturally, an actual > english message > is not the best thing... a well-known tag would work better > the world over. > > Before I jump into the solution space, I was wondering what people > thought of the idea. > > -andy > > > > _______________________________________________ > 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 ------------------------------ Message: 6 Date: Thu, 6 Apr 2006 16:35:00 +0200 From: "Stastny Richard" Subject: [Ecrit] RE: [Geopriv] static location on a mobile device To: "Marc Berryman" , "Marc Linsner" , "Andrew Newton" , , Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4EC5@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=3D"us-ascii" I consider a tag or warning useful not only with static configuration, but also with dynamic configuration Brian is proposing in his I-D ecrit-phonebcp, that a device immediately gets his location at attachment time, and each time the device is moved The device may detect this by some means, e.g. change of IP address or change of hotspot, etc. What may happen here is that the device is not able to retrieve the location at this time, so the location information may be tagged as out-dated until a new location information may be retrieved The same could be done with manual configuration, if the device detects a potential change in location. Richard > -----Original Message----- > From: Marc Berryman [mailto:MBerryman@911.org] > Sent: Thursday, April 06, 2006 4:22 PM > To: Marc Linsner; Andrew Newton; geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] static location on a mobile device > > In the best of all worlds, the mobile device would "know" it has been > moved and request the location information be updated (either by manual > update or obtaining the location from the new connection point e.g. > wiremap). Of course this may would be the best case and not necessarily > the common case. > > While it is out of the scope of this WG, we need to make sure there is a > consumer education / awareness aspect so the end users will know this > may happen, and to update their location every time they move. > > Marc B > > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Thursday, April 06, 2006 8:10 AM > To: 'Andrew Newton'; geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] static location on a mobile device > > Obviously the use case is valid. > > Are you suggesting that the 'Manual' pidf-lo method is not sufficient to > cover this use case? > > -Marc- > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Thursday, April 06, 2006 8:46 AM > > To: geopriv@ietf.org; ecrit@ietf.org > > Subject: [Geopriv] static location on a mobile device > > > > [ This is being cross-posted to both GEOPRIV and ECRIT. The > > use case is for emergency services but it deals with location. ] > > > > > > Despite our best efforts, I believe in less than ideal > > situations (and > > there will be many) we may end up with mobile devices configured with > > static locations. Here is the scenario as the world works > > today in some > > situations: > > > > A user signs up for voip service. In the process of getting voip > > service, their location is determined (either by asking the > > user or some > > database lookup). This location is based on the endpoint of > > the users > > broadband connection. > > Now, the user takes the device associated with that > > location to his > > friends house. If a call is placed, the location conveyed will be > > different than the location of the actual device. > > > > This is simply a fact of life. It will happen. I was > > thinking that it > > would be a good thing if the location could be conveyed to > > the PSAP with > > the following note, "This location has been configured > > statically, but > > the device may have been moved." Naturally, an actual > > english message > > is not the best thing... a well-known tag would work better > > the world over. > > > > Before I jump into the solution space, I was wondering what people > > thought of the idea. > > > > -andy > > > > > > > > _______________________________________________ > > 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 > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ------------------------------ Message: 7 Date: Thu, 06 Apr 2006 11:29:29 -0400 From: Henning Schulzrinne Subject: [Ecrit] Re: [Geopriv] static location on a mobile device To: Marc Berryman Cc: geopriv@ietf.org, ecrit@ietf.org Message-ID: <443533D9.2020702@cs.columbia.edu> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed This is fairly easy to determine automatically, as a move almost always implies a change in (public) IP address or, at least, a change in the 802.11 AP address. For wired devices in large-scale enterprise LANs, loss of Ethernet carrier is a good indication, although with false positives. Marc Berryman wrote: > In the best of all worlds, the mobile device would "know" it has been > moved and request the location information be updated (either by manual > update or obtaining the location from the new connection point e.g. > wiremap). Of course this may would be the best case and not necessarily > the common case. > > While it is out of the scope of this WG, we need to make sure there is a > consumer education / awareness aspect so the end users will know this > may happen, and to update their location every time they move. > > Marc B > > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Thursday, April 06, 2006 8:10 AM > To: 'Andrew Newton'; geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] static location on a mobile device > > Obviously the use case is valid. > > Are you suggesting that the 'Manual' pidf-lo method is not sufficient to > cover this use case? > > -Marc- > >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Thursday, April 06, 2006 8:46 AM >> To: geopriv@ietf.org; ecrit@ietf.org >> Subject: [Geopriv] static location on a mobile device >> >> [ This is being cross-posted to both GEOPRIV and ECRIT. The >> use case is for emergency services but it deals with location. ] >> >> >> Despite our best efforts, I believe in less than ideal >> situations (and >> there will be many) we may end up with mobile devices configured with >> static locations. Here is the scenario as the world works >> today in some >> situations: >> >> A user signs up for voip service. In the process of getting voip >> service, their location is determined (either by asking the >> user or some >> database lookup). This location is based on the endpoint of >> the users >> broadband connection. >> Now, the user takes the device associated with that >> location to his >> friends house. If a call is placed, the location conveyed will be >> different than the location of the actual device. >> >> This is simply a fact of life. It will happen. I was >> thinking that it >> would be a good thing if the location could be conveyed to >> the PSAP with >> the following note, "This location has been configured >> statically, but >> the device may have been moved." Naturally, an actual >> english message >> is not the best thing... a well-known tag would work better >> the world over. >> >> Before I jump into the solution space, I was wondering what people >> thought of the idea. >> >> -andy >> >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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 End of Ecrit Digest, Vol 15, Issue 3 ************************************ _______________________________________________ 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 Thu Apr 06 16:21:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRayT-0003Z4-Vs; Thu, 06 Apr 2006 16:21:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRayS-0003Yz-A1 for ecrit@ietf.org; Thu, 06 Apr 2006 16:21:00 -0400 Received: from mail44.messagelabs.com ([216.82.249.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRayP-0006Xc-As for ecrit@ietf.org; Thu, 06 Apr 2006 16:21:00 -0400 X-VirusChecked: Checked X-Env-Sender: kamran.aquil@mitretek.org X-Msg-Ref: server-22.tower-44.messagelabs.com!1144354852!19933476!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [66.10.26.57] Received: (qmail 1616 invoked from network); 6 Apr 2006 20:20:52 -0000 Received: from mtk-news1.mitretek.org (HELO mtk-news1.mitretek.org) (66.10.26.57) by server-22.tower-44.messagelabs.com with SMTP; 6 Apr 2006 20:20:52 -0000 Received: from email1.mitretek.org (email1.mitretek.org [172.16.49.40]) by mtk-news1.mitretek.org (8.12.10/8.12.10) with ESMTP id k36KKpQc021852 for ; Thu, 6 Apr 2006 16:20:51 -0400 (EDT) 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] static location on a mobile device Date: Thu, 6 Apr 2006 16:20:50 -0400 Message-ID: <88C80871CC296F438124F37C5656BDAF01059527@email1.mitretek.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RE:[Geopriv] static location on a mobile device Thread-Index: AcZZk1ONQV6hDtkLTbqO0gMba0esUwAGkv/gAAFUtJMAAH40oA== From: "Aquil, Kamran" To: "Stastny Richard" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1fb4c76a9d88e8fb8b791f63f8d1b07f 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: , Errors-To: ecrit-bounces@ietf.org That depends if the WiFi provider and Cellular are not the same than attaching to different network will require separate IP address. But if both the WIFI and Cellular provider are from the same Carrier (Tmobile - Wifi/GSM). A mechanism can be implemented by the carrier to use the same IP address on the same IP session with help of IMS/call server.=20 Also agreement between different Carrier for Interoperability between networks can also lead to using a set range of IP address that can be used between carriers to maintain session when handing off between WIFI and Cellular Kamran=20 =20 -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, April 06, 2006 3:55 PM To: Aquil, Kamran; ecrit@ietf.org Subject: Re: [Ecrit] RE:[Geopriv] static location on a mobile device >The dual mode Handset (802.11/Cellular) will be able to carry the same=20 >VOIP session with same IP address when handing off between either=20 >network. The location change trigger mechanism cannot be based on=20 >changing IP address in this scenario. =20 I cannot imagine that the UNDERLYING IP address is NOT changing if you hand of between an celllar network and a WiFi hotspot. If I am in the US using GPRS I get an Austrian IP address form my Austrian cellular provider . If I change to a WiFi hotspot in the hotel. I get an US IP address. =20 Could you please explain what you mean the IP address is not changing? =20 Richard ________________________________ Von: Aquil, Kamran [mailto:kamran.aquil@mitretek.org] Gesendet: Do 06.04.2006 21:19 An: ecrit@ietf.org Betreff: [Ecrit] RE:[Geopriv] static location on a mobile device The dual mode Handset (802.11/Cellular) will be able to carry the same VOIP session with same IP address when handing off between either network. The location change trigger mechanism cannot be based on changing IP address in this scenario. Also the ISP or the access provider is better situated to provide some sort location update trigger based on Pull or Push request instead of ASP/VSP. Kamran -----Original Message----- From: ecrit-request@ietf.org [mailto:ecrit-request@ietf.org] Sent: Thursday, April 06, 2006 12:00 PM To: ecrit@ietf.org Subject: Ecrit Digest, Vol 15, Issue 3 Send Ecrit mailing list submissions to ecrit@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/ecrit or, via email, send a message with subject or body 'help' to ecrit-request@ietf.org You can reach the person managing the list at ecrit-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Ecrit digest..." Today's Topics: 1. ECRIT Requirements Draft WGLC Status (Hannes Tschofenig) 2. static location on a mobile device (Andrew Newton) 3. RE: [Geopriv] static location on a mobile device (Marc Linsner) 4. ECRIT Security Threats Draft Status (Hannes Tschofenig) 5. RE: [Geopriv] static location on a mobile device (Marc Berryman) 6. RE: [Geopriv] static location on a mobile device (Stastny Richard) 7. Re: [Geopriv] static location on a mobile device (Henning Schulzrinne) ---------------------------------------------------------------------- Message: 1 Date: Thu, 06 Apr 2006 11:16:50 +0200 From: Hannes Tschofenig Subject: [Ecrit] ECRIT Requirements Draft WGLC Status To: ecrit@ietf.org Message-ID: <4434DC82.1040609@gmx.net> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Hi all, during the WGLC for we have received a number of comments. Roger has addressed editorial comments already with the most recent draft submission () We have added the open issues to the issue tracker and Roger has already worked on the resolution of them. Please find them at: http://www.ietf-ecrit.org:8080/ecrit-req/ Thanks Roger for the quick reaction. Please take a look at the raised issues. After we resolved all open issues there will be another draft version and then we are restarting a short WGLC. We think that this is necessary given the modifications the document has seen. Ciao Hannes & Marc PS: Henning did a serious review based on the previous draft version. Please find it at: http://www.ietf-ecrit.org/TEMP/draft-ietf-ecrit-requirements-05_review.p df Note that the editorial comments have been addressed already with the most recent draft update. The technical issues have been addressed to the issue tracker. ------------------------------ Message: 2 Date: Thu, 06 Apr 2006 08:46:11 -0400 From: Andrew Newton Subject: [Ecrit] static location on a mobile device To: geopriv@ietf.org, ecrit@ietf.org Message-ID: <44350D93.7070509@hxr.us> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed [ This is being cross-posted to both GEOPRIV and ECRIT. The use case is for emergency services but it deals with location. ] Despite our best efforts, I believe in less than ideal situations (and there will be many) we may end up with mobile devices configured with static locations. Here is the scenario as the world works today in some situations: A user signs up for voip service. In the process of getting voip service, their location is determined (either by asking the user or some database lookup). This location is based on the endpoint of the users broadband connection. Now, the user takes the device associated with that location to his friends house. If a call is placed, the location conveyed will be different than the location of the actual device. This is simply a fact of life. It will happen. I was thinking that it would be a good thing if the location could be conveyed to the PSAP with the following note, "This location has been configured statically, but the device may have been moved." Naturally, an actual english message is not the best thing... a well-known tag would work better the world over. Before I jump into the solution space, I was wondering what people thought of the idea. -andy ------------------------------ Message: 3 Date: Thu, 6 Apr 2006 09:09:49 -0400 From: "Marc Linsner" Subject: [Ecrit] RE: [Geopriv] static location on a mobile device To: "'Andrew Newton'" , , Message-ID: <004401c6597b$6310c250$1f0d0d0a@amer.cisco.com> Content-Type: text/plain; charset=3D"us-ascii" Obviously the use case is valid. Are you suggesting that the 'Manual' pidf-lo method is not sufficient to cover this use case? -Marc- > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, April 06, 2006 8:46 AM > To: geopriv@ietf.org; ecrit@ietf.org > Subject: [Geopriv] static location on a mobile device > > [ This is being cross-posted to both GEOPRIV and ECRIT. The use case > is for emergency services but it deals with location. ] > > > Despite our best efforts, I believe in less than ideal situations (and > there will be many) we may end up with mobile devices configured with=20 > static locations. Here is the scenario as the world works today in=20 > some > situations: > > A user signs up for voip service. In the process of getting voip=20 > service, their location is determined (either by asking the user or=20 > some database lookup). This location is based on the endpoint of the=20 > users broadband connection. > Now, the user takes the device associated with that location to his > friends house. If a call is placed, the location conveyed will be=20 > different than the location of the actual device. > > This is simply a fact of life. It will happen. I was thinking that=20 > it would be a good thing if the location could be conveyed to the PSAP > with the following note, "This location has been configured=20 > statically, but the device may have been moved." Naturally, an actual > english message is not the best thing... a well-known tag would work=20 > better the world over. > > Before I jump into the solution space, I was wondering what people=20 > thought of the idea. > > -andy > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ------------------------------ Message: 4 Date: Thu, 06 Apr 2006 16:23:32 +0200 From: Hannes Tschofenig Subject: [Ecrit] ECRIT Security Threats Draft Status To: ecrit@ietf.org Message-ID: <44352464.8020002@gmx.net> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Hi all, following the discussions at the last IETF meeting here is a short status report regarding . Tom had two modifications in mind: a) During the meeting we concluded that the requirements language was not quite right in all places. b) Steven Kent raised a security aspect to the subject regarding the ESRP using a mapping server subject to a business arrangement. Tom is working on a draft update. Thanks Tom! After we see the new draft we should think about a WGLC for this document as well. Ciao Hannes ------------------------------ Message: 5 Date: Thu, 6 Apr 2006 09:21:56 -0500 From: "Marc Berryman" Subject: [Ecrit] RE: [Geopriv] static location on a mobile device To: "Marc Linsner" , "Andrew Newton" , , Message-ID: Content-Type: text/plain; charset=3D"US-ASCII" In the best of all worlds, the mobile device would "know" it has been moved and request the location information be updated (either by manual update or obtaining the location from the new connection point e.g. wiremap). Of course this may would be the best case and not necessarily the common case. While it is out of the scope of this WG, we need to make sure there is a consumer education / awareness aspect so the end users will know this may happen, and to update their location every time they move. Marc B -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Thursday, April 06, 2006 8:10 AM To: 'Andrew Newton'; geopriv@ietf.org; ecrit@ietf.org Subject: RE: [Geopriv] static location on a mobile device Obviously the use case is valid. Are you suggesting that the 'Manual' pidf-lo method is not sufficient to cover this use case? -Marc- > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, April 06, 2006 8:46 AM > To: geopriv@ietf.org; ecrit@ietf.org > Subject: [Geopriv] static location on a mobile device > > [ This is being cross-posted to both GEOPRIV and ECRIT. The use case > is for emergency services but it deals with location. ] > > > Despite our best efforts, I believe in less than ideal situations (and > there will be many) we may end up with mobile devices configured with=20 > static locations. Here is the scenario as the world works today in=20 > some > situations: > > A user signs up for voip service. In the process of getting voip=20 > service, their location is determined (either by asking the user or=20 > some database lookup). This location is based on the endpoint of the=20 > users broadband connection. > Now, the user takes the device associated with that location to his > friends house. If a call is placed, the location conveyed will be=20 > different than the location of the actual device. > > This is simply a fact of life. It will happen. I was thinking that=20 > it would be a good thing if the location could be conveyed to the PSAP > with the following note, "This location has been configured=20 > statically, but the device may have been moved." Naturally, an actual > english message is not the best thing... a well-known tag would work=20 > better the world over. > > Before I jump into the solution space, I was wondering what people=20 > thought of the idea. > > -andy > > > > _______________________________________________ > 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 ------------------------------ Message: 6 Date: Thu, 6 Apr 2006 16:35:00 +0200 From: "Stastny Richard" Subject: [Ecrit] RE: [Geopriv] static location on a mobile device To: "Marc Berryman" , "Marc Linsner" , "Andrew Newton" , , Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4EC5@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=3D"us-ascii" I consider a tag or warning useful not only with static configuration, but also with dynamic configuration Brian is proposing in his I-D ecrit-phonebcp, that a device immediately gets his location at attachment time, and each time the device is moved The device may detect this by some means, e.g. change of IP address or change of hotspot, etc. What may happen here is that the device is not able to retrieve the location at this time, so the location information may be tagged as out-dated until a new location information may be retrieved The same could be done with manual configuration, if the device detects a potential change in location. Richard > -----Original Message----- > From: Marc Berryman [mailto:MBerryman@911.org] > Sent: Thursday, April 06, 2006 4:22 PM > To: Marc Linsner; Andrew Newton; geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] static location on a mobile device > > In the best of all worlds, the mobile device would "know" it has been=20 > moved and request the location information be updated (either by manual > update or obtaining the location from the new connection point e.g. > wiremap). Of course this may would be the best case and not necessarily > the common case. > > While it is out of the scope of this WG, we need to make sure there is a > consumer education / awareness aspect so the end users will know this=20 > may happen, and to update their location every time they move. > > Marc B > > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Thursday, April 06, 2006 8:10 AM > To: 'Andrew Newton'; geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] static location on a mobile device > > Obviously the use case is valid. > > Are you suggesting that the 'Manual' pidf-lo method is not sufficient to > cover this use case? > > -Marc- > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Thursday, April 06, 2006 8:46 AM > > To: geopriv@ietf.org; ecrit@ietf.org > > Subject: [Geopriv] static location on a mobile device > > > > [ This is being cross-posted to both GEOPRIV and ECRIT. The use=20 > > case is for emergency services but it deals with location. ] > > > > > > Despite our best efforts, I believe in less than ideal situations=20 > > (and there will be many) we may end up with mobile devices=20 > > configured with > > static locations. Here is the scenario as the world works today in=20 > > some > > situations: > > > > A user signs up for voip service. In the process of getting voip > > service, their location is determined (either by asking the user or=20 > > some database lookup). This location is based on the endpoint of=20 > > the users broadband connection. > > Now, the user takes the device associated with that location to=20 > > his friends house. If a call is placed, the location conveyed will=20 > > be different than the location of the actual device. > > > > This is simply a fact of life. It will happen. I was thinking that > > it would be a good thing if the location could be conveyed to the=20 > > PSAP with the following note, "This location has been configured=20 > > statically, but the device may have been moved." Naturally, an=20 > > actual english message is not the best thing... a well-known tag=20 > > would work better the world over. > > > > Before I jump into the solution space, I was wondering what people=20 > > thought of the idea. > > > > -andy > > > > > > > > _______________________________________________ > > 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 > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ------------------------------ Message: 7 Date: Thu, 06 Apr 2006 11:29:29 -0400 From: Henning Schulzrinne Subject: [Ecrit] Re: [Geopriv] static location on a mobile device To: Marc Berryman Cc: geopriv@ietf.org, ecrit@ietf.org Message-ID: <443533D9.2020702@cs.columbia.edu> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed This is fairly easy to determine automatically, as a move almost always implies a change in (public) IP address or, at least, a change in the 802.11 AP address. For wired devices in large-scale enterprise LANs, loss of Ethernet carrier is a good indication, although with false positives. Marc Berryman wrote: > In the best of all worlds, the mobile device would "know" it has been=20 > moved and request the location information be updated (either by manual > update or obtaining the location from the new connection point e.g. > wiremap). Of course this may would be the best case and not necessarily > the common case. > > While it is out of the scope of this WG, we need to make sure there is a > consumer education / awareness aspect so the end users will know this=20 > may happen, and to update their location every time they move. > > Marc B > > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Thursday, April 06, 2006 8:10 AM > To: 'Andrew Newton'; geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] static location on a mobile device > > Obviously the use case is valid. > > Are you suggesting that the 'Manual' pidf-lo method is not sufficient to > cover this use case? > > -Marc- > >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Thursday, April 06, 2006 8:46 AM >> To: geopriv@ietf.org; ecrit@ietf.org >> Subject: [Geopriv] static location on a mobile device >> >> [ This is being cross-posted to both GEOPRIV and ECRIT. The use=20 >> case is for emergency services but it deals with location. ] >> >> >> Despite our best efforts, I believe in less than ideal situations=20 >> (and there will be many) we may end up with mobile devices configured >> with >> static locations. Here is the scenario as the world works today in=20 >> some >> situations: >> >> A user signs up for voip service. In the process of getting voip=20 >> service, their location is determined (either by asking the user or=20 >> some database lookup). This location is based on the endpoint of the >> users broadband connection. >> Now, the user takes the device associated with that location to=20 >> his friends house. If a call is placed, the location conveyed will=20 >> be different than the location of the actual device. >> >> This is simply a fact of life. It will happen. I was thinking that=20 >> it would be a good thing if the location could be conveyed to the=20 >> PSAP with the following note, "This location has been configured=20 >> statically, but the device may have been moved." Naturally, an=20 >> actual english message is not the best thing... a well-known tag=20 >> would work better the world over. >> >> Before I jump into the solution space, I was wondering what people=20 >> thought of the idea. >> >> -andy >> >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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 End of Ecrit Digest, Vol 15, Issue 3 ************************************ _______________________________________________ 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 Thu Apr 06 16:29:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRb6y-0007Ut-9F; Thu, 06 Apr 2006 16:29:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRb6w-0007TR-Fo; Thu, 06 Apr 2006 16:29:46 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRb6t-0006gJ-94; Thu, 06 Apr 2006 16:29:46 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 06 Apr 2006 16:28:43 -0400 id 0158835E.443579FB.00002390 Message-ID: <44357A3A.2080801@hxr.us> Date: Thu, 06 Apr 2006 16:29:46 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Geopriv] Re: [Ecrit] static location on a mobile device References: <44350D93.7070509@hxr.us> <44356B2E.6000407@hxr.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: , Errors-To: ecrit-bounces@ietf.org Ted Hardie wrote: > Let me re-phrase this, then. Do you think it will ever be important to say to > a PSAP "I picked you based on a location that might be wrong"? As you would hear from one Alabaman gentlemen to another eying a pretty Georgia girl, "You dance with the one that brung ya." Once you are communicating with the PSAP, they'll let you know what you should do next. > If not, > I think the other cases covering "This location might be wrong" can always > go with the location, which simplifies things a good bit. I was think more along these lines. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 06 19:33:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRdye-0002uA-Od; Thu, 06 Apr 2006 19:33:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRdyc-0002si-VV; Thu, 06 Apr 2006 19:33:22 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRdya-0003p7-Ms; Thu, 06 Apr 2006 19:33:22 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 18:33:20 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 06 Apr 2006 18:33:20 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 18:33:19 -0500 Message-ID: From: "Winterbottom, James" To: "Andrew Newton" , "Ted Hardie" Date: Thu, 6 Apr 2006 18:33:17 -0500 Subject: RE: [Geopriv] Re: [Ecrit] static location on a mobile device 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 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 06 Apr 2006 23:33:19.0388 (UTC) FILETIME=[7C873DC0:01C659D2] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Geopriv] Re: [Ecrit] static location on a mobile device Thread-Index: AcZZuQ2j5qSEIhzcRVaECMa3Ha4MSAAGONqw X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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: , Errors-To: ecrit-bounces@ietf.org So is the suggestion that we introduce a new PIDF-LO tag, for arguments sake let's call it . Or would a new of type "Some-Wild-Guess" be the preferred approach? Either of these would work, the former leads down a potential slippery slope, and the latter kind of stretches the meaning of a bit. Thoughts? > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Friday, 7 April 2006 6:30 AM > To: Ted Hardie > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: Re: [Geopriv] Re: [Ecrit] static location on a mobile device >=20 > Ted Hardie wrote: > > Let me re-phrase this, then. Do you think it will ever be important to > say to > > a PSAP "I picked you based on a location that might be wrong"? >=20 > As you would hear from one Alabaman gentlemen to another eying a pretty > Georgia girl, "You dance with the one that brung ya." Once you are > communicating with the PSAP, they'll let you know what you should do next. >=20 > > If not, > > I think the other cases covering "This location might be wrong" can > always > > go with the location, which simplifies things a good bit. >=20 > I was think more along these lines. >=20 > -andy >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 07 08:53:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqSk-0004qi-Ko; Fri, 07 Apr 2006 08:53:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqSi-0004qV-Uk; Fri, 07 Apr 2006 08:53:16 -0400 Received: from test-iport-3.cisco.com ([171.71.176.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRqSg-0003DZ-Iu; Fri, 07 Apr 2006 08:53:16 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-3.cisco.com with ESMTP; 07 Apr 2006 05:53:14 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k37CrBw5025348; Fri, 7 Apr 2006 05:53:11 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Apr 2006 05:53:11 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Apr 2006 05:53:07 -0700 From: "Marc Linsner" To: "'Winterbottom, James'" , "'Andrew Newton'" , "'Ted Hardie'" Subject: RE: [Geopriv] Re: [Ecrit] static location on a mobile device Date: Fri, 7 Apr 2006 08:53:05 -0400 Message-ID: <005301c65a42$3932f4e0$1f0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZZuQ2j5qSEIhzcRVaECMa3Ha4MSAAGONqwABuqWWA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 07 Apr 2006 12:53:10.0926 (UTC) FILETIME=[39B6CAE0:01C65A42] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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: , Errors-To: ecrit-bounces@ietf.org In the case of emergency call taker, I'm curious as to the expected outcome by exposing the type of network connection and/or device. IMO, the suspicion level of the call taker wrt to accuracy of the provided location is not going to waiver knowing the device is small and lightweight or large and hard-to-carry-around. I believe the call taker will key on the 'manual' method and query the caller as to their current location regardless of the additional information. One possible use of knowing that the device is a desktop machine that was relocated is possibly dispatching a chiropractor.......??? :^) I believe the current pidf-lo method(s) provide enough information. -Marc- > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Thursday, April 06, 2006 7:33 PM > To: Andrew Newton; Ted Hardie > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] Re: [Ecrit] static location on a mobile device > > So is the suggestion that we introduce a new PIDF-LO tag, for > arguments sake let's call it . Or would a new > of type "Some-Wild-Guess" be the preferred approach? > > Either of these would work, the former leads down a potential > slippery slope, and the latter kind of stretches the meaning > of a bit. > > Thoughts? > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Friday, 7 April 2006 6:30 AM > > To: Ted Hardie > > Cc: geopriv@ietf.org; ecrit@ietf.org > > Subject: Re: [Geopriv] Re: [Ecrit] static location on a > mobile device > > > > Ted Hardie wrote: > > > Let me re-phrase this, then. Do you think it will ever > be important > to > > say to > > > a PSAP "I picked you based on a location that might be wrong"? > > > > As you would hear from one Alabaman gentlemen to another eying a > pretty > > Georgia girl, "You dance with the one that brung ya." Once you are > > communicating with the PSAP, they'll let you know what you should do > next. > > > > > If not, > > > I think the other cases covering "This location might be > wrong" can > > always > > > go with the location, which simplifies things a good bit. > > > > I was think more along these lines. > > > > -andy > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > > _______________________________________________ > 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 Fri Apr 07 15:55:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRx34-0005Wm-O2; Fri, 07 Apr 2006 15:55:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRx33-0005Us-2z; Fri, 07 Apr 2006 15:55:13 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRx2z-0003iw-SK; Fri, 07 Apr 2006 15:55:13 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Fri, 07 Apr 2006 15:54:09 -0400 id 015880AF.4436C361.000012F9 Message-ID: <4436C3A0.8070409@hxr.us> Date: Fri, 07 Apr 2006 15:55:12 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Geopriv] Re: [Ecrit] static location on a mobile device References: <005301c65a42$3932f4e0$1f0d0d0a@amer.cisco.com> In-Reply-To: <005301c65a42$3932f4e0$1f0d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: , Errors-To: ecrit-bounces@ietf.org Marc Linsner wrote: > > IMO, the suspicion level of the call taker wrt to accuracy of the provided > location is not going to waiver knowing the device is small and lightweight > or large and hard-to-carry-around. I believe the call taker will key on the > 'manual' method and query the caller as to their current location regardless > of the additional information. One possible use of knowing that the device > is a desktop machine that was relocated is possibly dispatching a > chiropractor.......??? :^) That's what I wanted to know. Is providing this information to the PSAP worth it? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 07 16:47:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRxrB-00019J-Fr; Fri, 07 Apr 2006 16:47:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRxr9-00016N-Ma; Fri, 07 Apr 2006 16:46:59 -0400 Received: from test-iport-3.cisco.com ([171.71.176.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRxr6-0005YN-Ca; Fri, 07 Apr 2006 16:46:59 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-3.cisco.com with ESMTP; 07 Apr 2006 13:46:55 -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 k37KksH1015796; Fri, 7 Apr 2006 13:46:55 -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); Fri, 7 Apr 2006 13:46:55 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Apr 2006 13:46:54 -0700 From: "Marc Linsner" To: "'Andrew Newton'" Subject: RE: [Geopriv] Re: [Ecrit] static location on a mobile device Date: Fri, 7 Apr 2006 16:46:52 -0400 Message-ID: <014d01c65a84$671ca030$1f0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZafS5Aql6SXsAUQ3iRwgqyWrSJVwABvBHg In-Reply-To: <4436C3A0.8070409@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 07 Apr 2006 20:46:54.0621 (UTC) FILETIME=[678E74D0:01C65A84] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: ecrit-bounces@ietf.org > > Marc Linsner wrote: > > > > IMO, the suspicion level of the call taker wrt to accuracy of the > > provided location is not going to waiver knowing the device > is small > > and lightweight or large and hard-to-carry-around. I > believe the call > > taker will key on the 'manual' method and query the caller > as to their > > current location regardless of the additional information. One > > possible use of knowing that the device is a desktop > machine that was > > relocated is possibly dispatching a chiropractor.......??? :^) > > That's what I wanted to know. Is providing this information > to the PSAP worth it? > > -andy If you ask, you'll get as many answers as there are possibilities. Some PSAPs want more information, some think the call taker is distracted with too much information. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 09 12:39:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FScw7-0005i4-Fa; Sun, 09 Apr 2006 12:38:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FScw6-0005hx-3K for ecrit@ietf.org; Sun, 09 Apr 2006 12:38:50 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FScw4-0005Oo-RU for ecrit@ietf.org; Sun, 09 Apr 2006 12:38:50 -0400 Received: from [192.168.0.41] (pool-138-89-69-211.mad.east.verizon.net [138.89.69.211]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k39GclF8023613 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 9 Apr 2006 12:38:48 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E4AAE91-A3A1-4716-813F-278314F76677@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Sun, 9 Apr 2006 12:38:51 -0400 To: "Rosen, Brian" X-Mailer: Apple Mail (2.746.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ecrit@ietf.org Subject: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 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: , Errors-To: ecrit-bounces@ietf.org Brian, thanks for your extensive comments. Partial responses in-line as I work through them; I'll take care of the wording fixes. On Apr 5, 2006, at 10:47 AM, Rosen, Brian wrote: > I have reviewed service-urn-02 and have the following comments: > > In Section 2, the ABNF attempts to limit the top level name to 27 > characters by using *25let-dig-hyp Not sure what you are concerned about here. The definition is let-dig [ *25let-dig-hyp let-dig ] In other words, a string starting and ending with a letter or digit and no more than 25 other characters in between. > > In Section 2, under "Process of Identifier Assignment" the > reference to > IANA Considerations needs "in" in front of it (esp look at how the > HTML > version reads). Actually, I note that IANA Considerations is > Section 4, > and note how the references in Process of Identifier Assignment is > made > vs "Identifier Uniqueness Considerations" above it. I'm not sure I understand. It currently reads (in the TXT version) The process of identifier assignment is described in the IANA Considerations (Section 4). > > In Section 2, "Process for Identifier Resolution" references NAPTR > rather than S-NAPTR. This might be okay (an S-NAPTR is sort of a > NAPTR, > right?) but think about it. I don't know if S-NAPTR is given a separate designation, given that it is a DNS NAPTR record, but I'm happy to follow convention. Since IANA (see the fancy web page at http://test.icann.org/iana.dev/ assignments/s-naptr-parameters.shtml) uses S-NAPTR, I'll follow that lead. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 09 21:22:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSl77-0006fy-Rs; Sun, 09 Apr 2006 21:22:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSl76-0006ft-KD for ecrit@ietf.org; Sun, 09 Apr 2006 21:22:44 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSl76-0007oh-AF for ecrit@ietf.org; Sun, 09 Apr 2006 21:22:44 -0400 Received: from [192.168.0.41] (pool-138-89-69-211.mad.east.verizon.net [138.89.69.211]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3A1Mcgm006003 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 9 Apr 2006 21:22:43 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Sun, 9 Apr 2006 21:22:39 -0400 To: "Rosen, Brian" X-Mailer: Apple Mail (2.746.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: ecrit@ietf.org Subject: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 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: , Errors-To: ecrit-bounces@ietf.org More responses: On Apr 5, 2006, at 10:47 AM, Rosen, Brian wrote: > I have reviewed service-urn-02 and have the following comments: > > A little concerned about 1-800-LAWYER as an example. The problem here > is that there is no obvious mechanism to translate the e.164 > 1-800-LAWYER to the service urn. I suppose someone could propose an > enumservice for this purpose, but until they do, we might consider > removing this particular example Removing lawyers is always a good idea. (The similarity is that dialing this number will get you a lawyer anywhere in the US, with the law office depending on where you're calling from.) I don't quite understand your concern about needing an enum service. > > You need a statement that points out the obvious: since the service > urn > is a protocol labeling mechanism, it has no i18n implications. I'll add an I18N section. > > My biggest problem is the DDDS stuff (section 3). There is no > discussion of what domain you query the DNS for. This is an area well > worked over by other emergency stuff, and 'fragile' because what you > normally want is your "local" (as in access network) domain, and it's I don't think that's really true in general. Why should my access network have better information about these services, particularly if it has no interest in VoIP or emergency calls? I suspect that, initially, the service lookup will be offered by the VSP. They have an interest and obligation to provide the service and can't wait until every last ISP has decided to provide a mapping service. > not all that easy to determine what that is. Read the HELD and LCP > documents, and the discussion about this point. I think this document > needs to handle this. I think whatever it says is likely to have > to be > I didn't see any description of this in draft-winterbottom-geopriv- held-sighting-00. LCP seems to define, besides the usual suspects of manual configuration and DHCP, a broadcast request, not specified further. (This would be essentially a one-off version of SLP.) I think there are at least two plausible approaches to find an ISP- operated domain name, besides DHCP: (1) SLP or Bonjour; the practical problem is that SLP is seeing limited new deployments and Bonjour seems to be under the cloud of being non-IETF-developed (but comparatively widely deployed), with the IETF competitor having been sent back to the WG for a do-over (somebody might know more about this). (2) Inverse DNS: Get public IP address (via STUN, say); obtain domain name (via the usual reverse DNS lookup); use SRV or NAPTR record for that domain. This relies on the user's public IP address having a DNS entry. As far as I can tell, this seems to be almost universally true for residential broadband. (For enterprise users, I suspect that the DHCP solution is easiest.) I had suggested a version of (2). > the same as any other similar mechanism in the milieu (for example, > how > you find your LoST server). We need to decide what this text is, and > copy it into all the relevant documents. Actually, you find your LoST server via this mechanism, since it performs the translation. > > I am confused by the "Validation Mechanism" in Section 2. First of > all > the word "resource" is used here for the first time. I am assuming it > has the meaning of 3406 resource. The real problem is that the > section > in 3406 that talks about validity defines it as "is there a valid > service" rather than "is the service available". Using the DDDS > mechanism would only tell you if a service was available (in the sense > of configured, rather than in the sense of functioning) within a > domain. > While I think you could keep most of this text if you qualify it, I > think the actual answer is that the validation mechanism is IANA > assignment. I agree that this doesn't quite fit; I reread 3406 and 3406 defines validation thusly: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN. [...] This seems to imply that this mechanism would allow to determine whether urn:service:timezone, say, exists or not. This would presumably be done by the lookup mechanism. I'll reword the paragraph to hopefully make the distinction clearer. (more to follow) Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 09 21:43:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSlQv-00058Q-Iv; Sun, 09 Apr 2006 21:43:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSlQu-00056f-6J for ecrit@ietf.org; Sun, 09 Apr 2006 21:43:12 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSlQt-0008WF-Th for ecrit@ietf.org; Sun, 09 Apr 2006 21:43:12 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Apr 2006 20:43:11 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sun, 09 Apr 2006 20:43:10 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Apr 2006 20:43:10 -0500 Message-ID: From: "Thomson, Martin" To: "Henning Schulzrinne" , "Rosen, Brian" Date: Sun, 9 Apr 2006 20:42:03 -0500 Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02, DDDS MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 Apr 2006 01:43:10.0164 (UTC) FILETIME=[1F6E9140:01C65C40] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02, DDDS Thread-Index: AcZcPWRM4zIPBSfoSWe4bXYevry62QAAJsRg X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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: , Content-Type: multipart/mixed; boundary="===============0598797938==" Errors-To: ecrit-bounces@ietf.org --===============0598797938== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SSBsaWtlIHRoZSBpbmNsdXNpb24gb2YgU05BUFRSLCBidXQgdGhlbiwgSSBzdWdnZXN0ZWQgaXQu ICBJIGxpa2UgdGhlIG1ldGhvZCBvZiB1c2luZyB0aGUgdG9wIGxldmVsIHNlcnZpY2UgdGFnIC0g aXQgc2ltcGxpZmllcyB0aGluZ3MgdG8gdGhlIHJpZ2h0IGxldmVsLg0KDQo+ID4gbm90IGFsbCB0 aGF0IGVhc3kgdG8gZGV0ZXJtaW5lIHdoYXQgdGhhdCBpcy4gIFJlYWQgdGhlIEhFTEQgYW5kIExD UA0KPiA+IGRvY3VtZW50cywgYW5kIHRoZSBkaXNjdXNzaW9uIGFib3V0IHRoaXMgcG9pbnQuICBJ IHRoaW5rIHRoaXMgZG9jdW1lbnQNCj4gPiBuZWVkcyB0byBoYW5kbGUgdGhpcy4gIEkgdGhpbmsg d2hhdGV2ZXIgaXQgc2F5cyBpcyBsaWtlbHkgdG8gaGF2ZQ0KPiA+IHRvIGJlDQo+ID4NCj4gDQo+ IEkgZGlkbid0IHNlZSBhbnkgZGVzY3JpcHRpb24gb2YgdGhpcyBpbiBkcmFmdC13aW50ZXJib3R0 b20tZ2VvcHJpdi0NCj4gaGVsZC1zaWdodGluZy0wMC4gTENQIHNlZW1zIHRvIGRlZmluZSwgYmVz aWRlcyB0aGUgdXN1YWwgc3VzcGVjdHMgb2YNCj4gbWFudWFsIGNvbmZpZ3VyYXRpb24gYW5kIERI Q1AsIGEgYnJvYWRjYXN0IHJlcXVlc3QsIG5vdCBzcGVjaWZpZWQNCj4gZnVydGhlci4gKFRoaXMg d291bGQgYmUgZXNzZW50aWFsbHkgYSBvbmUtb2ZmIHZlcnNpb24gb2YgU0xQLikNCg0KVGhlIGRp c2N1c3Npb24gb24gSEVMRCB3YXMgcXVpdGUgaGVhdGVkIGluIHByZXZpb3VzIGluY2FybmF0aW9u cy4NCg0KPiBJIHRoaW5rIHRoZXJlIGFyZSBhdCBsZWFzdCB0d28gcGxhdXNpYmxlIGFwcHJvYWNo ZXMgdG8gZmluZCBhbiBJU1AtDQo+IG9wZXJhdGVkIGRvbWFpbiBuYW1lLCBiZXNpZGVzIERIQ1A6 DQo+IA0KPiAoMSkgU0xQIG9yIEJvbmpvdXI7IHRoZSBwcmFjdGljYWwgcHJvYmxlbSBpcyB0aGF0 IFNMUCBpcyBzZWVpbmcNCj4gbGltaXRlZCBuZXcgZGVwbG95bWVudHMgYW5kIEJvbmpvdXIgc2Vl bXMgdG8gYmUgdW5kZXIgdGhlIGNsb3VkIG9mDQo+IGJlaW5nIG5vbi1JRVRGLWRldmVsb3BlZCAo YnV0IGNvbXBhcmF0aXZlbHkgd2lkZWx5IGRlcGxveWVkKSwgd2l0aA0KPiB0aGUgSUVURiBjb21w ZXRpdG9yIGhhdmluZyBiZWVuIHNlbnQgYmFjayB0byB0aGUgV0cgZm9yIGEgZG8tb3Zlcg0KPiAo c29tZWJvZHkgbWlnaHQga25vdyBtb3JlIGFib3V0IHRoaXMpLg0KPiANCj4gKDIpIEludmVyc2Ug RE5TOiBHZXQgcHVibGljIElQIGFkZHJlc3MgKHZpYSBTVFVOLCBzYXkpOyBvYnRhaW4gZG9tYWlu DQo+IG5hbWUgKHZpYSB0aGUgdXN1YWwgcmV2ZXJzZSBETlMgbG9va3VwKTsgdXNlIFNSViBvciBO QVBUUiByZWNvcmQgZm9yDQo+IHRoYXQgZG9tYWluLiBUaGlzIHJlbGllcyBvbiB0aGUgdXNlcidz IHB1YmxpYyBJUCBhZGRyZXNzIGhhdmluZyBhIEROUw0KPiBlbnRyeS4gQXMgZmFyIGFzIEkgY2Fu IHRlbGwsIHRoaXMgc2VlbXMgdG8gYmUgYWxtb3N0IHVuaXZlcnNhbGx5IHRydWUNCj4gZm9yIHJl c2lkZW50aWFsIGJyb2FkYmFuZC4gKEZvciBlbnRlcnByaXNlIHVzZXJzLCBJIHN1c3BlY3QgdGhh dCB0aGUNCj4gREhDUCBzb2x1dGlvbiBpcyBlYXNpZXN0LikNCj4gDQo+IEkgaGFkIHN1Z2dlc3Rl ZCBhIHZlcnNpb24gb2YgKDIpLg0KDQpXZSBhcmUgbG9va2luZyBhdCB0aGlzIHNvcnQgb2YgZGlz Y292ZXJ5IG1lY2hhbmlzbSBmb3Igc29tZSB0ZXN0cyBoZXJlIGFzIHdlbGwuICBJIHRoaW5rIHRo YXQgaXQgaXMgd29ya2FibGUsIGFuZCB5b3UgY2FuIHdyaXRlIGEgY2xpZW50IHRoYXQgb3JkZXJz IHRoZSBkaWZmZXJlbnQgbWV0aG9kcyBhcHByb3ByaWF0ZWx5Og0KDQogMS4gR2V0IGRvbWFpbiBu YW1lIGZyb20gRE5TDQogMi4gRG8gTkFQVFIvU1JWIGxvb2t1cCBmb3IgdGhhdCBkb21haW4gKHlv dSBjYW4gaXRlcmF0ZSBmcm9tIGxvY2FsIGRvbWFpbnMgdG8gVExELTEgaWYgeW91IGxpa2UpLiAg U3VjY2VzcyA9IFVSTCBvciBIb3N0L1BvcnQgb2Ygc2VydmljZS4NCiAzLiBVc2UgU1RVTi9VUG5Q L290aGVyIHRvIGRldGVybWluZSBwdWJsaWMgSVAgYWRkcmVzcy4NCiA0LiBVc2UgcmV2ZXJzZSBE TlMgdG8gZGV0ZXJtaW5lIHRoZSBkb21haW4gbmFtZShzKSBmb3IgdGhlIHB1YmxpYyBJUCBhZGRy ZXNzLg0KIDUuIFJlcGVhdCBzdGVwIDIuIGZvciB0aGUgbmV3IGRvbWFpbiBuYW1lKHMpLg0KIDYu IFVzZSBzdGF0aWMgY29uZmlndXJhdGlvbi4NCg0KVGhpcyByZWxpZXMgb24gaGF2aW5nIHJldmVy c2UgRE5TLCB3aGljaCBJJ20gdG9sZCBpcyBub3QgYW4gaXJvbmNsYWQgZ3VhcmFudGVlLCBidXQg aGlnaGx5IGxpa2VseS4NCg0KVGhpcyBtZXRob2QgaXMgZ29vZCBmb3IgbG9jYWwgc2VydmljZXMs IGJ1dCBmb3Igc2VydmljZXMgcmVsYXRpbmcgdG8geW91ciBjYWxsaW5nIHNlcnZpY2UsIEkgc2Vl IG5vIHJlYXNvbiBub3QgdG8gc2VhcmNoIGJhc2VkIG9uIHlvdXIgVlNQIGRvbWFpbi4gIEhvd2V2 ZXIsIEkgdGhpbmsgdGhhdCBWU1BzIGFyZSBwcm92aWRpbmcgYSBiYWNrdXAgTG9TVCBzZXJ2ZXIg b25seSAtIHRoZSBjb3ZlcmFnZSBhcmVhIG9mIHRoYXQgc2VydmVyIGlzIHZpcnR1YWxseSB1bmJv dW5kZWQsIHdoaWNoIG1ha2VzIGl0IGltcHJhY3RpY2FsIGxvbmcgdGVybS4gIE1heWJlIHRoZSBW U1Agd291bGQgYmUgaGFwcHkgd2l0aCBpdHMgc2VydmljZSBiZWluZyB0aGUgc3RhdGljYWxseSBj b25maWd1cmVkIG9wdGlvbi4NCg0KTWFydGluDQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0 ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFy eSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2Vp dmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFu ZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1h aWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KW21mMl0= --===============0598797938== 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 --===============0598797938==-- From ecrit-bounces@ietf.org Sun Apr 09 21:44:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSlS6-00067R-EW; Sun, 09 Apr 2006 21:44:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSlS4-00067G-Sa for ecrit@ietf.org; Sun, 09 Apr 2006 21:44:24 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSlS4-00006A-Ls for ecrit@ietf.org; Sun, 09 Apr 2006 21:44:24 -0400 Received: from [192.168.0.41] (pool-138-89-69-211.mad.east.verizon.net [138.89.69.211]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3A1iNFc008588 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 9 Apr 2006 21:44:24 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Sun, 9 Apr 2006 21:44:24 -0400 To: "Rosen, Brian" X-Mailer: Apple Mail (2.746.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ecrit@ietf.org Subject: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.police) 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: , Errors-To: ecrit-bounces@ietf.org > Consider the following issue: there is sos.police. In most areas > of the > world, there are several kinds of police services that are related to > the hierarchy of the jurisdictions. In North America, you typically > have local police, county police, state police and national police > (FBI). Some other services have this characteristic. Do we want to > allow a subservice under police? An alternative is to allow a > query to > a higher level civic address (a LoST query to a1=us, a2=pa for > sos.police gets you the Pennsylvania State Police). That wouldn't > work > for a geo query. An interesting issue. I suspect that this would be hard to categorize easily by hierarchy, as the hierarchy differs across countries. (For example, countries such as Germany only have essentially two levels - state and border patrol - while centralized countries such as France have, I believe, only one national police service.) In the US, this gets even more complicated since you have not just the ones you mention, but also campus police on every larger university campus, Amtrak police, ATF, capitol police (in DC), Secret Service and I'm sure FEMA has its own police force (equipped with bows and arrows). Until a few years ago, NYC had separate police forces for public housing and transit. Thus, I suspect you have to try to find designations that are geographically-independent, such as police. transportation police. border police. campus police. public-housing police. terrorism It is not clear to me that this is practically useful, as most people who need to know will be asking for ATF or FBI, rather than trying to guess which label applies to which service. Others will only need 'police' and then be transferred to the right agency. In the US, there are likely going to be several competing agencies :-) Do we want to do this now or wait until the need arises? Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 09 22:03:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSlks-0006j8-1R; Sun, 09 Apr 2006 22:03:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSlkq-0006j0-NE for ecrit@ietf.org; Sun, 09 Apr 2006 22:03:48 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSlkp-0000nD-F8 for ecrit@ietf.org; Sun, 09 Apr 2006 22:03:48 -0400 Received: from [192.168.0.41] (pool-138-89-69-211.mad.east.verizon.net [138.89.69.211]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3A23hVN000382 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 9 Apr 2006 22:03:44 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A0594BF-22A7-4967-88BD-695C0F016DE1@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02, DDDS Date: Sun, 9 Apr 2006 22:03:45 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.746.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "Rosen, Brian" , 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: , Errors-To: ecrit-bounces@ietf.org > We are looking at this sort of discovery mechanism for some tests > here as well. I think that it is workable, and you can write a > client that orders the different methods appropriately: > > 1. Get domain name from DNS > 2. Do NAPTR/SRV lookup for that domain (you can iterate from local > domains to TLD-1 if you like). Success = URL or Host/Port of service. > 3. Use STUN/UPnP/other to determine public IP address. > 4. Use reverse DNS to determine the domain name(s) for the public > IP address. > 5. Repeat step 2. for the new domain name(s). > 6. Use static configuration. > > This relies on having reverse DNS, which I'm told is not an > ironclad guarantee, but highly likely. Since the provider of the lookup service also controls the IP addresses in most cases, the ISP can fix the omission if need be. If there's agreement on this general mechanism, I'll add it to the draft. > > This method is good for local services, but for services relating > to your calling service, I see no reason not to search based on > your VSP domain. However, I think that VSPs are providing a backup > LoST server only - the coverage area of that server is virtually > unbounded, which makes it impractical long term. Maybe the VSP > would be happy with its service being the statically configured > option. Based on the architectural discussions, the VSP (or ISP) wouldn't really need to provide a world-wide database. It would provide an entry point only, i.e., a resolver in LoST terminology. This is no more onerous than providing a local DNS server. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 09 22:29:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSm9a-0000Oe-L4; Sun, 09 Apr 2006 22:29:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSm9Y-0000OW-Vq for ecrit@ietf.org; Sun, 09 Apr 2006 22:29:20 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSm9Y-00025j-Lu for ecrit@ietf.org; Sun, 09 Apr 2006 22:29:20 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Apr 2006 21:29:20 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sun, 09 Apr 2006 21:29:19 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Apr 2006 21:29:18 -0500 Message-ID: From: "Thomson, Martin" To: "Henning Schulzrinne" , "Rosen, Brian" Date: Sun, 9 Apr 2006 21:27:45 -0500 Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.police) MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 Apr 2006 02:29:18.0537 (UTC) FILETIME=[9182C390:01C65C46] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.police) Thread-Index: AcZcQhMjLtpWJ72TSlizKNDrL2jd4QAAIReg X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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: , Content-Type: multipart/mixed; boundary="===============1705628877==" Errors-To: ecrit-bounces@ietf.org --===============1705628877== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message VGhlIGxpbmUgbmVlZHMgdG8gYmUgZHJhd24gc29tZXdoZXJlOyBzbywgSSdkIHNheSB0aGF0IGxl YXZpbmcgYXMtaXMgZm9yIG5vdyBpcyBiZXN0Lg0KDQpCcmlhbidzIHN1Z2dlc3Rpb24gdGhhdCB5 b3UgY291bGQgcHVycG9zZWZ1bGx5IG1lc3Mgd2l0aCBwcmVjaXNpb24gdG8gZW5zdXJlIHRoYXQg eW91IGdldCB0aGUgZmVkZXJhbCBwb2xpY2UgaXMgZGFuZ2Vyb3VzLiAgVGhhdCBzb3J0IG9mIHRo aW5nIF9taWdodF8gbWFrZSBzZW5zZSBpbiBzb21lIGNhc2VzOyBidXQgSSBzdXNwZWN0IHRoYXQg dGhlIGVuZC11c2VyIGlzbid0IGFsd2F5cyB0aGUgb25lIHlvdSB3YW50IHRvIGhhdmUgbWFraW5n IHRoYXQgY2hvaWNlLiAgRGl2aXNpb24gYmFzZWQgb24gdHlwZSBvZiBpbmNpZGVudCBpcyBwcm9i YWJseSBzYWZlciwgYmVjYXVzZSB0aGVuIHlvdSBnZXQgdGhlIGZlZGVyYWwgcG9saWNlIHdoZW4g aXQncyBhcHByb3ByaWF0ZSBmb3IgdGhlbSB0byBhdHRlbmQsIGFuZCBub3QgYmVjYXVzZSBhIGNh bGxlciB0aG91Z2h0IGl0IHdvdWxkIGJlIGJlc3QuICBSb2FtaW5nIHVzZXJzIHRoZW4gZG9uJ3Qg bWFrZSBpbmNvcnJlY3QgYXNzdW1wdGlvbnMgYWJvdXQganVyaXNkaWN0aW9uLg0KDQpUaGF0IGNv dWxkIGxlYWQgdG8gYSBkaWZmZXJlbnQgc2V0IG9mIGxhYmVscyAodG8gYmUgc2xpZ2h0bHkgZnJp dm9sb3VzKToNCg0KICBzb3MuZGlzdHVyYmFuY2Vfb2ZfdGhlX3BlYWNlDQogIHNvcy5kaXN0dXJi YW5jZV9vZl90aGVfcGVhY2UuZG9tZXN0aWNfZGlzcHV0ZQ0KICBzb3MuY2FyX2NyYXNoIChnZXRz IHBvbGljZSwgZmlyZSBhbmQgYW1idWxhbmNlKQ0KICBzb3MuZ2FzX2xlYWsNCiAgc29zLmV4cGxv c2lvbg0KICBzb3MuZ3Vuc2hvdHMNCiAgc29zLmhvbGQtdXANCg0KVGhlIHByb2JsZW0gYmVpbmcg dGhhdCB0aGlzIHNvcnQgb2YgbGlzdCBpcyBhbG1vc3QgaW5maW5pdGUgLSBidXQgaXNuJ3QgdGhh dCBvbmUgb2YgdGhlIGpvYnMgb2YgdGhlIGNhbGwgdGFrZXI/DQoNCk1hcnRpbg0KDQpwLnMuIEV2 ZXJ5b25lIGtub3dzIHRoYXQgdGhlIFVTIGlzICJzcGVjaWFsIi4uLmFuZCBBbGNvaG9sLCBUb2Jh Y2NvIGFuZCBGaXJlYXJtcyBpcyBhIHN0b3JlLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IEhlbm5pbmcgU2NodWx6cmlubmUgW21haWx0bzpoZ3NAY3MuY29sdW1iaWEu ZWR1XQ0KPiBTZW50OiBNb25kYXksIDEwIEFwcmlsIDIwMDYgMTE6NDQgQU0NCj4gVG86IFJvc2Vu LCBCcmlhbg0KPiBDYzogZWNyaXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogW0Vjcml0XSBSZTogUmV2 aWV3IG9mIGRyYWZ0LWlldGYtZWNyaXQtc2VydmljZS11cm4tMDINCj4gKHNvcy5wb2xpY2UpDQo+ IA0KPiANCj4gDQo+ID4gQ29uc2lkZXIgdGhlIGZvbGxvd2luZyBpc3N1ZTogdGhlcmUgaXMgc29z LnBvbGljZS4gIEluIG1vc3QgYXJlYXMNCj4gPiBvZiB0aGUNCj4gPiB3b3JsZCwgdGhlcmUgYXJl IHNldmVyYWwga2luZHMgb2YgcG9saWNlIHNlcnZpY2VzIHRoYXQgYXJlIHJlbGF0ZWQgdG8NCj4g PiB0aGUgaGllcmFyY2h5IG9mIHRoZSBqdXJpc2RpY3Rpb25zLiAgSW4gTm9ydGggQW1lcmljYSwg eW91IHR5cGljYWxseQ0KPiA+IGhhdmUgbG9jYWwgcG9saWNlLCBjb3VudHkgcG9saWNlLCBzdGF0 ZSBwb2xpY2UgYW5kIG5hdGlvbmFsIHBvbGljZQ0KPiA+IChGQkkpLiAgU29tZSBvdGhlciBzZXJ2 aWNlcyBoYXZlIHRoaXMgY2hhcmFjdGVyaXN0aWMuICBEbyB3ZSB3YW50IHRvDQo+ID4gYWxsb3cg YSBzdWJzZXJ2aWNlIHVuZGVyIHBvbGljZT8gIEFuIGFsdGVybmF0aXZlIGlzIHRvIGFsbG93IGEN Cj4gPiBxdWVyeSB0bw0KPiA+IGEgaGlnaGVyIGxldmVsIGNpdmljIGFkZHJlc3MgKGEgTG9TVCBx dWVyeSB0byBhMT11cywgYTI9cGEgZm9yDQo+ID4gc29zLnBvbGljZSBnZXRzIHlvdSB0aGUgUGVu bnN5bHZhbmlhIFN0YXRlIFBvbGljZSkuICBUaGF0IHdvdWxkbid0DQo+ID4gd29yaw0KPiA+IGZv ciBhIGdlbyBxdWVyeS4NCj4gDQo+IEFuIGludGVyZXN0aW5nIGlzc3VlLiAgSSBzdXNwZWN0IHRo YXQgdGhpcyB3b3VsZCBiZSBoYXJkIHRvDQo+IGNhdGVnb3JpemUgZWFzaWx5IGJ5IGhpZXJhcmNo eSwgYXMgdGhlIGhpZXJhcmNoeSBkaWZmZXJzIGFjcm9zcw0KPiBjb3VudHJpZXMuIChGb3IgZXhh bXBsZSwgY291bnRyaWVzIHN1Y2ggYXMgR2VybWFueSBvbmx5IGhhdmUNCj4gZXNzZW50aWFsbHkg dHdvIGxldmVscyAtIHN0YXRlIGFuZCBib3JkZXIgcGF0cm9sIC0gd2hpbGUgY2VudHJhbGl6ZWQN Cj4gY291bnRyaWVzIHN1Y2ggYXMgRnJhbmNlIGhhdmUsIEkgYmVsaWV2ZSwgb25seSBvbmUgbmF0 aW9uYWwgcG9saWNlDQo+IHNlcnZpY2UuKQ0KPiANCj4gSW4gdGhlIFVTLCB0aGlzIGdldHMgZXZl biBtb3JlIGNvbXBsaWNhdGVkIHNpbmNlIHlvdSBoYXZlIG5vdCBqdXN0DQo+IHRoZSBvbmVzIHlv dSBtZW50aW9uLCBidXQgYWxzbyBjYW1wdXMgcG9saWNlIG9uIGV2ZXJ5IGxhcmdlcg0KPiB1bml2 ZXJzaXR5IGNhbXB1cywgQW10cmFrIHBvbGljZSwgQVRGLCBjYXBpdG9sIHBvbGljZSAoaW4gREMp LCBTZWNyZXQNCj4gU2VydmljZSBhbmQgSSdtIHN1cmUgRkVNQSBoYXMgaXRzIG93biBwb2xpY2Ug Zm9yY2UgKGVxdWlwcGVkIHdpdGgNCj4gYm93cyBhbmQgYXJyb3dzKS4gVW50aWwgYSBmZXcgeWVh cnMgYWdvLCBOWUMgaGFkIHNlcGFyYXRlIHBvbGljZQ0KPiBmb3JjZXMgZm9yIHB1YmxpYyBob3Vz aW5nIGFuZCB0cmFuc2l0Lg0KPiANCj4gVGh1cywgSSBzdXNwZWN0IHlvdSBoYXZlIHRvIHRyeSB0 byBmaW5kIGRlc2lnbmF0aW9ucyB0aGF0IGFyZQ0KPiBnZW9ncmFwaGljYWxseS1pbmRlcGVuZGVu dCwgc3VjaCBhcw0KPiAgICBwb2xpY2UuIHRyYW5zcG9ydGF0aW9uDQo+ICAgIHBvbGljZS4gYm9y ZGVyDQo+ICAgIHBvbGljZS4gY2FtcHVzDQo+ICAgIHBvbGljZS4gcHVibGljLWhvdXNpbmcNCj4g ICAgcG9saWNlLiB0ZXJyb3Jpc20NCj4gDQo+IEl0IGlzIG5vdCBjbGVhciB0byBtZSB0aGF0IHRo aXMgaXMgcHJhY3RpY2FsbHkgdXNlZnVsLCBhcyBtb3N0IHBlb3BsZQ0KPiB3aG8gbmVlZCB0byBr bm93IHdpbGwgYmUgYXNraW5nIGZvciBBVEYgb3IgRkJJLCByYXRoZXIgdGhhbiB0cnlpbmcgdG8N Cj4gZ3Vlc3Mgd2hpY2ggbGFiZWwgYXBwbGllcyB0byB3aGljaCBzZXJ2aWNlLiBPdGhlcnMgd2ls bCBvbmx5IG5lZWQNCj4gJ3BvbGljZScgYW5kIHRoZW4gYmUgdHJhbnNmZXJyZWQgdG8gdGhlIHJp Z2h0IGFnZW5jeS4gSW4gdGhlIFVTLA0KPiB0aGVyZSBhcmUgbGlrZWx5IGdvaW5nIHRvIGJlIHNl dmVyYWwgY29tcGV0aW5nIGFnZW5jaWVzIDotKQ0KPiANCj4gRG8gd2Ugd2FudCB0byBkbyB0aGlz IG5vdyBvciB3YWl0IHVudGlsIHRoZSBuZWVkIGFyaXNlcz8NCj4gDQo+IEhlbm5pbmcNCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEVjcml0 IG1haWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9u bHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNl IHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9y aWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRl ZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0= --===============1705628877== 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 --===============1705628877==-- From ecrit-bounces@ietf.org Sun Apr 09 23:56:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSnVp-0002hi-4b; Sun, 09 Apr 2006 23:56:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSnVn-0002hd-GU for ecrit@ietf.org; Sun, 09 Apr 2006 23:56:23 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSnVl-0003rJ-7C for ecrit@ietf.org; Sun, 09 Apr 2006 23:56:23 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Apr 2006 22:56:20 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sun, 09 Apr 2006 22:56:20 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Apr 2006 22:56:20 -0500 Message-ID: From: "Winterbottom, James" To: "Henning Schulzrinne" , "Thomson, Martin" Date: Sun, 9 Apr 2006 22:56:18 -0500 Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02, DDDS 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 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 Apr 2006 03:56:20.0691 (UTC) FILETIME=[BA283A30:01C65C52] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02, DDDS Thread-Index: AcZcQ9d9xlGJNssMTUSvEKftXQ+QbwADtoYw X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: "Rosen, Brian" , 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: , Errors-To: ecrit-bounces@ietf.org I believe that this is the right approach > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, 10 April 2006 12:04 PM > To: Thomson, Martin > Cc: Rosen, Brian; ecrit@ietf.org > Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02, DDDS >=20 > > We are looking at this sort of discovery mechanism for some tests > > here as well. I think that it is workable, and you can write a > > client that orders the different methods appropriately: > > > > 1. Get domain name from DNS > > 2. Do NAPTR/SRV lookup for that domain (you can iterate from local > > domains to TLD-1 if you like). Success =3D URL or Host/Port of service. > > 3. Use STUN/UPnP/other to determine public IP address. > > 4. Use reverse DNS to determine the domain name(s) for the public > > IP address. > > 5. Repeat step 2. for the new domain name(s). > > 6. Use static configuration. > > > > This relies on having reverse DNS, which I'm told is not an > > ironclad guarantee, but highly likely. >=20 > Since the provider of the lookup service also controls the IP > addresses in most cases, the ISP can fix the omission if need be. >=20 > If there's agreement on this general mechanism, I'll add it to the > draft. >=20 > > > > This method is good for local services, but for services relating > > to your calling service, I see no reason not to search based on > > your VSP domain. However, I think that VSPs are providing a backup > > LoST server only - the coverage area of that server is virtually > > unbounded, which makes it impractical long term. Maybe the VSP > > would be happy with its service being the statically configured > > option. >=20 > Based on the architectural discussions, the VSP (or ISP) wouldn't > really need to provide a world-wide database. It would provide an > entry point only, i.e., a resolver in LoST terminology. This is no > more onerous than providing a local DNS server. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 02:16:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSpgu-00013O-3O; Mon, 10 Apr 2006 02:16:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSpgs-000109-B7 for ecrit@ietf.org; Mon, 10 Apr 2006 02:15:58 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSpfb-0001DE-TK for ecrit@ietf.org; Mon, 10 Apr 2006 02:14:43 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 09 Apr 2006 23:14:39 -0700 X-IronPort-AV: i="4.04,105,1144047600"; d="scan'208"; a="267587361:sNHT27888730" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3A6Ed1j029801; Sun, 9 Apr 2006 23:14:39 -0700 (PDT) Received: from 171.68.225.134 ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 10 Apr 2006 06:14:39 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Sun, 09 Apr 2006 23:14:41 -0700 Subject: Re: [Ecrit] Best Current Practice for Communications Services in support of Emergency Calling From: Cullen Jennings To: "Tschofenig, Hannes" , ECRIT Message-ID: Thread-Topic: [Ecrit] Best Current Practice for Communications Services in support of Emergency Calling Thread-Index: AcY7q3UCNyC5bIHhRCWPJ1877Is1RwgupiGq In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: ecrit-bounces@ietf.org Trivial detail but .... it looks like the version that got put in the drafts directory was base64 encoded then got deleted. A rev of the draft is likely the quickest way to fix this. Cullen PS - I like the draft. On 2/27/06 6:43 AM, "Tschofenig, Hannes" wrote: > draft-rosen-ecrit-phonebcp-00.txt _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 07:59:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSv35-0001lS-K4; Mon, 10 Apr 2006 07:59:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSv33-0001lN-N4 for ecrit@ietf.org; Mon, 10 Apr 2006 07:59:13 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSv31-00062R-A2 for ecrit@ietf.org; Mon, 10 Apr 2006 07:59:13 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 10 Apr 2006 07:59:11 -0400 X-IronPort-AV: i="4.04,107,1144036800"; d="scan'208"; a="86081728:sNHT33499144" Received: from [68.48.124.149] (rtp-vpn4-229.cisco.com [10.82.208.229]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3ABxAVU021105; Mon, 10 Apr 2006 07:59:10 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <309c3c0b87f63a919bc01be439a5bc3c@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 Date: Mon, 10 Apr 2006 07:59:05 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: "Rosen, Brian" , 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: , Errors-To: ecrit-bounces@ietf.org On Apr 9, 2006, at 9:22 PM, Henning Schulzrinne wrote: > I think there are at least two plausible approaches to find an > ISP-operated domain name, besides DHCP: > > (1) SLP or Bonjour; the practical problem is that SLP is seeing > limited new deployments and Bonjour seems to be under the cloud of > being non-IETF-developed (but comparatively widely deployed), with the > IETF competitor having been sent back to the WG for a do-over > (somebody might know more about this). > > (2) Inverse DNS: Get public IP address (via STUN, say); obtain domain > name (via the usual reverse DNS lookup); use SRV or NAPTR record for > that domain. This relies on the user's public IP address having a DNS > entry. As far as I can tell, this seems to be almost universally true > for residential broadband. (For enterprise users, I suspect that the > DHCP solution is easiest.) > > I had suggested a version of (2). > ... The most recent comment on reverse DNS: On Apr 5, 2006, at 2:22 PM, Dean Anderson wrote ( on dnsop@lists.uoregon.edu): > I thought that the title was going to be changed to > 'inaddr-encouraged', and I > thought there were additional issues with the text, but I don't have a > list > right off-hand. Though I recall some particular problems with the > notion that > reverse and foward should or can always match, and particular problems > with > security assumptions promoted in the draft. > > I'll see if I can review some of the email on the topic later this > week, as well > as summarize some offlist discussion with a few people that apparently > misunderstood the text of the draft. > > --Dean > > On Tue, 4 Apr 2006, Andrew Sullivan wrote: > >> Dear colleagues, >> >> During the Dallas meeting, the topic of >> draft-ietf-dnsop-inaddr-required >> came up. About five people, including me, indicated interest in the >> draft, and the Chairs suggested that what was needed was an open >> issues list. >> >> Since I committed to do something about this, I thought I'd propose a >> summary list of what I take to be open issues. I don't expect this >> is a complete or correct list; I'm just proposing it so that we have >> something to start with (or, perhaps, so you can all point and laugh >> at what a bad job I've done understanding the discussion this far!). >> I'm also not proposing text patches now, on the grounds that we >> perhaps need to agree on a list of what the issues are before we >> attempt to fix them. I hope this is helpful. >> >> I compiled the following list by looking at the discussions about >> this draft from last January. The threads start at >> >> >> >> and >> >> >> >> I'm not including mere editorial comments (style, &c.) here, since I >> doubt that's where the real contention is. >> >> The list >> -------- >> >> 1. Update the policy discussion in paragraph 3 of section 2. >> >> 2. Fix informative reference [ARIN] target. >> >> 3. Add informative reference to detailed APNIC policies at >> . >> >> 4. Add informative reference [AFRINIC]. >> >> 5. The recommendations in section 4 are not strong enough. >> >> 6. The ability of people actually to add PTR records is not >> considered. >> >> Also, I noted one issue while I was preparing this, but I'm not sure >> it's in the discussion from January: >> >> 7. Section 2, paragraph 2, appears to say that [RFC2050] >> requires RIRs to maintain IN-ADDR records on the large blocks >> they issue. I'm not entirely sure that RFC2050 actually says >> that, even if that's what was intended. >> >> Discussion >> ---------- >> >> * Issue 1 >> >> Some of the policy is out of date, and needs to be adjusted >> to reflect the current policies of the bodies in question. >> >> * Issues 2-4 >> >> These are references that need fixing in light of (1). >> >> * Issue 5 >> >> Some people (I am among them) express uneasiness that the >> document seems to suggest both that IN-ADDR is a good thing, >> and that one shouldn't use it. People argue that, therefore, >> the recommendation should be stronger. In particular, some >> have argued that the advice in section 4.2 could be made a >> little more equivocal, so that operators are urged to be >> fully aware of the trade-offs they make in terms of >> reliability when relying on IN-ADDR, but that they should not >> be told "never do this". >> >> * Issue 6 >> >> Some people note that there are plenty of parts of the >> Internet where users have a hard time maintaining IN-ADDR. >> So, the discussion of the state of affairs in section 2 (or >> perhaps 3, if it's renamed) should point out how difficult it >> sometimes is for people to do this maintenance (and, >> presumably, lament the situation as one that ought to be >> fixed). In addition, any alteration of section 4.2 in >> accordance with (5) will need to point out to operators the >> potential victims of their decisions to rely on IN-ADDR. >> >> *Issue 7 >> >> RFC 2050 says, "The regional registries will be responsible >> for maintaining IN-ADDR.ARPA records only on the parent >> blocks of IP addresses issued directly to the ISPs or those >> CIDR blocks of less than /16." That doesn't entail that they >> will be responsible for such maintenance. It rather entails >> that, if they are responsible for anything, they're only >> responsible as far as the parent block (or the blocks less >> than /16). Perhaps there's another source which makes it >> unambiguously clear that they are in fact responsible for >> this? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 09:31:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwTr-00022l-Ir; Mon, 10 Apr 2006 09:30:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwTq-00022g-1x for ecrit@ietf.org; Mon, 10 Apr 2006 09:30:58 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSwTo-0001aL-NI for ecrit@ietf.org; Mon, 10 Apr 2006 09:30:58 -0400 Received: from [192.168.0.41] (pool-138-89-69-211.mad.east.verizon.net [138.89.69.211]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3ADUsJ9000172 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 10 Apr 2006 09:30:55 -0400 (EDT) In-Reply-To: <309c3c0b87f63a919bc01be439a5bc3c@cisco.com> References: <309c3c0b87f63a919bc01be439a5bc3c@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <38E34702-0B26-4CCA-A75F-698EE71F4150@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 Date: Mon, 10 Apr 2006 09:30:53 -0400 To: John Schnizlein X-Mailer: Apple Mail (2.746.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: "Rosen, Brian" , 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: , Errors-To: ecrit-bounces@ietf.org Thanks for the pointer. I took a quick look and it seems to say "in- addr mapping good, do it". Did I miss any caveats? > > The most recent comment on reverse DNS: > > On Apr 5, 2006, at 2:22 PM, Dean Anderson wrote ( on > dnsop@lists.uoregon.edu): > >> I thought that the title was going to be changed to 'inaddr- >> encouraged', and I >> thought there were additional issues with the text, but I don't >> have a list >> right off-hand. Though I recall some particular problems with the >> notion that >> reverse and foward should or can always match, and particular >> problems with >> security assumptions promoted in the draft. >> >> I'll see if I can review some of the email on the topic later this >> week, as well >> as summarize some offlist discussion with a few people that >> apparently >> misunderstood the text of the draft. >> >> --Dean >> >> On Tue, 4 Apr 2006, Andrew Sullivan wrote: >> >>> Dear colleagues, >>> >>> During the Dallas meeting, the topic of draft-ietf-dnsop-inaddr- >>> required >>> came up. About five people, including me, indicated interest in the >>> draft, and the Chairs suggested that what was needed was an open >>> issues list. >>> >>> Since I committed to do something about this, I thought I'd >>> propose a >>> summary list of what I take to be open issues. I don't expect this >>> is a complete or correct list; I'm just proposing it so that we have >>> something to start with (or, perhaps, so you can all point and laugh >>> at what a bad job I've done understanding the discussion this far!). >>> I'm also not proposing text patches now, on the grounds that we >>> perhaps need to agree on a list of what the issues are before we >>> attempt to fix them. I hope this is helpful. >>> >>> I compiled the following list by looking at the discussions about >>> this draft from last January. The threads start at >>> >>> >>> >>> and >>> >>> >>> >>> I'm not including mere editorial comments (style, &c.) here, since I >>> doubt that's where the real contention is. >>> >>> The list >>> -------- >>> >>> 1. Update the policy discussion in paragraph 3 of section 2. >>> >>> 2. Fix informative reference [ARIN] target. >>> >>> 3. Add informative reference to detailed APNIC policies at >>> . >>> >>> 4. Add informative reference [AFRINIC]. >>> >>> 5. The recommendations in section 4 are not strong enough. >>> >>> 6. The ability of people actually to add PTR records is not >>> considered. >>> >>> Also, I noted one issue while I was preparing this, but I'm not sure >>> it's in the discussion from January: >>> >>> 7. Section 2, paragraph 2, appears to say that [RFC2050] >>> requires RIRs to maintain IN-ADDR records on the large blocks >>> they issue. I'm not entirely sure that RFC2050 actually says >>> that, even if that's what was intended. >>> >>> Discussion >>> ---------- >>> >>> * Issue 1 >>> >>> Some of the policy is out of date, and needs to be adjusted >>> to reflect the current policies of the bodies in question. >>> >>> * Issues 2-4 >>> >>> These are references that need fixing in light of (1). >>> >>> * Issue 5 >>> >>> Some people (I am among them) express uneasiness that the >>> document seems to suggest both that IN-ADDR is a good thing, >>> and that one shouldn't use it. People argue that, >>> therefore, >>> the recommendation should be stronger. In particular, some >>> have argued that the advice in section 4.2 could be made a >>> little more equivocal, so that operators are urged to be >>> fully aware of the trade-offs they make in terms of >>> reliability when relying on IN-ADDR, but that they should >>> not >>> be told "never do this". >>> >>> * Issue 6 >>> >>> Some people note that there are plenty of parts of the >>> Internet where users have a hard time maintaining IN-ADDR. >>> So, the discussion of the state of affairs in section 2 (or >>> perhaps 3, if it's renamed) should point out how >>> difficult it >>> sometimes is for people to do this maintenance (and, >>> presumably, lament the situation as one that ought to be >>> fixed). In addition, any alteration of section 4.2 in >>> accordance with (5) will need to point out to operators the >>> potential victims of their decisions to rely on IN-ADDR. >>> >>> *Issue 7 >>> >>> RFC 2050 says, "The regional registries will be responsible >>> for maintaining IN-ADDR.ARPA records only on the parent >>> blocks of IP addresses issued directly to the ISPs or those >>> CIDR blocks of less than /16." That doesn't entail that they >>> will be responsible for such maintenance. It rather entails >>> that, if they are responsible for anything, they're only >>> responsible as far as the parent block (or the blocks less >>> than /16). Perhaps there's another source which makes it >>> unambiguously clear that they are in fact responsible for >>> this? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 09:43:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwgM-0008HV-2a; Mon, 10 Apr 2006 09:43:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwgL-0008HL-B1 for ecrit@ietf.org; Mon, 10 Apr 2006 09:43:53 -0400 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.43) id 1FSwgK-0001qu-R2 for ecrit@ietf.org; Mon, 10 Apr 2006 09:43:53 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 10 Apr 2006 06:43:52 -0700 X-IronPort-AV: i="4.04,108,1144047600"; d="scan'208"; a="423097914:sNHT28157372" 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 k3ADhqGv011820; Mon, 10 Apr 2006 06:43:52 -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); Mon, 10 Apr 2006 06:43:51 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Apr 2006 06:43:48 -0700 From: "Marc Linsner" To: "'Winterbottom, James'" Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02, DDDS Date: Mon, 10 Apr 2006 09:43:45 -0400 Message-ID: <006201c65ca4$cb737050$1f0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZcQ9d9xlGJNssMTUSvEKftXQ+QbwADtoYwABF3KXA= In-Reply-To: X-OriginalArrivalTime: 10 Apr 2006 13:43:51.0043 (UTC) FILETIME=[CD011530:01C65CA4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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: , Errors-To: ecrit-bounces@ietf.org 1. Given the current state of the in-addr.arpa db (IMO, a mess) and the current discussions going on within the dns ops community, I would not want to suggest that implementers rely on this service. The current draft within the dnsop wg only suggests the population of in-addr.arpa, it does not require it. 2. I agree with Henning in that a VoIP SP is the most likely candidate to operate a LoST server/service and therefore any entry in the in-addr.arpa db would never compare to the operator of a telephone service. I certainly wouldn't want the success of an emergency call I make to rely on reverse DNS. I suggest we don't mention it. -Marc- > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Sunday, April 09, 2006 11:56 PM > To: Henning Schulzrinne; Thomson, Martin > Cc: Rosen, Brian; ecrit@ietf.org > Subject: RE: [Ecrit] Re: Review of > draft-ietf-ecrit-service-urn-02, DDDS > > I believe that this is the right approach > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Monday, 10 April 2006 12:04 PM > > To: Thomson, Martin > > Cc: Rosen, Brian; ecrit@ietf.org > > Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02, > DDDS > > > > > We are looking at this sort of discovery mechanism for some tests > > > here as well. I think that it is workable, and you can write a > > > client that orders the different methods appropriately: > > > > > > 1. Get domain name from DNS > > > 2. Do NAPTR/SRV lookup for that domain (you can iterate > from local > > > domains to TLD-1 if you like). Success = URL or Host/Port of > service. > > > 3. Use STUN/UPnP/other to determine public IP address. > > > 4. Use reverse DNS to determine the domain name(s) for > the public > > > IP address. > > > 5. Repeat step 2. for the new domain name(s). > > > 6. Use static configuration. > > > > > > This relies on having reverse DNS, which I'm told is not > an ironclad > > > guarantee, but highly likely. > > > > Since the provider of the lookup service also controls the IP > > addresses in most cases, the ISP can fix the omission if need be. > > > > If there's agreement on this general mechanism, I'll add it to the > > draft. > > > > > > > > This method is good for local services, but for services > relating to > > > your calling service, I see no reason not to search based on your > > > VSP domain. However, I think that VSPs are providing a > backup LoST > > > server only - the coverage area of that server is virtually > > > unbounded, which makes it impractical long term. Maybe the VSP > > > would be happy with its service being the statically configured > > > option. > > > > Based on the architectural discussions, the VSP (or ISP) wouldn't > > really need to provide a world-wide database. It would provide an > > entry point only, i.e., a resolver in LoST terminology. This is no > > more onerous than providing a local DNS server. > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://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 Apr 10 09:52:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwoZ-0003GI-Vl; Mon, 10 Apr 2006 09:52:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwoY-0003G8-Nz for ecrit@ietf.org; Mon, 10 Apr 2006 09:52:22 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSwoX-0001zZ-Hg for ecrit@ietf.org; Mon, 10 Apr 2006 09:52:22 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 10 Apr 2006 06:52:22 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,108,1144047600"; d="scan'208"; a="25546503:sNHT22547180" Received: from [68.48.124.149] (rtp-vpn4-229.cisco.com [10.82.208.229]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3ADqLVU013990; Mon, 10 Apr 2006 09:52:21 -0400 (EDT) In-Reply-To: <38E34702-0B26-4CCA-A75F-698EE71F4150@cs.columbia.edu> References: <309c3c0b87f63a919bc01be439a5bc3c@cisco.com> <38E34702-0B26-4CCA-A75F-698EE71F4150@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5dc68f2456dbeb0393a2b6ba6ce2da11@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 Date: Mon, 10 Apr 2006 09:52:20 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "Rosen, Brian" , 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: , Errors-To: ecrit-bounces@ietf.org On Apr 10, 2006, at 9:30 AM, Henning Schulzrinne wrote: > Thanks for the pointer. I took a quick look and it seems to say > "in-addr mapping good, do it". Did I miss any caveats? Yes, I think you missed these three points about draft-ietf-dnsop-inaddr-required-07.txt: 1) Since the -00 draft in August 2000, the biggest decision is that in-addr is NOT to be required. 2) The abstract says many sites do not implement it. "Mapping of addresses to names has been a feature of DNS. Many sites, implement it, many others don't. " 3) Section 4.2 says explicitly: "Applications SHOULD NOT rely on IN-ADDR for proper operation." John _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 10:18:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxDS-0005g3-Gk; Mon, 10 Apr 2006 10:18:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxDR-0005fx-CJ for ecrit@ietf.org; Mon, 10 Apr 2006 10:18:05 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSxDQ-0003EN-6M for ecrit@ietf.org; Mon, 10 Apr 2006 10:18:05 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Mon, 10 Apr 2006 10:17:03 -0400 id 01588001.443A68DF.000002FB Message-ID: <443A691F.2000606@hxr.us> Date: Mon, 10 Apr 2006 10:18:07 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.police) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: "Rosen, Brian" , 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: , Errors-To: ecrit-bounces@ietf.org Henning Schulzrinne wrote: > Thus, I suspect you have to try to find designations that are > geographically-independent, such as > police. transportation > police. border > police. campus > police. public-housing > police. terrorism > > It is not clear to me that this is practically useful, as most people > who need to know will be asking for ATF or FBI, rather than trying to > guess which label applies to which service. Others will only need > 'police' and then be transferred to the right agency. In the US, there > are likely going to be several competing agencies :-) I totally agree. I also can't imagine the user interface being all that helpful in an emergency situation by offering a slew of sub-police function categories. > > Do we want to do this now or wait until the need arises? Wait. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 10:31:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxQe-0004ac-Sv; Mon, 10 Apr 2006 10:31:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxQd-0004aV-OP for ecrit@ietf.org; Mon, 10 Apr 2006 10:31:43 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSxQd-0003mu-IM for ecrit@ietf.org; Mon, 10 Apr 2006 10:31:43 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Mon, 10 Apr 2006 10:30:43 -0400 id 01588001.443A6C13.000005CA Message-ID: <443A6C53.7020900@hxr.us> Date: Mon, 10 Apr 2006 10:31:47 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02, DDDS References: <006201c65ca4$cb737050$1f0d0d0a@amer.cisco.com> In-Reply-To: <006201c65ca4$cb737050$1f0d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: , Errors-To: ecrit-bounces@ietf.org Marc Linsner wrote: > 1. Given the current state of the in-addr.arpa db (IMO, a mess) and the > current discussions going on within the dns ops community, I would not want > to suggest that implementers rely on this service. The current draft within > the dnsop wg only suggests the population of in-addr.arpa, it does not > require it. > > 2. I agree with Henning in that a VoIP SP is the most likely candidate to > operate a LoST server/service and therefore any entry in the in-addr.arpa db > would never compare to the operator of a telephone service. > > I certainly wouldn't want the success of an emergency call I make to rely on > reverse DNS. I suggest we don't mention it. First, I agree that solely hanging our hats on reverse DNS is a recipe for a non-working architecture. During the MARID working group when many people were arguing for MTA Mark and using the reverse DNS for anti-spam measures, APNIC sent a formal message that basically said, "fat chance of getting that to work in Asia." However, the suggestion isn't a bad idea in this use case as there are likely to be many ISPs that do maintain their reverse space adequately and would want to do the right thing (if they can). Additionally, if this lookup is done at boot-time or network attachment-time, then I think it would be preferable to use it over that of a VSP-default. To restate it: At boot or network attachment time, do the following: 1) Use the reverse DNS to find the appropriate LoST resolver. 2) If not successful, use the VSP default to find the appropriate LoST resolver. BTW, we are talking about VSPs running LoST resolvers, not LoST mapping servers, right? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 13:28:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT0BO-000219-Jk; Mon, 10 Apr 2006 13:28:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT0BN-000214-Sx for ecrit@ietf.org; Mon, 10 Apr 2006 13:28:09 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT0BM-0002qM-Le for ecrit@ietf.org; Mon, 10 Apr 2006 13:28:09 -0400 Received: from lion.cs.columbia.edu (IDENT:PljLR0Xx6fo2g9HlXabu1ocglnE/8W2w@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k3AHRxcL019474 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 10 Apr 2006 13:28:00 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k3AHRxjN009435 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 10 Apr 2006 13:27:59 -0400 Message-ID: <443A959A.5010602@cs.columbia.edu> Date: Mon, 10 Apr 2006 13:27:54 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02, DDDS References: <006201c65ca4$cb737050$1f0d0d0a@amer.cisco.com> <443A6C53.7020900@hxr.us> In-Reply-To: <443A6C53.7020900@hxr.us> 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_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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: , Errors-To: ecrit-bounces@ietf.org > First, I agree that solely hanging our hats on reverse DNS is a recipe > for a non-working architecture. During the MARID working group when > many people were arguing for MTA Mark and using the reverse DNS for > anti-spam measures, APNIC sent a formal message that basically said, > "fat chance of getting that to work in Asia." > > However, the suggestion isn't a bad idea in this use case as there are > likely to be many ISPs that do maintain their reverse space adequately > and would want to do the right thing (if they can). Additionally, if > this lookup is done at boot-time or network attachment-time, then I > think it would be preferable to use it over that of a VSP-default. I'm curious what leads you to this conclusion. (I could come up with reasons either way and would consider my reasons largely speculative, in the realm of motivation, since there's not much real deployment to go by, to put it charitably.) One clear advantage of the ISP-operated resolver is that it is likely to be closer, network-wise, than a VSP-operated one and it satisfies the extensively-inconclusively-debated minimum-connectivity requirement. > > To restate it: > At boot or network attachment time, do the following: > 1) Use the reverse DNS to find the appropriate LoST resolver. > 2) If not successful, use the VSP default to find the appropriate LoST > resolver. > I would elaborate on this slightly and say that an end system would use the ICE mechanism to determine all IP addresses and then perform reverse DNS (your step (1)), possibly several times. One minor wrinkle is that some systems also get their DNS name via DHCP. I would suggest that as step (0). > BTW, we are talking about VSPs running LoST resolvers, not LoST mapping > servers, right? At least in my view of the world, yes. (I think there was some discussion that they might run actual mapping servers during early deployments.) Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 14:14:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT0ty-0008NZ-4F; Mon, 10 Apr 2006 14:14:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT0tw-0008NU-Dk for ecrit@ietf.org; Mon, 10 Apr 2006 14:14:12 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT0tv-0004iZ-6J for ecrit@ietf.org; Mon, 10 Apr 2006 14:14:12 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3AIDxBW014201; Mon, 10 Apr 2006 18:13:59 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 14:13: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] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.police) Date: Mon, 10 Apr 2006 14:13:56 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.police) Thread-Index: AcZcqZVZxxNFgAG+TramoJeJuQNwYwAH/p9w From: "Rosen, Brian" To: "Andrew Newton" , "Henning Schulzrinne" X-OriginalArrivalTime: 10 Apr 2006 18:13:59.0422 (UTC) FILETIME=[89F371E0:01C65CCA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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: , Errors-To: ecrit-bounces@ietf.org I am sorry, but I find this logic questionable. There is a clear need. If you have a way to dial them now, and any of them need accurate location based routing, then we need services for them. You can't say because there are more than 2 of them it's too hard. OTOH, it will be easy to add them, so we can punt for now Brian -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Monday, April 10, 2006 10:18 AM To: Henning Schulzrinne Cc: Rosen, Brian; ecrit@ietf.org Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.police) Henning Schulzrinne wrote: > Thus, I suspect you have to try to find designations that are=20 > geographically-independent, such as > police. transportation > police. border > police. campus > police. public-housing > police. terrorism >=20 > It is not clear to me that this is practically useful, as most people=20 > who need to know will be asking for ATF or FBI, rather than trying to=20 > guess which label applies to which service. Others will only need=20 > 'police' and then be transferred to the right agency. In the US, there > are likely going to be several competing agencies :-) I totally agree. I also can't imagine the user interface being all that helpful in an emergency situation by offering a slew of sub-police=20 function categories. >=20 > Do we want to do this now or wait until the need arises? Wait. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 14:24:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT13V-0004bu-PI; Mon, 10 Apr 2006 14:24:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT13U-0004bp-Da for ecrit@ietf.org; Mon, 10 Apr 2006 14:24:04 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT13T-00059r-6r for ecrit@ietf.org; Mon, 10 Apr 2006 14:24:04 -0400 Received: from lion.cs.columbia.edu (IDENT:q3i7F/G3eSJoers3Hi8I0igsYsUOOQ8x@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k3AINxcL001792 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 10 Apr 2006 14:24:00 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k3AINxjN013201 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 10 Apr 2006 14:23:59 -0400 Message-ID: <443AA2BA.9040301@cs.columbia.edu> Date: Mon, 10 Apr 2006 14:23:54 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Rosen, Brian" Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.police) References: 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_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , Errors-To: ecrit-bounces@ietf.org I think in some cases, a two-layer model may work better where services are not easily categorized by simple labels: - Query for service urn:service:police.directory (or something like that) - Get a search interface where you can type in "FBI" or "narcotics". The search interface would be suitably geographically tailored so that "county sheriff" returns your county sheriff, not somebody from another state. This is similar to the approach used in big cities. In NYC, you call 311, rather than trying to figure out which of the hundreds of agencies serves your particular non-emergency need. Rosen, Brian wrote: > I am sorry, but I find this logic questionable. > > There is a clear need. If you have a way to dial them now, and any of > them need accurate location based routing, then we need services for > them. You can't say because there are more than 2 of them it's too > hard. > > OTOH, it will be easy to add them, so we can punt for now > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 14:25:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT14R-0004xO-5r; Mon, 10 Apr 2006 14:25:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT14P-0004xH-6l for ecrit@ietf.org; Mon, 10 Apr 2006 14:25:01 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT14O-0005Bs-U9 for ecrit@ietf.org; Mon, 10 Apr 2006 14:25:01 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3AIOnBW014994; Mon, 10 Apr 2006 18:24:49 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 14:24:49 -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 Date: Mon, 10 Apr 2006 14:24:47 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-ecrit-service-urn-02 Thread-Index: AcZcPUX3CXeUJsZrQvO368u8xXLwsAAjVDAQ From: "Rosen, Brian" To: "Henning Schulzrinne" X-OriginalArrivalTime: 10 Apr 2006 18:24:49.0561 (UTC) FILETIME=[0D76C890:01C65CCC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: ecrit@ietf.org Subject: [Ecrit] RE: Review of draft-ietf-ecrit-service-urn-02 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: , Errors-To: ecrit-bounces@ietf.org Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 telephone number. To make this work using service urns, you would have to have the result of an enum dip for this number result in a urn that is not currently a valid enum service. However, if you did make a new service, it would work: e.164 is looked up in enum result is service urn urn is mapped with LoST call is sent where indicated, based on location of caller. Now, the caller would have to voluntarily put location on the call for this to work. I read: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN. =20 quite literally. urn:service.sos is a validly-assigned URN because there is an RFC that says it is (which is the same as saying it's in the IANA registry of services). "Validly-assigned" does not mean "currently active in a domain" to me. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Sunday, April 09, 2006 9:23 PM To: Rosen, Brian Cc: ecrit@ietf.org Subject: Re: Review of draft-ietf-ecrit-service-urn-02 More responses: On Apr 5, 2006, at 10:47 AM, Rosen, Brian wrote: > I have reviewed service-urn-02 and have the following comments: > > A little concerned about 1-800-LAWYER as an example. The problem here > is that there is no obvious mechanism to translate the e.164 > 1-800-LAWYER to the service urn. I suppose someone could propose an > enumservice for this purpose, but until they do, we might consider > removing this particular example Removing lawyers is always a good idea. (The similarity is that =20 dialing this number will get you a lawyer anywhere in the US, with =20 the law office depending on where you're calling from.) I don't quite =20 understand your concern about needing an enum service. > > You need a statement that points out the obvious: since the service =20 > urn > is a protocol labeling mechanism, it has no i18n implications. I'll add an I18N section. > > My biggest problem is the DDDS stuff (section 3). There is no > discussion of what domain you query the DNS for. This is an area well > worked over by other emergency stuff, and 'fragile' because what you > normally want is your "local" (as in access network) domain, and it's I don't think that's really true in general. Why should my access =20 network have better information about these services, particularly if =20 it has no interest in VoIP or emergency calls? I suspect that, =20 initially, the service lookup will be offered by the VSP. They have =20 an interest and obligation to provide the service and can't wait =20 until every last ISP has decided to provide a mapping service. > not all that easy to determine what that is. Read the HELD and LCP > documents, and the discussion about this point. I think this document > needs to handle this. I think whatever it says is likely to have =20 > to be > I didn't see any description of this in draft-winterbottom-geopriv-=20 held-sighting-00. LCP seems to define, besides the usual suspects of =20 manual configuration and DHCP, a broadcast request, not specified =20 further. (This would be essentially a one-off version of SLP.) I think there are at least two plausible approaches to find an ISP-=20 operated domain name, besides DHCP: (1) SLP or Bonjour; the practical problem is that SLP is seeing =20 limited new deployments and Bonjour seems to be under the cloud of =20 being non-IETF-developed (but comparatively widely deployed), with =20 the IETF competitor having been sent back to the WG for a do-over =20 (somebody might know more about this). (2) Inverse DNS: Get public IP address (via STUN, say); obtain domain =20 name (via the usual reverse DNS lookup); use SRV or NAPTR record for =20 that domain. This relies on the user's public IP address having a DNS =20 entry. As far as I can tell, this seems to be almost universally true =20 for residential broadband. (For enterprise users, I suspect that the =20 DHCP solution is easiest.) I had suggested a version of (2). > the same as any other similar mechanism in the milieu (for example, =20 > how > you find your LoST server). We need to decide what this text is, and > copy it into all the relevant documents. Actually, you find your LoST server via this mechanism, since it =20 performs the translation. > > I am confused by the "Validation Mechanism" in Section 2. First of =20 > all > the word "resource" is used here for the first time. I am assuming it > has the meaning of 3406 resource. The real problem is that the =20 > section > in 3406 that talks about validity defines it as "is there a valid > service" rather than "is the service available". Using the DDDS > mechanism would only tell you if a service was available (in the sense > of configured, rather than in the sense of functioning) within a =20 > domain. > While I think you could keep most of this text if you qualify it, I > think the actual answer is that the validation mechanism is IANA > assignment. I agree that this doesn't quite fit; I reread 3406 and 3406 defines =20 validation thusly: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN. =20 [...] This seems to imply that this mechanism would allow to determine =20 whether urn:service:timezone, say, exists or not. This would =20 presumably be done by the lookup mechanism. I'll reword the paragraph to hopefully make the distinction clearer. (more to follow) Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 14:27:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT16J-0005XQ-W1; Mon, 10 Apr 2006 14:26:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT16J-0005XI-4l for ecrit@ietf.org; Mon, 10 Apr 2006 14:26:59 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT16I-0005Em-Uk for ecrit@ietf.org; Mon, 10 Apr 2006 14:26:59 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Mon, 10 Apr 2006 14:25:58 -0400 id 01588106.443AA336.000031D1 Message-ID: <443AA376.6080008@hxr.us> Date: Mon, 10 Apr 2006 14:27:02 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02, DDDS References: <006201c65ca4$cb737050$1f0d0d0a@amer.cisco.com> <443A6C53.7020900@hxr.us> <443A959A.5010602@cs.columbia.edu> In-Reply-To: <443A959A.5010602@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: , Errors-To: ecrit-bounces@ietf.org Comments in-line: Henning Schulzrinne wrote: >> First, I agree that solely hanging our hats on reverse DNS is a recipe >> for a non-working architecture. During the MARID working group when >> many people were arguing for MTA Mark and using the reverse DNS for >> anti-spam measures, APNIC sent a formal message that basically said, >> "fat chance of getting that to work in Asia." >> >> However, the suggestion isn't a bad idea in this use case as there are >> likely to be many ISPs that do maintain their reverse space adequately >> and would want to do the right thing (if they can). Additionally, if >> this lookup is done at boot-time or network attachment-time, then I >> think it would be preferable to use it over that of a VSP-default. > > I'm curious what leads you to this conclusion. (I could come up with > reasons either way and would consider my reasons largely speculative, in > the realm of motivation, since there's not much real deployment to go > by, to put it charitably.) > > One clear advantage of the ISP-operated resolver is that it is likely to > be closer, network-wise, than a VSP-operated one and it satisfies the > extensively-inconclusively-debated minimum-connectivity requirement. I agree. I think the ISP will have a much better idea about the closest resolver than the VSP. >> To restate it: >> At boot or network attachment time, do the following: >> 1) Use the reverse DNS to find the appropriate LoST resolver. >> 2) If not successful, use the VSP default to find the appropriate >> LoST resolver. >> > > I would elaborate on this slightly and say that an end system would use > the ICE mechanism to determine all IP addresses and then perform reverse > DNS (your step (1)), possibly several times. > > One minor wrinkle is that some systems also get their DNS name via DHCP. > I would suggest that as step (0). No disagreement on either point. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 14:30:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT19W-0006cF-9m; Mon, 10 Apr 2006 14:30:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT19V-0006cA-O0 for ecrit@ietf.org; Mon, 10 Apr 2006 14:30:17 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT19V-0005KT-I9 for ecrit@ietf.org; Mon, 10 Apr 2006 14:30:17 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3AIU7BW015372; Mon, 10 Apr 2006 18:30:07 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 14:30:07 -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: Review of draft-ietf-ecrit-service-urn-02 (sos.police) Date: Mon, 10 Apr 2006 14:29:58 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.police) Thread-Index: AcZcy/M0nYPfokKmTDewqVBFz2AfywAAD4gQ From: "Rosen, Brian" To: "Henning Schulzrinne" X-OriginalArrivalTime: 10 Apr 2006 18:30:07.0288 (UTC) FILETIME=[CAD81380:01C65CCC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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: , Errors-To: ecrit-bounces@ietf.org That's fine for someone that does not know which service he needs, and doesn't know the number. Right now, if you have the number, and you want to location based route it, we need to define a service so we can do the right thing in LoST. These labels aren't for human consumption; they are protocol mechanisms. There are separate services, and we need an identifier for each separate service. I'm not objecting to (later) adding some more mechanisms to help users distinguish. I'm suggesting that we can include some more service labels in the initial set. Or not. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Monday, April 10, 2006 2:24 PM To: Rosen, Brian Cc: Andrew Newton; ecrit@ietf.org Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.police) I think in some cases, a two-layer model may work better where services=20 are not easily categorized by simple labels: - Query for service urn:service:police.directory (or something like that) - Get a search interface where you can type in "FBI" or "narcotics". The search interface would be suitably geographically tailored so that=20 "county sheriff" returns your county sheriff, not somebody from another=20 state. This is similar to the approach used in big cities. In NYC, you call=20 311, rather than trying to figure out which of the hundreds of agencies=20 serves your particular non-emergency need. Rosen, Brian wrote: > I am sorry, but I find this logic questionable. >=20 > There is a clear need. If you have a way to dial them now, and any of > them need accurate location based routing, then we need services for > them. You can't say because there are more than 2 of them it's too > hard. >=20 > OTOH, it will be easy to add them, so we can punt for now >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 14:30:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT19s-0006fJ-JK; Mon, 10 Apr 2006 14:30:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT19r-0006fE-Tw for ecrit@ietf.org; Mon, 10 Apr 2006 14:30:39 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT19q-0005Kp-Nj for ecrit@ietf.org; Mon, 10 Apr 2006 14:30:39 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Mon, 10 Apr 2006 14:29:38 -0400 id 01588100.443AA412.000032EF Message-ID: <443AA452.6070509@hxr.us> Date: Mon, 10 Apr 2006 14:30:42 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Rosen, Brian" Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.police) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: ecrit-bounces@ietf.org Rosen, Brian wrote: > I am sorry, but I find this logic questionable. > > There is a clear need. If you have a way to dial them now, and any of > them need accurate location based routing, then we need services for > them. You can't say because there are more than 2 of them it's too > hard. > > OTOH, it will be easy to add them, so we can punt for now Ok. Let's compromise for now and add them later if they are needed. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 15:17:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT1tI-0004BO-Ij; Mon, 10 Apr 2006 15:17:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT1tH-0004BJ-Dg for ecrit@ietf.org; Mon, 10 Apr 2006 15:17:35 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT1tH-0007hU-11 for ecrit@ietf.org; Mon, 10 Apr 2006 15:17:35 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 10 Apr 2006 12:17:21 -0700 X-IronPort-AV: i="4.04,108,1144047600"; d="scan'208"; a="267753875:sNHT1346251664" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3AJHJ1j011380; Mon, 10 Apr 2006 12:17:19 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Apr 2006 12:17:19 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Apr 2006 12:17:18 -0700 From: "Marc Linsner" To: "'Andrew Newton'" Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02, DDDS Date: Mon, 10 Apr 2006 15:17:14 -0400 Message-ID: <00f601c65cd3$60cdc230$1f0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZcq4shwRPfb63gSnGDALzBkk+l2AAEFJQw In-Reply-To: <443A6C53.7020900@hxr.us> X-OriginalArrivalTime: 10 Apr 2006 19:17:18.0677 (UTC) FILETIME=[627BC050:01C65CD3] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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: , Errors-To: ecrit-bounces@ietf.org > > First, I agree that solely hanging our hats on reverse DNS is > a recipe for a non-working architecture. During the MARID > working group when many people were arguing for MTA Mark and > using the reverse DNS for anti-spam measures, APNIC sent a > formal message that basically said, "fat chance of getting > that to work in Asia." I think APNIC gives too much credit to non-Asia access providers. > > However, the suggestion isn't a bad idea in this use case as > there are likely to be many ISPs that do maintain their > reverse space adequately and would want to do the right thing > (if they can). Additionally, if this lookup is done at > boot-time or network attachment-time, then I think it would > be preferable to use it over that of a VSP-default. > > To restate it: > At boot or network attachment time, do the following: > 1) Use the reverse DNS to find the appropriate LoST resolver. > 2) If not successful, use the VSP default to find the > appropriate LoST resolver. Why would we rely on a historically failed mechanism as our #1 choice for discovering a LoST resolver? I believe we agree that discovering a LoST resolver is essential to the success of an emergency call. Precedence dictates that the provider of the 'telephone service' is responsible for ensuring a successful emergency call setup. This leads to a conclusion that the application provider *should* be more interested in operating the LoST resolver used by it's customers than the access provider who is simply selling pipes and bandwidth. We are currently asking the access provider to, in addition to providing pipes and bandwidth: 1) Implement a location determination mechanism. We believe this is straight forward for wireline access providers, we believe they have this information within their service location db. 2) Provide this location information to their customer via: dhcp and/or a yet-to-be-determined L7 protocol. Now we want to add to the list: 3) Operate a LoST resolver 4) Update and maintain the in-addr.arpa database to facilitate the discovery of said resolver (which seems odd given #3). We reconcile #1 & #2 by concluding that there is no other place to get this information, therefore the access provider *must* provide it. We have no valid argument for #3 & #4, we simply can't justify why an access provider would be in the LoST resolver business. The discovery of the LoST resolver should be provisioned: 1) Via the application provider's registration mechanism. 2) Hard-coded. (I'm from the old-school that believes the application provider will still be involved in the config of the client, e.g. supply the client hardware and/or software). 3) IF the access provider operates a LoST resolver, via the host configuration mechanism. I think we should listen to the dns ops gurus. > > BTW, we are talking about VSPs running LoST resolvers, not > LoST mapping servers, right? Correct! -Marc- > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 16:09:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT2hj-00082P-2x; Mon, 10 Apr 2006 16:09:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT2hi-00081w-5R; Mon, 10 Apr 2006 16:09:42 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT2hh-00022V-Oi; Mon, 10 Apr 2006 16:09:42 -0400 Received: from ([90.152.52.44]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.127425270; Mon, 10 Apr 2006 16:08:43 -0400 Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01AL10015010117.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 10 Apr 2006 15:08:45 -0500 Importance: normal Priority: normal 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 MimeOLE V6.00.2800.1506 Date: Mon, 10 Apr 2006 15:08:44 -0500 Message-ID: <9888E1AA13C3A1459D122996A58C0E1107CA352C@bre2k61p-55> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] static location on a mobile device thread-index: AcZZeBiUyUS5+uoNQ1ypFV5kD1vwHQAAs9yAAAJ9M2AAAGkqoADUYxxA From: "Stark, Barbara" To: "Stastny Richard" , "Marc Berryman" , "Marc Linsner" , "Andrew Newton" , , X-OriginalArrivalTime: 10 Apr 2006 20:08:45.0593 (UTC) FILETIME=[926DC090:01C65CDA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: Subject: [Ecrit] RE: [Geopriv] static location on a mobile device 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: , Errors-To: ecrit-bounces@ietf.org I'd like to suggest an additional scenario for us to consider. We (BellSouth) currently offer a "WIMAX-like" "fixed wireless" service in several cities (like New Orleans, Biloxi, etc., where much of the communications infrastructure was destroyed). The customer-side antenna for this service is rather small (about the size of a mass market paperback book) and can be run off battery power. The output of this little antenna is a RJ-45 Ethernet jack. A laptop can be plugged into this Ethernet jack. The user would then run a PPPoE client (standard feature in XP) to connect to our network. Once the network connection is established, the user can run a SIP client on the laptop. Now the user can drive all around the city and use VoIP from anywhere in a 7 square mile (or so) area. The network-side antenna is connected through ATM to our core network, and from there to the same BRASs that serve our regular DSL customers. These BRASs terminate the PPPoE sessions, just like they do for our regular DSL. The laptop and SIP client in this case have absolutely no idea that they are "mobile". All they see is an Ethernet connection, and the IP address they get from PPPoE doesn't change over the 7 sq mi. Only the user and the network are aware of the laptop's mobility. So, if we are to consider a tag or warning that originates from the client, do we also need some way for the network to tell the client that they are potentially mobile or have moved?=20 We cannot assume that VoIP clients/devices are aware of their mobility or potential mobility. Barbara > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, April 06, 2006 10:35 AM > To: Marc Berryman; Marc Linsner; Andrew Newton; geopriv@ietf.org; > ecrit@ietf.org > Subject: RE: [Geopriv] static location on a mobile device >=20 >=20 > I consider a tag or warning useful not only with > static configuration, but also with dynamic configuration >=20 > Brian is proposing in his I-D ecrit-phonebcp, > that a device immediately gets his location at > attachment time, and each time the device is moved > The device may detect this by some means, e.g. change of > IP address or change of hotspot, etc. >=20 > What may happen here is that the device is not > able to retrieve the location at this time, so the > location information may be tagged as out-dated > until a new location information may be retrieved >=20 > The same could be done with manual configuration, if > the device detects a potential change in location. >=20 > Richard >=20 > > -----Original Message----- > > From: Marc Berryman [mailto:MBerryman@911.org] > > Sent: Thursday, April 06, 2006 4:22 PM > > To: Marc Linsner; Andrew Newton; geopriv@ietf.org; ecrit@ietf.org > > Subject: RE: [Geopriv] static location on a mobile device > >=20 > > In the best of all worlds, the mobile device would "know"=20 > it has been > > moved and request the location information be updated (either by > manual > > update or obtaining the location from the new connection point e.g. > > wiremap). Of course this may would be the best case and not > necessarily > > the common case. > >=20 > > While it is out of the scope of this WG, we need to make=20 > sure there is > a > > consumer education / awareness aspect so the end users will=20 > know this > > may happen, and to update their location every time they move. > >=20 > > Marc B > >=20 > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Thursday, April 06, 2006 8:10 AM > > To: 'Andrew Newton'; geopriv@ietf.org; ecrit@ietf.org > > Subject: RE: [Geopriv] static location on a mobile device > >=20 > > Obviously the use case is valid. > >=20 > > Are you suggesting that the 'Manual' pidf-lo method is not=20 > sufficient > to > > cover this use case? > >=20 > > -Marc- > >=20 > > > -----Original Message----- > > > From: Andrew Newton [mailto:andy@hxr.us] > > > Sent: Thursday, April 06, 2006 8:46 AM > > > To: geopriv@ietf.org; ecrit@ietf.org > > > Subject: [Geopriv] static location on a mobile device > > > > > > [ This is being cross-posted to both GEOPRIV and ECRIT. The > > > use case is for emergency services but it deals with location. ] > > > > > > > > > Despite our best efforts, I believe in less than ideal > > > situations (and > > > there will be many) we may end up with mobile devices configured > with > > > static locations. Here is the scenario as the world works > > > today in some > > > situations: > > > > > > A user signs up for voip service. In the process of=20 > getting voip > > > service, their location is determined (either by asking the > > > user or some > > > database lookup). This location is based on the endpoint of > > > the users > > > broadband connection. > > > Now, the user takes the device associated with that > > > location to his > > > friends house. If a call is placed, the location conveyed will be > > > different than the location of the actual device. > > > > > > This is simply a fact of life. It will happen. I was > > > thinking that it > > > would be a good thing if the location could be conveyed to > > > the PSAP with > > > the following note, "This location has been configured > > > statically, but > > > the device may have been moved." Naturally, an actual > > > english message > > > is not the best thing... a well-known tag would work better > > > the world over. > > > > > > Before I jump into the solution space, I was wondering what people > > > thought of the idea. > > > > > > -andy > > > > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > >=20 > >=20 > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 117 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 16:45:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT3GO-0000XB-TJ; Mon, 10 Apr 2006 16:45:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT3GM-0000X2-UC; Mon, 10 Apr 2006 16:45:30 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT3GM-0003hl-Ez; Mon, 10 Apr 2006 16:45:30 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FT3G6-0004Hs-OE; Mon, 10 Apr 2006 15:45:16 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Stastny Richard'" , "'Marc Berryman'" , "'Marc Linsner'" , "'Andrew Newton'" , , Subject: RE: [Ecrit] RE: [Geopriv] static location on a mobile device Date: Mon, 10 Apr 2006 16:45:15 -0400 Message-ID: <063c01c65cdf$affeeda0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9888E1AA13C3A1459D122996A58C0E1107CA352C@bre2k61p-55> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZeBiUyUS5+uoNQ1ypFV5kD1vwHQAAs9yAAAJ9M2AAAGkqoADUYxxAAAHHCpA= X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org There are going to be lots of such services. This is "LAN behind a WAN" with the caveat that the whole thing can be mobile. I do think we need a flag somewhere that says "caution, location can change at any moment". I think the procedures we had in mind for emergency calls are(get your location at boot, get a mapping at boot, update your mapping at call time) would be changed by the addition of "if mobile flag is set, update location at call time" prior to "update mapping". The flag, if set, means that the AoR needs a presence service with Subscribe/Notify Brian -----Original Message----- From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] Sent: Monday, April 10, 2006 4:09 PM To: Stastny Richard; Marc Berryman; Marc Linsner; Andrew Newton; geopriv@ietf.org; ecrit@ietf.org Subject: [Ecrit] RE: [Geopriv] static location on a mobile device I'd like to suggest an additional scenario for us to consider. We (BellSouth) currently offer a "WIMAX-like" "fixed wireless" service in several cities (like New Orleans, Biloxi, etc., where much of the communications infrastructure was destroyed). The customer-side antenna for this service is rather small (about the size of a mass market paperback book) and can be run off battery power. The output of this little antenna is a RJ-45 Ethernet jack. A laptop can be plugged into this Ethernet jack. The user would then run a PPPoE client (standard feature in XP) to connect to our network. Once the network connection is established, the user can run a SIP client on the laptop. Now the user can drive all around the city and use VoIP from anywhere in a 7 square mile (or so) area. The network-side antenna is connected through ATM to our core network, and from there to the same BRASs that serve our regular DSL customers. These BRASs terminate the PPPoE sessions, just like they do for our regular DSL. The laptop and SIP client in this case have absolutely no idea that they are "mobile". All they see is an Ethernet connection, and the IP address they get from PPPoE doesn't change over the 7 sq mi. Only the user and the network are aware of the laptop's mobility. So, if we are to consider a tag or warning that originates from the client, do we also need some way for the network to tell the client that they are potentially mobile or have moved? We cannot assume that VoIP clients/devices are aware of their mobility or potential mobility. Barbara > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, April 06, 2006 10:35 AM > To: Marc Berryman; Marc Linsner; Andrew Newton; geopriv@ietf.org; > ecrit@ietf.org > Subject: RE: [Geopriv] static location on a mobile device > > > I consider a tag or warning useful not only with > static configuration, but also with dynamic configuration > > Brian is proposing in his I-D ecrit-phonebcp, > that a device immediately gets his location at > attachment time, and each time the device is moved > The device may detect this by some means, e.g. change of > IP address or change of hotspot, etc. > > What may happen here is that the device is not > able to retrieve the location at this time, so the > location information may be tagged as out-dated > until a new location information may be retrieved > > The same could be done with manual configuration, if > the device detects a potential change in location. > > Richard > > > -----Original Message----- > > From: Marc Berryman [mailto:MBerryman@911.org] > > Sent: Thursday, April 06, 2006 4:22 PM > > To: Marc Linsner; Andrew Newton; geopriv@ietf.org; ecrit@ietf.org > > Subject: RE: [Geopriv] static location on a mobile device > > > > In the best of all worlds, the mobile device would "know" > it has been > > moved and request the location information be updated (either by > manual > > update or obtaining the location from the new connection point e.g. > > wiremap). Of course this may would be the best case and not > necessarily > > the common case. > > > > While it is out of the scope of this WG, we need to make > sure there is > a > > consumer education / awareness aspect so the end users will > know this > > may happen, and to update their location every time they move. > > > > Marc B > > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Thursday, April 06, 2006 8:10 AM > > To: 'Andrew Newton'; geopriv@ietf.org; ecrit@ietf.org > > Subject: RE: [Geopriv] static location on a mobile device > > > > Obviously the use case is valid. > > > > Are you suggesting that the 'Manual' pidf-lo method is not > sufficient > to > > cover this use case? > > > > -Marc- > > > > > -----Original Message----- > > > From: Andrew Newton [mailto:andy@hxr.us] > > > Sent: Thursday, April 06, 2006 8:46 AM > > > To: geopriv@ietf.org; ecrit@ietf.org > > > Subject: [Geopriv] static location on a mobile device > > > > > > [ This is being cross-posted to both GEOPRIV and ECRIT. The > > > use case is for emergency services but it deals with location. ] > > > > > > > > > Despite our best efforts, I believe in less than ideal > > > situations (and > > > there will be many) we may end up with mobile devices configured > with > > > static locations. Here is the scenario as the world works > > > today in some > > > situations: > > > > > > A user signs up for voip service. In the process of > getting voip > > > service, their location is determined (either by asking the > > > user or some > > > database lookup). This location is based on the endpoint of > > > the users > > > broadband connection. > > > Now, the user takes the device associated with that > > > location to his > > > friends house. If a call is placed, the location conveyed will be > > > different than the location of the actual device. > > > > > > This is simply a fact of life. It will happen. I was > > > thinking that it > > > would be a good thing if the location could be conveyed to > > > the PSAP with > > > the following note, "This location has been configured > > > statically, but > > > the device may have been moved." Naturally, an actual > > > english message > > > is not the best thing... a well-known tag would work better > > > the world over. > > > > > > Before I jump into the solution space, I was wondering what people > > > thought of the idea. > > > > > > -andy > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > > _______________________________________________ > > 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 > ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 117 _______________________________________________ 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 Apr 10 19:16:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT5cp-0005Ac-Vg; Mon, 10 Apr 2006 19:16:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT5cp-00058Y-2k for ecrit@ietf.org; Mon, 10 Apr 2006 19:16:51 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT5cn-0001gS-R5 for ecrit@ietf.org; Mon, 10 Apr 2006 19:16:51 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k3ANGNo2010559; Mon, 10 Apr 2006 18:16:24 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Apr 2006 00:16:23 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0129687F0@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Rosen, Brian'" , "'Andrew Newton'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.po lice) Date: Tue, 11 Apr 2006 00:16:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.5 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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: , Errors-To: ecrit-bounces@ietf.org Can you clarify what you mean by " If you have a way to dial them now". We are talking about a substructuring of the "sos" service URN, and surely this is not meant to be about a means of being able to reach the police generally. Does any country in the world have such a level of discrimination for emergency calls? regards Keith > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: 10 April 2006 19:14 > To: Andrew Newton; Henning Schulzrinne > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > (sos.police) > > > I am sorry, but I find this logic questionable. > > There is a clear need. If you have a way to dial them now, and any of > them need accurate location based routing, then we need services for > them. You can't say because there are more than 2 of them it's too > hard. > > OTOH, it will be easy to add them, so we can punt for now > > Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Monday, April 10, 2006 10:18 AM > To: Henning Schulzrinne > Cc: Rosen, Brian; ecrit@ietf.org > Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > (sos.police) > > Henning Schulzrinne wrote: > > Thus, I suspect you have to try to find designations that are > > geographically-independent, such as > > police. transportation > > police. border > > police. campus > > police. public-housing > > police. terrorism > > > > It is not clear to me that this is practically useful, as > most people > > who need to know will be asking for ATF or FBI, rather than > trying to > > guess which label applies to which service. Others will only need > > 'police' and then be transferred to the right agency. In > the US, there > > > are likely going to be several competing agencies :-) > > I totally agree. I also can't imagine the user interface > being all that > > helpful in an emergency situation by offering a slew of sub-police > function categories. > > > > > Do we want to do this now or wait until the need arises? > > Wait. > > -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 Apr 10 19:20:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT5gi-00061w-Cb; Mon, 10 Apr 2006 19:20:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT5gg-00061r-UB for ecrit@ietf.org; Mon, 10 Apr 2006 19:20:50 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT5gg-0001r9-Lp for ecrit@ietf.org; Mon, 10 Apr 2006 19:20:50 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 18:20:50 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 10 Apr 2006 18:20:49 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 18:20:49 -0500 Message-ID: From: "Winterbottom, James" To: "Drage, Keith \(Keith\)" , "Rosen, Brian" , "Andrew Newton" , "Henning Schulzrinne" Date: Mon, 10 Apr 2006 18:20:47 -0500 Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.police) 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 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 Apr 2006 23:20:49.0428 (UTC) FILETIME=[672B6D40:01C65CF5] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.police) Thread-Index: AcZc9NuHGyUJHoI2TnCv8wSp0PDkZgAAIBHg X-Spam-Score: 0.5 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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: , Errors-To: ecrit-bounces@ietf.org Yes Japan does. Each service dialed directly. > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Tuesday, 11 April 2006 9:16 AM > To: 'Rosen, Brian'; 'Andrew Newton'; 'Henning Schulzrinne' > Cc: 'ecrit@ietf.org' > Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > (sos.police) >=20 > Can you clarify what you mean by " If you have a way to dial them now". >=20 > We are talking about a substructuring of the "sos" service URN, and surely > this is not meant to be about a means of being able to reach the police > generally. >=20 > Does any country in the world have such a level of discrimination for > emergency calls? >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > Sent: 10 April 2006 19:14 > > To: Andrew Newton; Henning Schulzrinne > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > > (sos.police) > > > > > > I am sorry, but I find this logic questionable. > > > > There is a clear need. If you have a way to dial them now, and any of > > them need accurate location based routing, then we need services for > > them. You can't say because there are more than 2 of them it's too > > hard. > > > > OTOH, it will be easy to add them, so we can punt for now > > > > Brian > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Monday, April 10, 2006 10:18 AM > > To: Henning Schulzrinne > > Cc: Rosen, Brian; ecrit@ietf.org > > Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > > (sos.police) > > > > Henning Schulzrinne wrote: > > > Thus, I suspect you have to try to find designations that are > > > geographically-independent, such as > > > police. transportation > > > police. border > > > police. campus > > > police. public-housing > > > police. terrorism > > > > > > It is not clear to me that this is practically useful, as > > most people > > > who need to know will be asking for ATF or FBI, rather than > > trying to > > > guess which label applies to which service. Others will only need > > > 'police' and then be transferred to the right agency. In > > the US, there > > > > > are likely going to be several competing agencies :-) > > > > I totally agree. I also can't imagine the user interface > > being all that > > > > helpful in an emergency situation by offering a slew of sub-police > > function categories. > > > > > > > > Do we want to do this now or wait until the need arises? > > > > Wait. > > > > -andy > > > > > > _______________________________________________ > > 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 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 19:27:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT5md-0006el-5N; Mon, 10 Apr 2006 19:26:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT5mb-0006eg-QP for ecrit@ietf.org; Mon, 10 Apr 2006 19:26:57 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT5mb-000240-HS for ecrit@ietf.org; Mon, 10 Apr 2006 19:26:57 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k3ANQmuX021252; Mon, 10 Apr 2006 18:26:48 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Apr 2006 00:26:48 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0129687F8@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Winterbottom, James" , "Drage, Keith (Keith)" , "Rosen, Brian" , Andrew Newton , Henning Schulzrinne Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.po lice) Date: Tue, 11 Apr 2006 00:26:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.5 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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: , Errors-To: ecrit-bounces@ietf.org Japan does exactly what is already covered in the URN document. The discussion being proposed is to substructure even further into types of police, and so on. Japan does not do that. regards Keith > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: 11 April 2006 00:21 > To: Drage, Keith (Keith); Rosen, Brian; Andrew Newton; Henning > Schulzrinne > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > (sos.police) > > > Yes Japan does. > Each service dialed directly. > > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Tuesday, 11 April 2006 9:16 AM > > To: 'Rosen, Brian'; 'Andrew Newton'; 'Henning Schulzrinne' > > Cc: 'ecrit@ietf.org' > > Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > > (sos.police) > > > > Can you clarify what you mean by " If you have a way to dial them > now". > > > > We are talking about a substructuring of the "sos" service URN, and > surely > > this is not meant to be about a means of being able to reach the > police > > generally. > > > > Does any country in the world have such a level of > discrimination for > > emergency calls? > > > > regards > > > > Keith > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > Sent: 10 April 2006 19:14 > > > To: Andrew Newton; Henning Schulzrinne > > > Cc: ecrit@ietf.org > > > Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > > > (sos.police) > > > > > > > > > I am sorry, but I find this logic questionable. > > > > > > There is a clear need. If you have a way to dial them > now, and any > of > > > them need accurate location based routing, then we need > services for > > > them. You can't say because there are more than 2 of > them it's too > > > hard. > > > > > > OTOH, it will be easy to add them, so we can punt for now > > > > > > Brian > > > -----Original Message----- > > > From: Andrew Newton [mailto:andy@hxr.us] > > > Sent: Monday, April 10, 2006 10:18 AM > > > To: Henning Schulzrinne > > > Cc: Rosen, Brian; ecrit@ietf.org > > > Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > > > (sos.police) > > > > > > Henning Schulzrinne wrote: > > > > Thus, I suspect you have to try to find designations that are > > > > geographically-independent, such as > > > > police. transportation > > > > police. border > > > > police. campus > > > > police. public-housing > > > > police. terrorism > > > > > > > > It is not clear to me that this is practically useful, as > > > most people > > > > who need to know will be asking for ATF or FBI, rather than > > > trying to > > > > guess which label applies to which service. Others will > only need > > > > 'police' and then be transferred to the right agency. In > > > the US, there > > > > > > > are likely going to be several competing agencies :-) > > > > > > I totally agree. I also can't imagine the user interface > > > being all that > > > > > > helpful in an emergency situation by offering a slew of sub-police > > > function categories. > > > > > > > > > > > Do we want to do this now or wait until the need arises? > > > > > > Wait. > > > > > > -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 > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 19:27:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT5nY-0006jj-JY; Mon, 10 Apr 2006 19:27:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT5nW-0006je-SI for ecrit@ietf.org; Mon, 10 Apr 2006 19:27:54 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT5nW-00024s-Hq for ecrit@ietf.org; Mon, 10 Apr 2006 19:27:54 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 18:27:54 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 10 Apr 2006 18:27:53 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 18:27:53 -0500 Message-ID: From: "Winterbottom, James" To: "Drage, Keith \(Keith\)" , "Rosen, Brian" , "Andrew Newton" , "Henning Schulzrinne" Date: Mon, 10 Apr 2006 18:27:49 -0500 Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.police) 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 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 Apr 2006 23:27:53.0037 (UTC) FILETIME=[63A907D0:01C65CF6] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.police) Thread-Index: AcZc9j6+qvGqvfFkSU+UEVr42XvBtQAABziw X-Spam-Score: 0.5 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 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: , Errors-To: ecrit-bounces@ietf.org You are right, I stand corrected. > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Tuesday, 11 April 2006 9:27 AM > To: Winterbottom, James; Drage, Keith (Keith); Rosen, Brian; Andrew > Newton; Henning Schulzrinne > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > (sos.police) >=20 > Japan does exactly what is already covered in the URN document. >=20 > The discussion being proposed is to substructure even further into types > of police, and so on. >=20 > Japan does not do that. >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: 11 April 2006 00:21 > > To: Drage, Keith (Keith); Rosen, Brian; Andrew Newton; Henning > > Schulzrinne > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > > (sos.police) > > > > > > Yes Japan does. > > Each service dialed directly. > > > > > -----Original Message----- > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > Sent: Tuesday, 11 April 2006 9:16 AM > > > To: 'Rosen, Brian'; 'Andrew Newton'; 'Henning Schulzrinne' > > > Cc: 'ecrit@ietf.org' > > > Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > > > (sos.police) > > > > > > Can you clarify what you mean by " If you have a way to dial them > > now". > > > > > > We are talking about a substructuring of the "sos" service URN, and > > surely > > > this is not meant to be about a means of being able to reach the > > police > > > generally. > > > > > > Does any country in the world have such a level of > > discrimination for > > > emergency calls? > > > > > > regards > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > > Sent: 10 April 2006 19:14 > > > > To: Andrew Newton; Henning Schulzrinne > > > > Cc: ecrit@ietf.org > > > > Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > > > > (sos.police) > > > > > > > > > > > > I am sorry, but I find this logic questionable. > > > > > > > > There is a clear need. If you have a way to dial them > > now, and any > > of > > > > them need accurate location based routing, then we need > > services for > > > > them. You can't say because there are more than 2 of > > them it's too > > > > hard. > > > > > > > > OTOH, it will be easy to add them, so we can punt for now > > > > > > > > Brian > > > > -----Original Message----- > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > Sent: Monday, April 10, 2006 10:18 AM > > > > To: Henning Schulzrinne > > > > Cc: Rosen, Brian; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > > > > (sos.police) > > > > > > > > Henning Schulzrinne wrote: > > > > > Thus, I suspect you have to try to find designations that are > > > > > geographically-independent, such as > > > > > police. transportation > > > > > police. border > > > > > police. campus > > > > > police. public-housing > > > > > police. terrorism > > > > > > > > > > It is not clear to me that this is practically useful, as > > > > most people > > > > > who need to know will be asking for ATF or FBI, rather than > > > > trying to > > > > > guess which label applies to which service. Others will > > only need > > > > > 'police' and then be transferred to the right agency. In > > > > the US, there > > > > > > > > > are likely going to be several competing agencies :-) > > > > > > > > I totally agree. I also can't imagine the user interface > > > > being all that > > > > > > > > helpful in an emergency situation by offering a slew of sub-police > > > > function categories. > > > > > > > > > > > > > > Do we want to do this now or wait until the need arises? > > > > > > > > Wait. > > > > > > > > -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 > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > > ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 10 20:55:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT7AK-0003uw-Hj; Mon, 10 Apr 2006 20:55:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT7AJ-0003uh-Pv for ecrit@ietf.org; Mon, 10 Apr 2006 20:55:31 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT7AI-0006Vy-HP for ecrit@ietf.org; Mon, 10 Apr 2006 20:55:31 -0400 Received: from [192.168.0.41] (pool-138-89-69-211.mad.east.verizon.net [138.89.69.211]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3B0tSEJ000564 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 10 Apr 2006 20:55:29 -0400 (EDT) In-Reply-To: <475FF955A05DD411980D00508B6D5FB0129687F0@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB0129687F0@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9FF092C8-8875-478B-945E-D1385281637F@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.po lice) Date: Mon, 10 Apr 2006 20:55:50 -0400 To: "Drage, Keith (Keith)" X-Mailer: Apple Mail (2.746.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.5 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: "'Rosen, Brian'" , "'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: , Errors-To: ecrit-bounces@ietf.org Besides the misunderstanding here, I think that in many cases, users will want to dial things such as "the local office of the FBI" The easiest solution for that is to send a SIP request to fbi.gov and include a location object since fbi.gov is in the best position to figure out where to send the request. This is the equivalent of the current 800# mechanism. The only real issue is the identification of police (or other services) by keywords and labels. In any event, I think there's general agreement to punt on this for now. On Apr 10, 2006, at 7:16 PM, Drage, Keith (Keith) wrote: > Can you clarify what you mean by " If you have a way to dial them > now". > > We are talking about a substructuring of the "sos" service URN, and > surely this is not meant to be about a means of being able to reach > the police generally. > > Does any country in the world have such a level of discrimination > for emergency calls? > > regards > > Keith > >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: 10 April 2006 19:14 >> To: Andrew Newton; Henning Schulzrinne >> Cc: ecrit@ietf.org >> Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 >> (sos.police) >> >> >> I am sorry, but I find this logic questionable. >> >> There is a clear need. If you have a way to dial them now, and >> any of >> them need accurate location based routing, then we need services for >> them. You can't say because there are more than 2 of them it's too >> hard. >> >> OTOH, it will be easy to add them, so we can punt for now >> >> Brian >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Monday, April 10, 2006 10:18 AM >> To: Henning Schulzrinne >> Cc: Rosen, Brian; ecrit@ietf.org >> Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 >> (sos.police) >> >> Henning Schulzrinne wrote: >>> Thus, I suspect you have to try to find designations that are >>> geographically-independent, such as >>> police. transportation >>> police. border >>> police. campus >>> police. public-housing >>> police. terrorism >>> >>> It is not clear to me that this is practically useful, as >> most people >>> who need to know will be asking for ATF or FBI, rather than >> trying to >>> guess which label applies to which service. Others will only need >>> 'police' and then be transferred to the right agency. In >> the US, there >> >>> are likely going to be several competing agencies :-) >> >> I totally agree. I also can't imagine the user interface >> being all that >> >> helpful in an emergency situation by offering a slew of sub-police >> function categories. >> >>> >>> Do we want to do this now or wait until the need arises? >> >> Wait. >> >> -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 Apr 10 21:03:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT7Hh-0001TS-4O; Mon, 10 Apr 2006 21:03:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT7Hg-0001TH-CH for ecrit@ietf.org; Mon, 10 Apr 2006 21:03:08 -0400 Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FT7Hf-00072l-T8 for ecrit@ietf.org; Mon, 10 Apr 2006 21:03:08 -0400 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-11.tower-124.messagelabs.com!1144717254!8868426!18 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30446 invoked from network); 11 Apr 2006 01:03:06 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-11.tower-124.messagelabs.com with SMTP; 11 Apr 2006 01:03:06 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh3i.attrh.att.com (7.2.052) id 4426C9FE0020866F; Mon, 10 Apr 2006 21:03:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.police) Date: Mon, 10 Apr 2006 20:03:04 -0500 Message-ID: <28F05913385EAC43AF019413F674A0170DE0C569@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB0129687F8@en0033exch001u.uk.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.police) Thread-Index: AcZc9mOvbnf5p/6wQP22XGIYHkEe1gADQ+tA From: "Dolly, Martin C, ALABS" To: "Drage, Keith \(Keith\)" , "Winterbottom, James" , "Rosen, Brian" , "Andrew Newton" , "Henning Schulzrinne" X-Spam-Score: 0.5 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de 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: , Errors-To: ecrit-bounces@ietf.org What is your point? your real point? > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Monday, April 10, 2006 7:27 PM > To: Winterbottom, James; Drage, Keith (Keith); Rosen, Brian; Andrew > Newton; Henning Schulzrinne > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > (sos.police) >=20 >=20 > Japan does exactly what is already covered in the URN document.=20 >=20 > The discussion being proposed is to substructure even further=20 > into types of police, and so on. >=20 > Japan does not do that. >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: 11 April 2006 00:21 > > To: Drage, Keith (Keith); Rosen, Brian; Andrew Newton; Henning > > Schulzrinne > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > > (sos.police) > >=20 > >=20 > > Yes Japan does. > > Each service dialed directly. > >=20 > > > -----Original Message----- > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > Sent: Tuesday, 11 April 2006 9:16 AM > > > To: 'Rosen, Brian'; 'Andrew Newton'; 'Henning Schulzrinne' > > > Cc: 'ecrit@ietf.org' > > > Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > > > (sos.police) > > >=20 > > > Can you clarify what you mean by " If you have a way to dial them > > now". > > >=20 > > > We are talking about a substructuring of the "sos"=20 > service URN, and > > surely > > > this is not meant to be about a means of being able to reach the > > police > > > generally. > > >=20 > > > Does any country in the world have such a level of=20 > > discrimination for > > > emergency calls? > > >=20 > > > regards > > >=20 > > > Keith > > >=20 > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > > Sent: 10 April 2006 19:14 > > > > To: Andrew Newton; Henning Schulzrinne > > > > Cc: ecrit@ietf.org > > > > Subject: RE: [Ecrit] Re: Review of=20 > draft-ietf-ecrit-service-urn-02 > > > > (sos.police) > > > > > > > > > > > > I am sorry, but I find this logic questionable. > > > > > > > > There is a clear need. If you have a way to dial them=20 > > now, and any > > of > > > > them need accurate location based routing, then we need=20 > > services for > > > > them. You can't say because there are more than 2 of=20 > > them it's too > > > > hard. > > > > > > > > OTOH, it will be easy to add them, so we can punt for now > > > > > > > > Brian > > > > -----Original Message----- > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > Sent: Monday, April 10, 2006 10:18 AM > > > > To: Henning Schulzrinne > > > > Cc: Rosen, Brian; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Re: Review of=20 > draft-ietf-ecrit-service-urn-02 > > > > (sos.police) > > > > > > > > Henning Schulzrinne wrote: > > > > > Thus, I suspect you have to try to find designations that are > > > > > geographically-independent, such as > > > > > police. transportation > > > > > police. border > > > > > police. campus > > > > > police. public-housing > > > > > police. terrorism > > > > > > > > > > It is not clear to me that this is practically useful, as > > > > most people > > > > > who need to know will be asking for ATF or FBI, rather than > > > > trying to > > > > > guess which label applies to which service. Others will=20 > > only need > > > > > 'police' and then be transferred to the right agency. In > > > > the US, there > > > > > > > > > are likely going to be several competing agencies :-) > > > > > > > > I totally agree. I also can't imagine the user interface > > > > being all that > > > > > > > > helpful in an emergency situation by offering a slew of=20 > sub-police > > > > function categories. > > > > > > > > > > > > > > Do we want to do this now or wait until the need arises? > > > > > > > > Wait. > > > > > > > > -andy > > > > > > > > > > > > _______________________________________________ > > > > 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 > >=20 > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. =20 > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > >=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 Mon Apr 10 21:23:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT7bd-0008KV-5E; Mon, 10 Apr 2006 21:23:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT7bc-0008KQ-MN for ecrit@ietf.org; Mon, 10 Apr 2006 21:23:44 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT7bb-0008No-FW for ecrit@ietf.org; Mon, 10 Apr 2006 21:23:44 -0400 Received: from [192.168.0.41] (pool-138-89-69-211.mad.east.verizon.net [138.89.69.211]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3B1Nen0001698 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 10 Apr 2006 21:23:42 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Mon, 10 Apr 2006 21:24:02 -0400 To: "Rosen, Brian" X-Mailer: Apple Mail (2.746.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ecrit@ietf.org Subject: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (lawyers) 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: , Errors-To: ecrit-bounces@ietf.org Maybe part of the confusion is that I meant this as an analogy. In other words, I don't this literally as translating an E.164 number. Rather, this 800# has the same properties as 411 or 911: The phone system uses location-related information (caller phone number or location) to select one of several possible destinations. In the service URN case, the N11 and 1-800-something cases would be treated similarly, as urn:service:lawyer in this case. On Apr 10, 2006, at 2:24 PM, Rosen, Brian wrote: > Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 > telephone number. To make this work using service urns, you would > have > to have the result of an enum dip for this number result in a urn that > is not currently a valid enum service. However, if you did make a new > service, it would work: > > e.164 is looked up in enum > result is service urn > urn is mapped with LoST > call is sent where indicated, based on location of caller. > > Now, the caller would have to voluntarily put location on the call for > this to work. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 11 04:53:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTEcx-0006Rn-3F; Tue, 11 Apr 2006 04:53:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTEcv-0006Ri-HY for ecrit@ietf.org; Tue, 11 Apr 2006 04:53:33 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTEcu-0007kI-3n for ecrit@ietf.org; Tue, 11 Apr 2006 04:53:33 -0400 Received: (qmail invoked by alias); 11 Apr 2006 08:53:30 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp010) with SMTP; 11 Apr 2006 10:53:30 +0200 X-Authenticated: #29516787 Message-ID: <443B6E88.8070309@gmx.net> Date: Tue, 11 Apr 2006 10:53:28 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org, mary.barnes@nortel.com, gonzalo.camarillo@ericsson.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ecrit] SIPPING-SOS 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: , Errors-To: ecrit-bounces@ietf.org Hi Gonzalo, Hi Mary, please remove the draft 'Emergency Services URI for the Session Initiation Protocol' http://www.ietf.org/internet-drafts/draft-ietf-sipping-sos-02.txt (SIPPING-SOS) from SIPPING. During the ECRIT interim meeting (and later on the mailing list) ECRIT members concluded that we want to go for 'A Uniform Resource Name (URN) for Services' http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-02.txt The work on SIPPING-SOS has been stopped already. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 11 05:14:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTEwc-0005AT-If; Tue, 11 Apr 2006 05:13:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTEwb-0005A5-3V for ecrit@ietf.org; Tue, 11 Apr 2006 05:13:53 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTEwa-0000OU-PY for ecrit@ietf.org; Tue, 11 Apr 2006 05:13:53 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k3B9DR3v010654; Tue, 11 Apr 2006 04:13:27 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Apr 2006 10:13:27 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB012968866@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Dolly, Martin C, ALABS" , "Drage, Keith (Keith)" , "Winterbottom, James" , "Rosen, Brian" , Andrew Newton , Henning Schulzrinne Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 (sos.po lice) Date: Tue, 11 Apr 2006 10:13:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.5 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff 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: , Errors-To: ecrit-bounces@ietf.org Well I guess I can see it from my original message, but essentially my meaning was that for the sos type of the service URN, I see no need to subtype beyond the level already used for emergency calls throughout the world today. The sos type is special in that these are emergency calls. Other subtypes might be used to give that level of discrimination, thus we might postulate a service type of "civic" which might include a number of different police authorities, but these would not be emergency calls. regards Keith > -----Original Message----- > From: Dolly, Martin C, ALABS [mailto:mdolly@att.com]e > Sent: 11 April 2006 02:03 > To: Drage, Keith (Keith); Winterbottom, James; Rosen, Brian; Andrew > Newton; Henning Schulzrinne > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > (sos.police) > > > What is your point? your real point? > > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Monday, April 10, 2006 7:27 PM > > To: Winterbottom, James; Drage, Keith (Keith); Rosen, Brian; Andrew > > Newton; Henning Schulzrinne > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > > (sos.police) > > > > > > Japan does exactly what is already covered in the URN document. > > > > The discussion being proposed is to substructure even further > > into types of police, and so on. > > > > Japan does not do that. > > > > regards > > > > Keith > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: 11 April 2006 00:21 > > > To: Drage, Keith (Keith); Rosen, Brian; Andrew Newton; Henning > > > Schulzrinne > > > Cc: ecrit@ietf.org > > > Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02 > > > (sos.police) > > > > > > > > > Yes Japan does. > > > Each service dialed directly. > > > > > > > -----Original Message----- > > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > > Sent: Tuesday, 11 April 2006 9:16 AM > > > > To: 'Rosen, Brian'; 'Andrew Newton'; 'Henning Schulzrinne' > > > > Cc: 'ecrit@ietf.org' > > > > Subject: RE: [Ecrit] Re: Review of > draft-ietf-ecrit-service-urn-02 > > > > (sos.police) > > > > > > > > Can you clarify what you mean by " If you have a way to > dial them > > > now". > > > > > > > > We are talking about a substructuring of the "sos" > > service URN, and > > > surely > > > > this is not meant to be about a means of being able to reach the > > > police > > > > generally. > > > > > > > > Does any country in the world have such a level of > > > discrimination for > > > > emergency calls? > > > > > > > > regards > > > > > > > > Keith > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > > > Sent: 10 April 2006 19:14 > > > > > To: Andrew Newton; Henning Schulzrinne > > > > > Cc: ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Re: Review of > > draft-ietf-ecrit-service-urn-02 > > > > > (sos.police) > > > > > > > > > > > > > > > I am sorry, but I find this logic questionable. > > > > > > > > > > There is a clear need. If you have a way to dial them > > > now, and any > > > of > > > > > them need accurate location based routing, then we need > > > services for > > > > > them. You can't say because there are more than 2 of > > > them it's too > > > > > hard. > > > > > > > > > > OTOH, it will be easy to add them, so we can punt for now > > > > > > > > > > Brian > > > > > -----Original Message----- > > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > > Sent: Monday, April 10, 2006 10:18 AM > > > > > To: Henning Schulzrinne > > > > > Cc: Rosen, Brian; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Re: Review of > > draft-ietf-ecrit-service-urn-02 > > > > > (sos.police) > > > > > > > > > > Henning Schulzrinne wrote: > > > > > > Thus, I suspect you have to try to find > designations that are > > > > > > geographically-independent, such as > > > > > > police. transportation > > > > > > police. border > > > > > > police. campus > > > > > > police. public-housing > > > > > > police. terrorism > > > > > > > > > > > > It is not clear to me that this is practically useful, as > > > > > most people > > > > > > who need to know will be asking for ATF or FBI, rather than > > > > > trying to > > > > > > guess which label applies to which service. Others will > > > only need > > > > > > 'police' and then be transferred to the right agency. In > > > > > the US, there > > > > > > > > > > > are likely going to be several competing agencies :-) > > > > > > > > > > I totally agree. I also can't imagine the user interface > > > > > being all that > > > > > > > > > > helpful in an emergency situation by offering a slew of > > sub-police > > > > > function categories. > > > > > > > > > > > > > > > > > Do we want to do this now or wait until the need arises? > > > > > > > > > > Wait. > > > > > > > > > > -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 > > > > > > -------------------------------------------------------------- > > > ---------------------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private > information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > -------------------------------------------------------------- > > > ---------------------------------- > > > [mf2] > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://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 Apr 11 09:00:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTITR-0004lG-Vc; Tue, 11 Apr 2006 09:00:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTITR-0004lB-Bk for ecrit@ietf.org; Tue, 11 Apr 2006 09:00:01 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTITQ-0000Nn-47 for ecrit@ietf.org; Tue, 11 Apr 2006 09:00:01 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3BCxmBW007557; Tue, 11 Apr 2006 12:59:48 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 08:59:47 -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 Date: Tue, 11 Apr 2006 08:59:46 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-ecrit-service-urn-02 (lawyers) Thread-Index: AcZdBpQnfP/iP4jTSBKc6lbpU1WHRQAYKnYg From: "Rosen, Brian" To: "Henning Schulzrinne" X-OriginalArrivalTime: 11 Apr 2006 12:59:47.0927 (UTC) FILETIME=[CFFF5670:01C65D67] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ecrit@ietf.org Subject: [Ecrit] RE: Review of draft-ietf-ecrit-service-urn-02 (lawyers) 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: , Errors-To: ecrit-bounces@ietf.org But I didn't.=20 There is an actual better example. In the U.S., there is a single 800 number for poison control, 1-800-222-1222. It "routes" to the "nearest" poison control center. Of course, the routing is not accurate, it depends on rate center of caller. It would be better if there was accurate routing. There is no short code for poison control, there is only the 800 number. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Monday, April 10, 2006 9:24 PM To: Rosen, Brian Cc: ecrit@ietf.org Subject: Re: Review of draft-ietf-ecrit-service-urn-02 (lawyers) Maybe part of the confusion is that I meant this as an analogy. In =20 other words, I don't this literally as translating an E.164 number. =20 Rather, this 800# has the same properties as 411 or 911: The phone =20 system uses location-related information (caller phone number or =20 location) to select one of several possible destinations. In the service URN case, the N11 and 1-800-something cases would be =20 treated similarly, as urn:service:lawyer in this case. On Apr 10, 2006, at 2:24 PM, Rosen, Brian wrote: > Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 > telephone number. To make this work using service urns, you would =20 > have > to have the result of an enum dip for this number result in a urn that > is not currently a valid enum service. However, if you did make a new > service, it would work: > > e.164 is looked up in enum > result is service urn > urn is mapped with LoST > call is sent where indicated, based on location of caller. > > Now, the caller would have to voluntarily put location on the call for > this to work. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 11 09:44:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJAj-0002w8-PN; Tue, 11 Apr 2006 09:44:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJAj-0002w3-1Y for ecrit@ietf.org; Tue, 11 Apr 2006 09:44:45 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTJAf-0002Lx-Qm for ecrit@ietf.org; Tue, 11 Apr 2006 09:44:45 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 11 Apr 2006 09:43:40 -0400 id 0158812B.443BB28C.00007905 Message-ID: <443BB2CC.6070508@hxr.us> Date: Tue, 11 Apr 2006 09:44:44 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Ecrit] ANI 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: , Errors-To: ecrit-bounces@ietf.org For the purposes of drawing similarities to current E-911, is the From header or the Contact header to be analogous to the ANI? And a slightly off-topic question... I've run into references to ANI stating it is 8 digits, 7 for the local phone number and 1 short code representing area code. Does anybody know if this is still the case? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 11 09:46:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJCL-0003ms-19; Tue, 11 Apr 2006 09:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJCJ-0003mf-LH; Tue, 11 Apr 2006 09:46:23 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTJCI-0002O1-Uw; Tue, 11 Apr 2006 09:46:23 -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 Date: Tue, 11 Apr 2006 15:50:24 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4980@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URNs in ENUM (Laywer) Thread-Index: AcZcPUX3CXeUJsZrQvO368u8xXLwsAAjVDAQACjcZq0= From: "Stastny Richard" To: "Rosen, Brian" , "Henning Schulzrinne" , X-Spam-Score: 0.5 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: ecrit@ietf.org Subject: [Ecrit] URNs in ENUM (Laywer) 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: , Errors-To: ecrit-bounces@ietf.org >Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 >telephone number. To make this work using service urns, you would have >to have the result of an enum dip for this number result in a urn that >is not currently a valid enum service. However, if you did make a new >service, it would work: Thank you for bringing this forward, I will crosspost this question to = the ENUM WG =20 I am not really sure if you need an new Enumservice at all =20 It depends if a service URN is a valid entry in a SIP URI If it is you do not even need a a new Enumservice to make this work, the "sip" Enumservice would be sufficient =20 The real problem here is again to locate the LoST service database =20 any comments here frem ENUM WG? =20 Richard ________________________________ Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Gesendet: Mo 10.04.2006 20:24 An: Henning Schulzrinne Cc: ecrit@ietf.org Betreff: [Ecrit] RE: Review of draft-ietf-ecrit-service-urn-02 Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 telephone number. To make this work using service urns, you would have to have the result of an enum dip for this number result in a urn that is not currently a valid enum service. However, if you did make a new service, it would work: e.164 is looked up in enum result is service urn urn is mapped with LoST call is sent where indicated, based on location of caller. Now, the caller would have to voluntarily put location on the call for this to work. I read: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN. =20 quite literally. urn:service.sos is a validly-assigned URN because there is an RFC that says it is (which is the same as saying it's in the IANA registry of services). "Validly-assigned" does not mean "currently active in a domain" to me. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Sunday, April 09, 2006 9:23 PM To: Rosen, Brian Cc: ecrit@ietf.org Subject: Re: Review of draft-ietf-ecrit-service-urn-02 More responses: On Apr 5, 2006, at 10:47 AM, Rosen, Brian wrote: > I have reviewed service-urn-02 and have the following comments: > > A little concerned about 1-800-LAWYER as an example. The problem here > is that there is no obvious mechanism to translate the e.164 > 1-800-LAWYER to the service urn. I suppose someone could propose an > enumservice for this purpose, but until they do, we might consider > removing this particular example Removing lawyers is always a good idea. (The similarity is that=20 dialing this number will get you a lawyer anywhere in the US, with=20 the law office depending on where you're calling from.) I don't quite=20 understand your concern about needing an enum service. > > You need a statement that points out the obvious: since the service=20 > urn > is a protocol labeling mechanism, it has no i18n implications. I'll add an I18N section. > > My biggest problem is the DDDS stuff (section 3). There is no > discussion of what domain you query the DNS for. This is an area well > worked over by other emergency stuff, and 'fragile' because what you > normally want is your "local" (as in access network) domain, and it's I don't think that's really true in general. Why should my access=20 network have better information about these services, particularly if=20 it has no interest in VoIP or emergency calls? I suspect that,=20 initially, the service lookup will be offered by the VSP. They have=20 an interest and obligation to provide the service and can't wait=20 until every last ISP has decided to provide a mapping service. > not all that easy to determine what that is. Read the HELD and LCP > documents, and the discussion about this point. I think this document > needs to handle this. I think whatever it says is likely to have=20 > to be > I didn't see any description of this in draft-winterbottom-geopriv- held-sighting-00. LCP seems to define, besides the usual suspects of=20 manual configuration and DHCP, a broadcast request, not specified=20 further. (This would be essentially a one-off version of SLP.) I think there are at least two plausible approaches to find an ISP- operated domain name, besides DHCP: (1) SLP or Bonjour; the practical problem is that SLP is seeing=20 limited new deployments and Bonjour seems to be under the cloud of=20 being non-IETF-developed (but comparatively widely deployed), with=20 the IETF competitor having been sent back to the WG for a do-over=20 (somebody might know more about this). (2) Inverse DNS: Get public IP address (via STUN, say); obtain domain=20 name (via the usual reverse DNS lookup); use SRV or NAPTR record for=20 that domain. This relies on the user's public IP address having a DNS=20 entry. As far as I can tell, this seems to be almost universally true=20 for residential broadband. (For enterprise users, I suspect that the=20 DHCP solution is easiest.) I had suggested a version of (2). > the same as any other similar mechanism in the milieu (for example,=20 > how > you find your LoST server). We need to decide what this text is, and > copy it into all the relevant documents. Actually, you find your LoST server via this mechanism, since it=20 performs the translation. > > I am confused by the "Validation Mechanism" in Section 2. First of=20 > all > the word "resource" is used here for the first time. I am assuming it > has the meaning of 3406 resource. The real problem is that the=20 > section > in 3406 that talks about validity defines it as "is there a valid > service" rather than "is the service available". Using the DDDS > mechanism would only tell you if a service was available (in the sense > of configured, rather than in the sense of functioning) within a=20 > domain. > While I think you could keep most of this text if you qualify it, I > think the actual answer is that the validation mechanism is IANA > assignment. I agree that this doesn't quite fit; I reread 3406 and 3406 defines=20 validation thusly: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN. =20 [...] This seems to imply that this mechanism would allow to determine=20 whether urn:service:timezone, say, exists or not. This would=20 presumably be done by the lookup mechanism. I'll reword the paragraph to hopefully make the distinction clearer. (more to follow) Henning _______________________________________________ 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 Apr 11 09:53:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJIz-00068X-BA; Tue, 11 Apr 2006 09:53:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJIy-00068M-8h for ecrit@ietf.org; Tue, 11 Apr 2006 09:53:16 -0400 Received: from insmtp.indigital.net ([66.249.239.11] helo=inbsf.indigital.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTJIw-0002aZ-Vk for ecrit@ietf.org; Tue, 11 Apr 2006 09:53:16 -0400 Received: from apa9.indigital.net (ns2.fwin.net [66.249.239.15]) by inbsf.indigital.net (Spam Firewall) with ESMTP id E5E28CE0B7 for ; Tue, 11 Apr 2006 09:53:12 -0400 (EDT) Received: from [66.170.32.23] (helo=[192.168.20.202]) by apa9.indigital.net with esmtpa (Exim 4.43) id 1FTJIu-00079P-SK for ecrit@ietf.org; Tue, 11 Apr 2006 09:53:12 -0400 Message-ID: <443BB4C5.3030903@indigital.net> Date: Tue, 11 Apr 2006 09:53:09 -0400 From: Byron Smith Organization: INdigital Telecom User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Ecrit@Ietf.Org" Subject: Re: [Ecrit] ANI References: <443BB2CC.6070508@hxr.us> In-Reply-To: <443BB2CC.6070508@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by INdigital SMTP Gateway at indigital.net X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bsmith@indigital.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Andrew Newton wrote: > For the purposes of drawing similarities to current E-911, is the From > header or the Contact header to be analogous to the ANI? Yes > > And a slightly off-topic question... I've run into references to ANI > stating it is 8 digits, 7 for the local phone number and 1 short code > representing area code. Does anybody know if this is still the case? > Sadly, it is the norm for CAMA (MF) trunks. In fact, many 911 switches only send a "0" in the NPD position, and ignore it on an incoming call, so separate trunk groups are required for each area code. Byron > -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 Apr 11 09:55:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJKk-0006GB-Ri; Tue, 11 Apr 2006 09:55:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJKj-0006G6-Cy for ecrit@ietf.org; Tue, 11 Apr 2006 09:55:05 -0400 Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTJKi-0002bv-0u for ecrit@ietf.org; Tue, 11 Apr 2006 09:55:05 -0400 Received: from rrc-dte-ieg01.cc.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id k3BDsw816806; Tue, 11 Apr 2006 09:54:58 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006041109545225025 ; Tue, 11 Apr 2006 09:54:52 -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, 11 Apr 2006 09:54:52 -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] ANI Date: Tue, 11 Apr 2006 09:54:52 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ANI Thread-Index: AcZdbh5lommzZGyASceaTTF9yY4AygAAMkNg From: "Abbott, Nadine B" To: "Andrew Newton" , X-OriginalArrivalTime: 11 Apr 2006 13:54:52.0766 (UTC) FILETIME=[81D5BFE0:01C65D6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: ecrit-bounces@ietf.org Hi, Andy, Originally, ANI was used in North America for billing purposes and was 7 or 1+7 digits, as you indicate. When this was adapted to deliver calling number to PSAPs, this 1+7 form was used. Some years ago this began to be upgraded to delivery of 10-digit ANI (including NPA) to PSAPs, but has not occurred everywhere.=20 Nadine =20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Andrew Newton Sent: Tuesday, April 11, 2006 9:45 AM To: ecrit@ietf.org Subject: [Ecrit] ANI For the purposes of drawing similarities to current E-911, is the From header or the Contact header to be analogous to the ANI? And a slightly off-topic question... I've run into references to ANI stating it is 8 digits, 7 for the local phone number and 1 short code representing area code. Does anybody know if this is still the case? -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 Apr 11 10:05:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJUX-0002kW-0i; Tue, 11 Apr 2006 10:05:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJUV-0002jR-SX for ecrit@ietf.org; Tue, 11 Apr 2006 10:05:11 -0400 Received: from test-iport-2.cisco.com ([171.71.176.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTJUT-0002zR-Hg for ecrit@ietf.org; Tue, 11 Apr 2006 10:05:11 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-2.cisco.com with ESMTP; 11 Apr 2006 07:05:08 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3BE58w3006642; Tue, 11 Apr 2006 07:05:08 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 07:05:08 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 07:05:07 -0700 From: "Marc Linsner" To: "'Andrew Newton'" Subject: RE: [Ecrit] ANI Date: Tue, 11 Apr 2006 10:05:03 -0400 Message-ID: <007501c65d70$eecd2560$1f0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <443BB2CC.6070508@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZdbh4izVaLK7HFQsu/ITpSTC7ZxAAAgIKg X-OriginalArrivalTime: 11 Apr 2006 14:05:07.0853 (UTC) FILETIME=[F07493D0:01C65D70] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: ecrit-bounces@ietf.org > > For the purposes of drawing similarities to current E-911, is > the From header or the Contact header to be analogous to the ANI? I believe it's From. > > And a slightly off-topic question... I've run into references > to ANI stating it is 8 digits, 7 for the local phone number > and 1 short code representing area code. Does anybody know > if this is still the case? It depends on the selective router. In addition to 7 or 8, some will accept 10 digits and a few will accept 20 digits. -Marc- > > -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 Apr 11 10:10:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJZU-0004a4-MK; Tue, 11 Apr 2006 10:10:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJZS-0004Zf-LG; Tue, 11 Apr 2006 10:10:18 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTJZR-00035C-A7; Tue, 11 Apr 2006 10:10:18 -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 Date: Tue, 11 Apr 2006 16:13:41 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4981@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] URNs in ENUM (Laywer) Thread-Index: AcZdcbZPVqVyYqDsTRK5ntV327FiUQAAGw9u From: "Stastny Richard" To: "Tony Rutkowski" , "Rosen, Brian" , "Henning Schulzrinne" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ecrit@ietf.org Subject: [Ecrit] Re: [Enum] URNs in ENUM (Laywer) 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: , Errors-To: ecrit-bounces@ietf.org NPRM, SDO, INC ? =20 Richard ________________________________ Von: Tony Rutkowski [mailto:trutkowski@verisign.com] Gesendet: Di 11.04.2006 16:06 An: Stastny Richard; Rosen, Brian; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Betreff: Re: [Enum] URNs in ENUM (Laywer) Richard et al., > >Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 > >telephone number. To make this work using service urns, you would = have > >to have the result of an enum dip for this number result in a urn = that > >is not currently a valid enum service. However, if you did make a = new > >service, it would work: Since this is an E.164 number and 800/freephone services/network elements are within the jurisdiction of the national telecom authority like the FCC, it would seem a NPRM would be necessary, followed by SDO action, e.g., INC. No? =3D=3Dtony _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 11 10:15:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJeu-00069J-5B; Tue, 11 Apr 2006 10:15:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJes-00069E-HI for ecrit@ietf.org; Tue, 11 Apr 2006 10:15:54 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTJes-0003HS-Bn for ecrit@ietf.org; Tue, 11 Apr 2006 10:15:54 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 11 Apr 2006 10:14:53 -0400 id 0158812C.443BB9DD.0000021F Message-ID: <443BBA1D.2040306@hxr.us> Date: Tue, 11 Apr 2006 10:15:57 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: bsmith@indigital.net, "Ecrit@Ietf.Org" Subject: Re: [Ecrit] ANI References: <443BB2CC.6070508@hxr.us> <443BB4C5.3030903@indigital.net> In-Reply-To: <443BB4C5.3030903@indigital.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: , Errors-To: ecrit-bounces@ietf.org Byron Smith wrote: >> And a slightly off-topic question... I've run into references to ANI >> stating it is 8 digits, 7 for the local phone number and 1 short code >> representing area code. Does anybody know if this is still the case? >> > Sadly, it is the norm for CAMA (MF) trunks. In fact, many 911 switches > only send a "0" in the NPD position, and ignore it on an incoming call, > so separate trunk groups are required for each area code. So I guess it is also true that a lot of PSAP software cannot handle expanded ANI formats, making adoption of Wireless E911 Phase I problematic. I hope somebody is reminding the vendors that they should also handle URIs. Out of curiosity, has there ever been in any attempt to solve the home/visited emergency dial plan issue in the Wireless E911 space? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 11 10:35:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJxM-0005kn-9Z; Tue, 11 Apr 2006 10:35:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJxL-0005jx-1w for ecrit@ietf.org; Tue, 11 Apr 2006 10:34:59 -0400 Received: from insmtp.indigital.net ([66.249.239.11] helo=inbsf.indigital.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTJxK-00042H-R6 for ecrit@ietf.org; Tue, 11 Apr 2006 10:34:59 -0400 Received: from apa8.indigital.net (IP-66.249.239.5.indigital.net [66.249.239.5]) by inbsf.indigital.net (Spam Firewall) with ESMTP id 5E0531372C0 for ; Tue, 11 Apr 2006 10:34:57 -0400 (EDT) Received: from [66.170.32.23] (helo=[192.168.20.202]) by apa8.indigital.net with esmtpa (Exim 4.43) id 1FTJxJ-0000Dg-91 for ecrit@ietf.org; Tue, 11 Apr 2006 10:34:57 -0400 Message-ID: <443BBE8D.9090208@indigital.net> Date: Tue, 11 Apr 2006 10:34:53 -0400 From: Byron Smith Organization: INdigital Telecom User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Ecrit@Ietf.Org" Subject: Re: [Ecrit] ANI References: <443BB2CC.6070508@hxr.us> <443BB4C5.3030903@indigital.net> <443BBA1D.2040306@hxr.us> In-Reply-To: <443BBA1D.2040306@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by INdigital SMTP Gateway at indigital.net X-Spam-Score: 0.5 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bsmith@indigital.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Andrew Newton wrote: > Byron Smith wrote: >>> And a slightly off-topic question... I've run into references to ANI >>> stating it is 8 digits, 7 for the local phone number and 1 short >>> code representing area code. Does anybody know if this is still the >>> case? >>> >> Sadly, it is the norm for CAMA (MF) trunks. In fact, many 911 >> switches only send a "0" in the NPD position, and ignore it on an >> incoming call, so separate trunk groups are required for each area code. > > So I guess it is also true that a lot of PSAP software cannot handle > expanded ANI formats, making adoption of Wireless E911 Phase I > problematic. I hope somebody is reminding the vendors that they > should also handle URIs. > > Out of curiosity, has there ever been in any attempt to solve the > home/visited emergency dial plan issue in the Wireless E911 space? > > -andy > > Perhaps I slightly over-stated the situation. A good many 911 tandem to PSAP trunks are "enhanced MF", or 10 digits. In Indiana, probably 98% of the PSAPs are 10-digit MF trunks. However, from local exchange office / or MSC to 911 tandem, easily the majority, probably 80%, are 8 digit, with the NPD = 0, unless they are using ISUP trunks. If SS7 ISUP, then it is 10 digit. Again, in Indiana, only about 15% of the incoming trunks to the 911 tandem are ISUP. The rest are MF. Out of 17 wireline 911 tandems in the state, only 3 are SS7 capable. Probably only about 5% of the inter-tandem MF trunks are 10-digits, because few of the originating switches support anything other than 0 + 7 digits for MF outpulsing. Byron _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 11 11:56:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLEb-0008T3-DD; Tue, 11 Apr 2006 11:56:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLEa-0008Sv-KY; Tue, 11 Apr 2006 11:56:52 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTLEZ-0007Iu-9R; Tue, 11 Apr 2006 11:56:52 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3BFrKBW022711; Tue, 11 Apr 2006 15:53:20 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 11:53:20 -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 Date: Tue, 11 Apr 2006 11:53:18 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URNs in ENUM (Laywer) Thread-Index: AcZcPUX3CXeUJsZrQvO368u8xXLwsAAjVDAQACjcZq0ABFuGIA== From: "Rosen, Brian" To: "Stastny Richard" , "Henning Schulzrinne" , X-OriginalArrivalTime: 11 Apr 2006 15:53:20.0168 (UTC) FILETIME=[0E2D3A80:01C65D80] X-Spam-Score: 0.5 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: ecrit@ietf.org Subject: [Ecrit] RE: URNs in ENUM (Laywer) 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: , Errors-To: ecrit-bounces@ietf.org Richard Read what I wrote. The enum dip would return urn:service.lawyer You would use LoST (not SIP) to resolve it That would resolve to a sip uri I think that's a LoST enumservice, right? Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Tuesday, April 11, 2006 9:50 AM To: Rosen, Brian; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Subject: URNs in ENUM (Laywer) >Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 >telephone number. To make this work using service urns, you would have >to have the result of an enum dip for this number result in a urn that >is not currently a valid enum service. However, if you did make a new >service, it would work: Thank you for bringing this forward, I will crosspost this question to the ENUM WG =20 I am not really sure if you need an new Enumservice at all =20 It depends if a service URN is a valid entry in a SIP URI If it is you do not even need a a new Enumservice to make this work, the "sip" Enumservice would be sufficient =20 The real problem here is again to locate the LoST service database =20 any comments here frem ENUM WG? =20 Richard ________________________________ Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Gesendet: Mo 10.04.2006 20:24 An: Henning Schulzrinne Cc: ecrit@ietf.org Betreff: [Ecrit] RE: Review of draft-ietf-ecrit-service-urn-02 Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 telephone number. To make this work using service urns, you would have to have the result of an enum dip for this number result in a urn that is not currently a valid enum service. However, if you did make a new service, it would work: e.164 is looked up in enum result is service urn urn is mapped with LoST call is sent where indicated, based on location of caller. Now, the caller would have to voluntarily put location on the call for this to work. I read: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN. =20 quite literally. urn:service.sos is a validly-assigned URN because there is an RFC that says it is (which is the same as saying it's in the IANA registry of services). "Validly-assigned" does not mean "currently active in a domain" to me. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Sunday, April 09, 2006 9:23 PM To: Rosen, Brian Cc: ecrit@ietf.org Subject: Re: Review of draft-ietf-ecrit-service-urn-02 More responses: On Apr 5, 2006, at 10:47 AM, Rosen, Brian wrote: > I have reviewed service-urn-02 and have the following comments: > > A little concerned about 1-800-LAWYER as an example. The problem here > is that there is no obvious mechanism to translate the e.164 > 1-800-LAWYER to the service urn. I suppose someone could propose an > enumservice for this purpose, but until they do, we might consider > removing this particular example Removing lawyers is always a good idea. (The similarity is that=20 dialing this number will get you a lawyer anywhere in the US, with=20 the law office depending on where you're calling from.) I don't quite=20 understand your concern about needing an enum service. > > You need a statement that points out the obvious: since the service=20 > urn > is a protocol labeling mechanism, it has no i18n implications. I'll add an I18N section. > > My biggest problem is the DDDS stuff (section 3). There is no > discussion of what domain you query the DNS for. This is an area well > worked over by other emergency stuff, and 'fragile' because what you > normally want is your "local" (as in access network) domain, and it's I don't think that's really true in general. Why should my access=20 network have better information about these services, particularly if=20 it has no interest in VoIP or emergency calls? I suspect that,=20 initially, the service lookup will be offered by the VSP. They have=20 an interest and obligation to provide the service and can't wait=20 until every last ISP has decided to provide a mapping service. > not all that easy to determine what that is. Read the HELD and LCP > documents, and the discussion about this point. I think this document > needs to handle this. I think whatever it says is likely to have=20 > to be > I didn't see any description of this in draft-winterbottom-geopriv- held-sighting-00. LCP seems to define, besides the usual suspects of=20 manual configuration and DHCP, a broadcast request, not specified=20 further. (This would be essentially a one-off version of SLP.) I think there are at least two plausible approaches to find an ISP- operated domain name, besides DHCP: (1) SLP or Bonjour; the practical problem is that SLP is seeing=20 limited new deployments and Bonjour seems to be under the cloud of=20 being non-IETF-developed (but comparatively widely deployed), with=20 the IETF competitor having been sent back to the WG for a do-over=20 (somebody might know more about this). (2) Inverse DNS: Get public IP address (via STUN, say); obtain domain=20 name (via the usual reverse DNS lookup); use SRV or NAPTR record for=20 that domain. This relies on the user's public IP address having a DNS=20 entry. As far as I can tell, this seems to be almost universally true=20 for residential broadband. (For enterprise users, I suspect that the=20 DHCP solution is easiest.) I had suggested a version of (2). > the same as any other similar mechanism in the milieu (for example,=20 > how > you find your LoST server). We need to decide what this text is, and > copy it into all the relevant documents. Actually, you find your LoST server via this mechanism, since it=20 performs the translation. > > I am confused by the "Validation Mechanism" in Section 2. First of=20 > all > the word "resource" is used here for the first time. I am assuming it > has the meaning of 3406 resource. The real problem is that the=20 > section > in 3406 that talks about validity defines it as "is there a valid > service" rather than "is the service available". Using the DDDS > mechanism would only tell you if a service was available (in the sense > of configured, rather than in the sense of functioning) within a=20 > domain. > While I think you could keep most of this text if you qualify it, I > think the actual answer is that the validation mechanism is IANA > assignment. I agree that this doesn't quite fit; I reread 3406 and 3406 defines=20 validation thusly: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN. =20 [...] This seems to imply that this mechanism would allow to determine=20 whether urn:service:timezone, say, exists or not. This would=20 presumably be done by the lookup mechanism. I'll reword the paragraph to hopefully make the distinction clearer. (more to follow) Henning _______________________________________________ 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 Apr 11 13:30:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTMh6-0006ek-PC; Tue, 11 Apr 2006 13:30:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTMh5-0006eI-Lb for ecrit@ietf.org; Tue, 11 Apr 2006 13:30:23 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTMh4-0002We-Eb for ecrit@ietf.org; Tue, 11 Apr 2006 13:30:23 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 11 Apr 2006 13:29:21 -0400 id 0158812D.443BE771.000027E9 Message-ID: <443BE7B1.4020702@hxr.us> Date: Tue, 11 Apr 2006 13:30:25 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: bsmith@indigital.net Subject: Re: [Ecrit] ANI References: <443BB2CC.6070508@hxr.us> <443BB4C5.3030903@indigital.net> <443BBA1D.2040306@hxr.us> <443BBE8D.9090208@indigital.net> In-Reply-To: <443BBE8D.9090208@indigital.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: , Errors-To: ecrit-bounces@ietf.org Byron Smith wrote: >> Out of curiosity, has there ever been in any attempt to solve the >> home/visited emergency dial plan issue in the Wireless E911 space? >> >> -andy >> >> > Perhaps I slightly over-stated the situation. > > A good many 911 tandem to PSAP trunks are "enhanced MF", or 10 digits. > In Indiana, probably 98% of the PSAPs are 10-digit MF trunks. > > However, from local exchange office / or MSC to 911 tandem, easily the > majority, probably 80%, are 8 digit, with the NPD = 0, unless they are > using ISUP trunks. If SS7 ISUP, then it is 10 digit. > Again, in Indiana, only about 15% of the incoming trunks to the 911 > tandem are ISUP. The rest are MF. Out of 17 wireline 911 tandems in > the state, only 3 are SS7 capable. Probably only about 5% of the > inter-tandem MF trunks are 10-digits, because few of the originating > switches support anything other than 0 + 7 digits for MF outpulsing. Byron, I made a slight context switch there and didn't adequately state the question. I was not actually asking about the routing aspect of a visited emergency number, though that is an issue. I was actually wondering about the recognition of a home emergency number being used in a visited network. As in, if I dial 112 in North America, does the network recognize 112 as an emergency phone number. I was just curious if there were any attempts to solve this problem in the cellular phone space. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 11 14:16:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTNPG-0008Vr-5s; Tue, 11 Apr 2006 14:16:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTNPF-0008Vm-GV for ecrit@ietf.org; Tue, 11 Apr 2006 14:16:01 -0400 Received: from insmtp.indigital.net ([66.249.239.11] helo=inbsf.indigital.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTNPF-00043M-7Y for ecrit@ietf.org; Tue, 11 Apr 2006 14:16:01 -0400 Received: from apa7.indigital.net (IP-66.249.239.5.indigital.net [66.249.239.5]) by inbsf.indigital.net (Spam Firewall) with ESMTP id 48ADACF2A9 for ; Tue, 11 Apr 2006 14:15:59 -0400 (EDT) Received: from [66.170.32.23] (helo=[192.168.20.223]) by apa7.indigital.net with esmtpa (Exim 4.43) id 1FTNPC-00072P-Vd for ecrit@ietf.org; Tue, 11 Apr 2006 14:15:59 -0400 Message-ID: <443BF25B.8060709@indigital.net> Date: Tue, 11 Apr 2006 14:15:55 -0400 From: Byron Smith Organization: INdigital Telecom User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 CC: "Ecrit@Ietf.Org" Subject: Re: [Ecrit] ANI References: <443BB2CC.6070508@hxr.us> <443BB4C5.3030903@indigital.net> <443BBA1D.2040306@hxr.us> <443BBE8D.9090208@indigital.net> <443BE7B1.4020702@hxr.us> In-Reply-To: <443BE7B1.4020702@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by INdigital SMTP Gateway at indigital.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bsmith@indigital.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Andrew Newton wrote: > Byron Smith wrote: >>> Out of curiosity, has there ever been in any attempt to solve the >>> home/visited emergency dial plan issue in the Wireless E911 space? >>> >>> -andy >>> >>> >> Perhaps I slightly over-stated the situation. >> >> A good many 911 tandem to PSAP trunks are "enhanced MF", or 10 >> digits. In Indiana, probably 98% of the PSAPs are 10-digit MF trunks. >> >> However, from local exchange office / or MSC to 911 tandem, easily >> the majority, probably 80%, are 8 digit, with the NPD = 0, unless >> they are using ISUP trunks. If SS7 ISUP, then it is 10 digit. Again, >> in Indiana, only about 15% of the incoming trunks to the 911 tandem >> are ISUP. The rest are MF. Out of 17 wireline 911 tandems in the >> state, only 3 are SS7 capable. Probably only about 5% of the >> inter-tandem MF trunks are 10-digits, because few of the originating >> switches support anything other than 0 + 7 digits for MF outpulsing. > > Byron, > > I made a slight context switch there and didn't adequately state the > question. I was not actually asking about the routing aspect of a > visited emergency number, though that is an issue. I was actually > wondering about the recognition of a home emergency number being used > in a visited network. As in, if I dial 112 in North America, does the > network recognize 112 as an emergency phone number. To my knowledge, no. Generally not in the USA. The originating host switch for the call, be it wireline or wireless, would have to have a translation to recognize, for example, 112, as an emergency call, and then route that call to an appropriate 911 destination, typically a trunk group to a 911 tandem. While there is probably nothing that would preclude a operating company from providing a 112 code translation, or other such codes, I doubt that you will find it implemented in very many switches in the US. (Actually, some codes might be a bit of a problem to implement in that they would be prefixes to local dial plans, but there are usually ways around such problems, usually involving time-outs.) The only places where I personally have seen this done is in locations that might get a lot of international visitors. For example, in the British Virgin Islands, I believe you can dial 911, 111, or 999, and get the same result. Byron > I was just curious if there were any attempts to solve this problem in > the cellular phone space. > > -andy > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 11 15:29:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOYj-00055b-6W; Tue, 11 Apr 2006 15:29:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOYi-00055W-Ge for ecrit@ietf.org; Tue, 11 Apr 2006 15:29:52 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTOYg-0006kP-8j for ecrit@ietf.org; Tue, 11 Apr 2006 15:29:52 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FTOYY-0000NL-JB; Tue, 11 Apr 2006 14:29:42 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'Andrew Newton'" Subject: RE: [Ecrit] ANI Date: Tue, 11 Apr 2006 15:29:45 -0400 Message-ID: <015c01c65d9e$4c9384f0$4fe6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <007501c65d70$eecd2560$1f0d0d0a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZdbh4izVaLK7HFQsu/ITpSTC7ZxAAAgIKgAAt/5gA= X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Depends on what you are using it for. A subscriber would use From: A network operator (and emergency calling) would use SIP Identity, or, for the time being, P-A-I Brian -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Tuesday, April 11, 2006 10:05 AM To: 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] ANI > > For the purposes of drawing similarities to current E-911, is > the From header or the Contact header to be analogous to the ANI? I believe it's From. > > And a slightly off-topic question... I've run into references > to ANI stating it is 8 digits, 7 for the local phone number > and 1 short code representing area code. Does anybody know > if this is still the case? It depends on the selective router. In addition to 7 or 8, some will accept 10 digits and a few will accept 20 digits. -Marc- > > -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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 11 15:32:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOaw-0005Ub-Dq; Tue, 11 Apr 2006 15:32:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOav-0005UW-J9 for ecrit@ietf.org; Tue, 11 Apr 2006 15:32:09 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTOau-0006py-DW for ecrit@ietf.org; Tue, 11 Apr 2006 15:32:09 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 11 Apr 2006 15:31:07 -0400 id 0158812E.443C03FB.00003F8A Message-ID: <443C043B.5090405@hxr.us> Date: Tue, 11 Apr 2006 15:32:11 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Ecrit] ANI References: <015c01c65d9e$4c9384f0$4fe6a8c0@cis.neustar.com> In-Reply-To: <015c01c65d9e$4c9384f0$4fe6a8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: , Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > Depends on what you are using it for. > > A subscriber would use From: > > A network operator (and emergency calling) would use SIP Identity, or, for > the time being, P-A-I Where have we documented this? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 11 15:32:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTObB-0005XN-M7; Tue, 11 Apr 2006 15:32:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTObA-0005XF-IH; Tue, 11 Apr 2006 15:32:24 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTObA-0006sA-9T; Tue, 11 Apr 2006 15:32:24 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FTOb1-0000Wd-3G; Tue, 11 Apr 2006 14:32:15 -0500 From: "Brian Rosen" To: "'Stastny Richard'" , "'Tony Rutkowski'" , "Rosen, Brian" , "'Henning Schulzrinne'" , Subject: RE: [Ecrit] Re: [Enum] URNs in ENUM (Laywer) Date: Tue, 11 Apr 2006 15:32:18 -0400 Message-ID: <015d01c65d9e$a7856130$4fe6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <32755D354E6B65498C3BD9FD496C7D462C4981@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZdcbZPVqVyYqDsTRK5ntV327FiUQAAGw9uAAsLPfA= X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org No, I don't think so. The number is in the NANP, and would be perfectly reasonable to exist in enum (any form of enum). The URI you get out could be a plain SIP URI, or it could be something else. One of the something else's could be a new enumservice (the LoST service) which could location-based-route the call to a SIP URI, which would then be routed as any other SIP URI would. But IANAL Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 11, 2006 10:14 AM To: Tony Rutkowski; Rosen, Brian; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] Re: [Enum] URNs in ENUM (Laywer) NPRM, SDO, INC ? Richard ________________________________ Von: Tony Rutkowski [mailto:trutkowski@verisign.com] Gesendet: Di 11.04.2006 16:06 An: Stastny Richard; Rosen, Brian; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Betreff: Re: [Enum] URNs in ENUM (Laywer) Richard et al., > >Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 > >telephone number. To make this work using service urns, you would have > >to have the result of an enum dip for this number result in a urn that > >is not currently a valid enum service. However, if you did make a new > >service, it would work: Since this is an E.164 number and 800/freephone services/network elements are within the jurisdiction of the national telecom authority like the FCC, it would seem a NPRM would be necessary, followed by SDO action, e.g., INC. No? ==tony _______________________________________________ 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 Apr 11 15:35:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOeO-00061Q-27; Tue, 11 Apr 2006 15:35:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOeM-00061L-LN for ecrit@ietf.org; Tue, 11 Apr 2006 15:35:42 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTOeL-0006yz-Cj for ecrit@ietf.org; Tue, 11 Apr 2006 15:35:42 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FTOeD-0000mt-88; Tue, 11 Apr 2006 14:35:33 -0500 From: "Brian Rosen" To: , "'Marc Linsner'" , "'Andrew Newton'" Subject: RE: [Ecrit] ANI Date: Tue, 11 Apr 2006 15:35:36 -0400 Message-ID: <015e01c65d9f$1d982010$4fe6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <015c01c65d9e$4c9384f0$4fe6a8c0@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZdbh4izVaLK7HFQsu/ITpSTC7ZxAAAgIKgAAt/5gAAADJDoA== X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Nowhere yet. It would probably go in the phone BCP (in the proxy server behavior part) and also probably in the architecture document. Don't think it would occur anywhere in any LoST work. Brian -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, April 11, 2006 3:30 PM To: 'Marc Linsner'; 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] ANI Depends on what you are using it for. A subscriber would use From: A network operator (and emergency calling) would use SIP Identity, or, for the time being, P-A-I Brian -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Tuesday, April 11, 2006 10:05 AM To: 'Andrew Newton' Cc: ecrit@ietf.org Subject: RE: [Ecrit] ANI > > For the purposes of drawing similarities to current E-911, is > the From header or the Contact header to be analogous to the ANI? I believe it's From. > > And a slightly off-topic question... I've run into references > to ANI stating it is 8 digits, 7 for the local phone number > and 1 short code representing area code. Does anybody know > if this is still the case? It depends on the selective router. In addition to 7 or 8, some will accept 10 digits and a few will accept 20 digits. -Marc- > > -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 _______________________________________________ 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 Apr 11 15:46:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOoR-0003ni-4z; Tue, 11 Apr 2006 15:46:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOoP-0003na-Tw for ecrit@ietf.org; Tue, 11 Apr 2006 15:46:05 -0400 Received: from imo-m18.mx.aol.com ([64.12.138.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTOoN-0007AE-Bn for ecrit@ietf.org; Tue, 11 Apr 2006 15:46:05 -0400 Received: from Rockford9@aol.com by imo-m18.mx.aol.com (mail_out_v38_r7.3.) id s.30e.29628a8 (17228); Tue, 11 Apr 2006 15:45:52 -0400 (EDT) From: Rockford9@aol.com Message-ID: <30e.29628a8.316d616f@aol.com> Date: Tue, 11 Apr 2006 15:45:51 EDT Subject: Re: [Ecrit] ANI To: andy@hxr.us, bsmith@indigital.net MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5021 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) 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: , Content-Type: multipart/mixed; boundary="===============0635445130==" Errors-To: ecrit-bounces@ietf.org --===============0635445130== Content-Type: multipart/alternative; boundary="-----------------------------1144784751" -------------------------------1144784751 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/11/2006 1:39:11 PM Eastern Daylight Time, andy@hxr.us writes: Byron Smith wrote: >> Out of curiosity, has there ever been in any attempt to solve the >> home/visited emergency dial plan issue in the Wireless E911 space? >> >> -andy >> >> > Perhaps I slightly over-stated the situation. > > A good many 911 tandem to PSAP trunks are "enhanced MF", or 10 digits. > In Indiana, probably 98% of the PSAPs are 10-digit MF trunks. > > However, from local exchange office / or MSC to 911 tandem, easily the > majority, probably 80%, are 8 digit, with the NPD = 0, unless they are > using ISUP trunks. If SS7 ISUP, then it is 10 digit. > Again, in Indiana, only about 15% of the incoming trunks to the 911 > tandem are ISUP. The rest are MF. Out of 17 wireline 911 tandems in > the state, only 3 are SS7 capable. Probably only about 5% of the > inter-tandem MF trunks are 10-digits, because few of the originating > switches support anything other than 0 + 7 digits for MF outpulsing. Byron, I made a slight context switch there and didn't adequately state the question. I was not actually asking about the routing aspect of a visited emergency number, though that is an issue. I was actually wondering about the recognition of a home emergency number being used in a visited network. As in, if I dial 112 in North America, does the network recognize 112 as an emergency phone number. I was just curious if there were any attempts to solve this problem in the cellular phone space. -andy It is my understanding that with at least one GSM provider (T-Mobile) 1-1-2 translates to 9-1-1 in US/Canada and vice-versa in Europe. Rick _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit -------------------------------1144784751 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
In a message dated 4/11/2006 1:39:11 PM Eastern Daylight Time, andy@hxr= .us=20 writes:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>Byron=20 Smith wrote:
>> Out of curiosity, has there ever been in any atte= mpt=20 to solve the
>> home/visited emergency dial plan issue in the=20 Wireless E911 space?
>>
>>=20 -andy
>>
>>
> Perhaps I slightly over-stated the=20 situation.
>
> A good many 911 tandem to PSAP trunks are=20 "enhanced MF", or 10 digits. 
> In Indiana, probably 98% of th= e=20 PSAPs are 10-digit MF trunks.
>
> However, from local exchang= e=20 office / or MSC to 911 tandem, easily the
> majority, probably 80%,= are=20 8 digit, with the NPD =3D 0, unless they are
> using ISUP trunks.&n= bsp;=20 If SS7 ISUP, then it is 10 digit.
> Again, in Indiana, only about 1= 5%=20 of the incoming trunks to the 911
> tandem are ISUP.  The rest= are=20 MF.   Out of 17 wireline 911 tandems in
> the state, only= 3=20 are SS7 capable.  Probably only about 5% of the
> inter-tandem= MF=20 trunks are 10-digits, because few of the originating
> switches sup= port=20 anything other than 0 + 7 digits for MF outpulsing.

Byron,

I= =20 made a slight context switch there and didn't adequately state the=20
question.  I was not actually asking about the routing aspect of=20= a=20
visited emergency number, though that is an issue.  I was actuall= y=20
wondering about the recognition of a home emergency number being used=20= in=20
a visited network.  As in, if I dial 112 in North America, does t= he=20
network recognize 112 as an emergency phone number.  I was just=20 curious
if there were any attempts to solve this problem in the cellul= ar=20 phone
space.

-andy
 
It is my understanding that with at least one GSM provider (T-Mobile) 1= -1-2=20 translates to 9-1-1 in US/Canada and vice-versa in Europe.
 
Rick
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>
_______________________________________________
Ecrit mail= ing=20 list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
=
 
-------------------------------1144784751-- --===============0635445130== 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 --===============0635445130==-- From ecrit-bounces@ietf.org Tue Apr 11 15:59:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTP1Z-0006Wx-9n; Tue, 11 Apr 2006 15:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTP1X-0006Wm-7j for ecrit@ietf.org; Tue, 11 Apr 2006 15:59:39 -0400 Received: from aismt08p.bellsouth.com ([139.76.165.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTP1V-00004r-TR for ecrit@ietf.org; Tue, 11 Apr 2006 15:59:39 -0400 Received: from ([90.152.52.46]) by aismt08p.bellsouth.com with SMTP id KP-AXPNC.127517802; Tue, 11 Apr 2006 15:59:18 -0400 Importance: normal Priority: normal Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01al10015010118.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Apr 2006 14:59:18 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 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] ANI Date: Tue, 11 Apr 2006 14:59:17 -0500 Message-ID: <9888E1AA13C3A1459D122996A58C0E11036FD0D9@bre2k61p-55> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ANI Thread-Index: AcZdjcJ4mwFkfMuiS4CdtELaic8jAgAFDitA From: "Stark, Barbara" To: "Andrew Newton" , X-OriginalArrivalTime: 11 Apr 2006 19:59:18.0309 (UTC) FILETIME=[6AB6D550:01C65DA2] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: ecrit-bounces@ietf.org > I was actually=20 > wondering about the recognition of a home emergency number=20 > being used in=20 > a visited network. As in, if I dial 112 in North America, does the=20 > network recognize 112 as an emergency phone number. I was=20 > just curious=20 > if there were any attempts to solve this problem in the=20 > cellular phone=20 > space. >=20 > -andy I can't say about other cell providers, but if you dial 112 on a GSM = phone today on the Cingular network, you'll find your call being = answered by 911. Barbara ***** "The information transmitted is intended only for the person or entity = to which it is addressed and may contain confidential, proprietary, = and/or privileged material. Any review, retransmission, dissemination = or other use of, or taking of any action in reliance upon, this = information by persons or entities other than the intended recipient is = prohibited. If you received this in error, please contact the sender = and delete the material from all computers." 118 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 11 17:59:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQtk-00051I-Jr; Tue, 11 Apr 2006 17:59:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQhI-0003E1-Mx; Tue, 11 Apr 2006 17:46:52 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTQhH-0005Ai-D5; Tue, 11 Apr 2006 17:46:52 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3BLkhNn030922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Apr 2006 14:46:46 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3BLkgVO000744; Tue, 11 Apr 2006 14:46:43 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <44353D69.5070305@hxr.us> References: <004401c6597b$6310c250$1f0d0d0a@amer.cisco.com> <44353D69.5070305@hxr.us> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 11 Apr 2006 14:44:43 -0700 To: Andrew Newton , Marc Linsner From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-Mailman-Approved-At: Tue, 11 Apr 2006 17:59:42 -0400 Cc: geopriv@ietf.org, ecrit@ietf.org Subject: [Ecrit] Re: [Geopriv] static location on a mobile device 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: , Errors-To: ecrit-bounces@ietf.org At 12:10 PM -0400 4/6/06, Andrew Newton wrote: > I'm thinking that perhaps when the registration of the device is > given, there is also a mobility capability registered with it. So > the manual configuration of location in the wifi phones says "this > is a mobile device" and my tower PC says "this is an immobile > device". How does the device know if it is mobile or not? I'm just wondering if a mobile device incorrectly marked as 'immobile' would be worse than not having the label. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Implementation is the sincerest form of flattery. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 11 17:59:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQtk-000511-Fg; Tue, 11 Apr 2006 17:59:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTK6D-00013q-L7; Tue, 11 Apr 2006 10:44:09 -0400 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTK6B-0004FL-Ae; Tue, 11 Apr 2006 10:44:09 -0400 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id k3BEjhXP028762; Tue, 11 Apr 2006 10:45:43 -0400 Received: from trutkowski-desk.verisign.com ([10.169.64.230]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 10:43:57 -0400 Message-Id: <7.0.1.0.2.20060411102750.0371e470@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 11 Apr 2006 10:43:56 -0400 To: "Stastny Richard" , "Rosen, Brian" , "Henning Schulzrinne" , From: Tony Rutkowski In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4981@oefeg-s04.oefeg.loc > References: <32755D354E6B65498C3BD9FD496C7D462C4981@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 11 Apr 2006 14:43:57.0880 (UTC) FILETIME=[5D427B80:01C65D76] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Tue, 11 Apr 2006 17:59:42 -0400 Cc: ecrit@ietf.org Subject: [Ecrit] Re: [Enum] URNs in ENUM (Laywer) 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: , Errors-To: ecrit-bounces@ietf.org Hi Richard, >NPRM Notice of Proposed Rulemaking. All changes to E.164 requirements and use in the U.S. is subject to the exclusive jurisdiction of the FCC pursuant to the Communications Act of 1996 and related judicial decisions. The FCC is obligated to proceed to make changes through a public consultative process consisting of a NPRM, followed by comments, reply comments, and implementing Orders. Some of this authority at the State level is shared with the Public Service Commissions through a separate consultative mechanism. The 800 number block and the associated services were the subject of extensive previous proceedings in conjunction with the rollout of the existing "ENUM" services based on the Intelligent Network. >SDO Standards Development Organization, e.g., ATIS, ETSI, etc. Some of these bodies have special regulatory related roles where E.164 number based resolvers/directories are concerned. >INC ? Industry Numbering Committee - an ATIS forum. See http://www.atis.org/inc/index.asp ATIS was created by the FCC at the time of the ATT breakup to serve as the industry wide forum for developing technical and administrative standards for the telecommunication infrastructure. Over the years - particularly in matters relating to signalling systems and practices, ATIS was regarded as the implementation mechanism for requirements established by the FCC. Its role is similar to both ETSI and and perhaps ERO/ENF. best, tony _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 11 17:59:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQtk-00050w-Bf; Tue, 11 Apr 2006 17:59:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJVr-0002uF-8C; Tue, 11 Apr 2006 10:06:35 -0400 Received: from peregrine.verisign.com ([216.168.239.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTJVq-000311-2q; Tue, 11 Apr 2006 10:06:35 -0400 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id k3BE7rNd007820; Tue, 11 Apr 2006 10:07:54 -0400 Received: from trutkowski-desk.verisign.com ([10.169.64.230]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 10:06:25 -0400 Message-Id: <7.0.1.0.2.20060411095756.037293d0@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 11 Apr 2006 10:06:24 -0400 To: "Stastny Richard" , "Rosen, Brian" , "Henning Schulzrinne" , From: Tony Rutkowski In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4980@oefeg-s04.oefeg.loc > References: <32755D354E6B65498C3BD9FD496C7D462C4980@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 11 Apr 2006 14:06:25.0141 (UTC) FILETIME=[1E85CA50:01C65D71] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Tue, 11 Apr 2006 17:59:42 -0400 Cc: ecrit@ietf.org Subject: [Ecrit] Re: [Enum] URNs in ENUM (Laywer) 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: , Errors-To: ecrit-bounces@ietf.org Richard et al., > >Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 > >telephone number. To make this work using service urns, you would have > >to have the result of an enum dip for this number result in a urn that > >is not currently a valid enum service. However, if you did make a new > >service, it would work: Since this is an E.164 number and 800/freephone services/network elements are within the jurisdiction of the national telecom authority like the FCC, it would seem a NPRM would be necessary, followed by SDO action, e.g., INC. No? ==tony _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 11 19:00:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRql-0007sK-Hl; Tue, 11 Apr 2006 19:00:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRqk-0007rh-K4; Tue, 11 Apr 2006 19:00:42 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTRqj-0008U7-Bt; Tue, 11 Apr 2006 19:00:42 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 18:00:41 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 11 Apr 2006 18:00:40 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 18:00:39 -0500 Message-ID: From: "Thomson, Martin" To: "Randall Gellens" , , , Date: Tue, 11 Apr 2006 18:00:39 -0500 Subject: RE: [Ecrit] RE: [Geopriv] static location on a mobile device 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 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 11 Apr 2006 23:00:39.0968 (UTC) FILETIME=[C0B03A00:01C65DBB] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] RE: [Geopriv] static location on a mobile device Thread-Index: AcZdt2fOw+ueenGqTmWJs2QpzDvthQAA2k0x 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: , Errors-To: ecrit-bounces@ietf.org It's safer to assume that the location will change. If it doesn't move, th= en you haven't lost anything. If you want to hint at this fact, you can pr= ovide more useful information by including an expiry time, so the user know= s when to re-request. That would obviate the need for a special flag. ________________________________ From: Randall Gellens [mailto:randy@qualcomm.com] Sent: Wed 4/12/2006 8:27 AM To: br@brianrosen.net; 'Stark, Barbara'; 'Stastny Richard'; 'Marc Berryman'= ; 'Marc Linsner'; 'Andrew Newton'; geopriv@ietf.org; ecrit@ietf.org Subject: RE: [Ecrit] RE: [Geopriv] static location on a mobile device At 4:45 PM -0400 4/10/06, Brian Rosen wrote: > I do think we need a flag somewhere that says "caution, location can cha= nge > at any moment". I can see how such a flag might be useful. What I was wondering about in my earlier mail was a flag that said "this device won't move", as that seems less likely to be accurate. So, the presence of your flag is a warning that the device is likely to move; its absence doesn't imply that the device won't move. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- What is mind? No matter. What is matter? Never mind. --Thomas Hewitt Key, 1799-1875 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 12 04:35:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTaoc-0003fv-5K; Wed, 12 Apr 2006 04:35:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTaoa-0003Rc-7Y; Wed, 12 Apr 2006 04:35:04 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTaoY-0004iT-Pm; Wed, 12 Apr 2006 04:35:04 -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 Date: Wed, 12 Apr 2006 10:39:04 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4983@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] URNs in ENUM (Laywer) Thread-Index: AcZddvYA/eeTkTTQTAS7ZF+xcEy/3AAlOJP/ From: "Stastny Richard" To: "Tony Rutkowski" , "Rosen, Brian" , "Henning Schulzrinne" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ecrit@ietf.org Subject: [Ecrit] Re: [Enum] URNs in ENUM (Laywer) 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: , Errors-To: ecrit-bounces@ietf.org Thanx Tony for this extensive explanations =20 So IMHO this is not so much an ENUM problem, but a problem of the definition of the service URNs =20 Before we define service URNs, we need to define what a service is ;-) =20 good luck =20 I see e.g. global services and local services all location based services are local services, as the name implies maybe we need a distinction in the service URN definition of a service is the same everywhere or if it is locally different. This also requires a definition of the related database e.g. LoST, etc. etc. =20 Richard ________________________________ Von: Tony Rutkowski [mailto:trutkowski@verisign.com] Gesendet: Di 11.04.2006 16:43 An: Stastny Richard; Rosen, Brian; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Betreff: Re: [Enum] URNs in ENUM (Laywer) Hi Richard, >NPRM Notice of Proposed Rulemaking. All changes to E.164 requirements and use in the U.S. is subject to the exclusive jurisdiction of the FCC pursuant to the Communications Act of 1996 and related judicial decisions. The FCC is obligated to proceed to make changes through a public consultative process consisting of a NPRM, followed by comments, reply comments, and implementing Orders. Some of this authority at the State level is shared with the Public Service Commissions through a separate consultative mechanism. The 800 number block and the associated services were the subject of extensive previous proceedings in conjunction with the rollout of the existing "ENUM" services based on the Intelligent Network. >SDO Standards Development Organization, e.g., ATIS, ETSI, etc. Some of these bodies have special regulatory related roles where E.164 number based resolvers/directories are concerned. >INC ? Industry Numbering Committee - an ATIS forum. See http://www.atis.org/inc/index.asp ATIS was created by the FCC at the time of the ATT breakup to serve as the industry wide forum for developing technical and administrative standards for the telecommunication infrastructure. Over the years - particularly in matters relating to signalling systems and practices, ATIS was regarded as the implementation mechanism for requirements established by the FCC. Its role is similar to both ETSI and and perhaps ERO/ENF. best, tony _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 12 04:45:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTayT-0000Q3-1i; Wed, 12 Apr 2006 04:45:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTayS-0000Pe-1U; Wed, 12 Apr 2006 04:45:16 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTayQ-0004sV-3k; Wed, 12 Apr 2006 04:45: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 Date: Wed, 12 Apr 2006 10:49:15 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4984@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URNs in ENUM (Laywer) Thread-Index: AcZcPUX3CXeUJsZrQvO368u8xXLwsAAjVDAQACjcZq0ABFuGIAAjcBs9 From: "Stastny Richard" To: "Rosen, Brian" , "Henning Schulzrinne" , X-Spam-Score: 0.5 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: ecrit@ietf.org Subject: [Ecrit] Re: URNs in ENUM (Laywer) 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: , Errors-To: ecrit-bounces@ietf.org Hmm, =20 This could be done. OTOH, do all URN:service resolve with LoST =20 This seems a bit a chicken-and-egg problem if a user enters a service URN direct, there must be a way to resolve it within e.g. SIP anyway, so why burden ENUM resolvers with service resolving do it one after the other ENUM - SIP - LoST-SIP =20 especially if the UA is not capable of doing LoST so the service URN has to be forwarded to the proxy anyway via SIP =20 Richard ________________________________ Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Gesendet: Di 11.04.2006 17:53 An: Stastny Richard; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Betreff: RE: URNs in ENUM (Laywer) Richard Read what I wrote. The enum dip would return urn:service.lawyer You would use LoST (not SIP) to resolve it That would resolve to a sip uri I think that's a LoST enumservice, right? Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 11, 2006 9:50 AM To: Rosen, Brian; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Subject: URNs in ENUM (Laywer) >Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 >telephone number. To make this work using service urns, you would have >to have the result of an enum dip for this number result in a urn that >is not currently a valid enum service. However, if you did make a new >service, it would work: Thank you for bringing this forward, I will crosspost this question to the ENUM WG I am not really sure if you need an new Enumservice at all It depends if a service URN is a valid entry in a SIP URI If it is you do not even need a a new Enumservice to make this work, the "sip" Enumservice would be sufficient The real problem here is again to locate the LoST service database any comments here frem ENUM WG? Richard ________________________________ Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Gesendet: Mo 10.04.2006 20:24 An: Henning Schulzrinne Cc: ecrit@ietf.org Betreff: [Ecrit] RE: Review of draft-ietf-ecrit-service-urn-02 Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 telephone number. To make this work using service urns, you would have to have the result of an enum dip for this number result in a urn that is not currently a valid enum service. However, if you did make a new service, it would work: e.164 is looked up in enum result is service urn urn is mapped with LoST call is sent where indicated, based on location of caller. Now, the caller would have to voluntarily put location on the call for this to work. I read: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN.=20 quite literally. urn:service.sos is a validly-assigned URN because there is an RFC that says it is (which is the same as saying it's in the IANA registry of services). "Validly-assigned" does not mean "currently active in a domain" to me. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Sunday, April 09, 2006 9:23 PM To: Rosen, Brian Cc: ecrit@ietf.org Subject: Re: Review of draft-ietf-ecrit-service-urn-02 More responses: On Apr 5, 2006, at 10:47 AM, Rosen, Brian wrote: > I have reviewed service-urn-02 and have the following comments: > > A little concerned about 1-800-LAWYER as an example. The problem here > is that there is no obvious mechanism to translate the e.164 > 1-800-LAWYER to the service urn. I suppose someone could propose an > enumservice for this purpose, but until they do, we might consider > removing this particular example Removing lawyers is always a good idea. (The similarity is that dialing this number will get you a lawyer anywhere in the US, with the law office depending on where you're calling from.) I don't quite understand your concern about needing an enum service. > > You need a statement that points out the obvious: since the service > urn > is a protocol labeling mechanism, it has no i18n implications. I'll add an I18N section. > > My biggest problem is the DDDS stuff (section 3). There is no > discussion of what domain you query the DNS for. This is an area well > worked over by other emergency stuff, and 'fragile' because what you > normally want is your "local" (as in access network) domain, and it's I don't think that's really true in general. Why should my access network have better information about these services, particularly if it has no interest in VoIP or emergency calls? I suspect that, initially, the service lookup will be offered by the VSP. They have an interest and obligation to provide the service and can't wait until every last ISP has decided to provide a mapping service. > not all that easy to determine what that is. Read the HELD and LCP > documents, and the discussion about this point. I think this document > needs to handle this. I think whatever it says is likely to have > to be > I didn't see any description of this in draft-winterbottom-geopriv- held-sighting-00. LCP seems to define, besides the usual suspects of manual configuration and DHCP, a broadcast request, not specified further. (This would be essentially a one-off version of SLP.) I think there are at least two plausible approaches to find an ISP- operated domain name, besides DHCP: (1) SLP or Bonjour; the practical problem is that SLP is seeing limited new deployments and Bonjour seems to be under the cloud of being non-IETF-developed (but comparatively widely deployed), with the IETF competitor having been sent back to the WG for a do-over (somebody might know more about this). (2) Inverse DNS: Get public IP address (via STUN, say); obtain domain name (via the usual reverse DNS lookup); use SRV or NAPTR record for that domain. This relies on the user's public IP address having a DNS entry. As far as I can tell, this seems to be almost universally true for residential broadband. (For enterprise users, I suspect that the DHCP solution is easiest.) I had suggested a version of (2). > the same as any other similar mechanism in the milieu (for example, > how > you find your LoST server). We need to decide what this text is, and > copy it into all the relevant documents. Actually, you find your LoST server via this mechanism, since it performs the translation. > > I am confused by the "Validation Mechanism" in Section 2. First of > all > the word "resource" is used here for the first time. I am assuming it > has the meaning of 3406 resource. The real problem is that the > section > in 3406 that talks about validity defines it as "is there a valid > service" rather than "is the service available". Using the DDDS > mechanism would only tell you if a service was available (in the sense > of configured, rather than in the sense of functioning) within a > domain. > While I think you could keep most of this text if you qualify it, I > think the actual answer is that the validation mechanism is IANA > assignment. I agree that this doesn't quite fit; I reread 3406 and 3406 defines validation thusly: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN.=20 [...] This seems to imply that this mechanism would allow to determine whether urn:service:timezone, say, exists or not. This would presumably be done by the lookup mechanism. I'll reword the paragraph to hopefully make the distinction clearer. (more to follow) Henning _______________________________________________ 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 Apr 12 08:16:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeGO-0005Pf-PT; Wed, 12 Apr 2006 08:16:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeGN-0005Oi-Jc; Wed, 12 Apr 2006 08:15:59 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTeGN-0003bQ-7b; Wed, 12 Apr 2006 08:15:59 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3CCFRBW027580; Wed, 12 Apr 2006 12:15:27 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 08:15:26 -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 Date: Wed, 12 Apr 2006 08:15:24 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URNs in ENUM (Laywer) Thread-Index: AcZcPUX3CXeUJsZrQvO368u8xXLwsAAjVDAQACjcZq0ABFuGIAAjcBs9AAdPaCA= From: "Rosen, Brian" To: "Stastny Richard" , "Henning Schulzrinne" , X-OriginalArrivalTime: 12 Apr 2006 12:15:26.0973 (UTC) FILETIME=[C85BBAD0:01C65E2A] X-Spam-Score: 0.5 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: ecrit@ietf.org Subject: [Ecrit] RE: URNs in ENUM (Laywer) 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: , Errors-To: ecrit-bounces@ietf.org No, not all service urns resolve with LoST; only those which are location based. There is a defined procedure to resolve a service URN. I expect the enumservice is not really a LoST service, it's a service URN service, for which there is a defined resolution process. =20 Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Wednesday, April 12, 2006 4:49 AM To: Rosen, Brian; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Subject: Re: URNs in ENUM (Laywer) Hmm, =20 This could be done. OTOH, do all URN:service resolve with LoST =20 This seems a bit a chicken-and-egg problem if a user enters a service URN direct, there must be a way to resolve it within e.g. SIP anyway, so why burden ENUM resolvers with service resolving do it one after the other ENUM - SIP - LoST-SIP =20 especially if the UA is not capable of doing LoST so the service URN has to be forwarded to the proxy anyway via SIP =20 Richard ________________________________ Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Gesendet: Di 11.04.2006 17:53 An: Stastny Richard; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Betreff: RE: URNs in ENUM (Laywer) Richard Read what I wrote. The enum dip would return urn:service.lawyer You would use LoST (not SIP) to resolve it That would resolve to a sip uri I think that's a LoST enumservice, right? Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 11, 2006 9:50 AM To: Rosen, Brian; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Subject: URNs in ENUM (Laywer) >Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 >telephone number. To make this work using service urns, you would have >to have the result of an enum dip for this number result in a urn that >is not currently a valid enum service. However, if you did make a new >service, it would work: Thank you for bringing this forward, I will crosspost this question to the ENUM WG I am not really sure if you need an new Enumservice at all It depends if a service URN is a valid entry in a SIP URI If it is you do not even need a a new Enumservice to make this work, the "sip" Enumservice would be sufficient The real problem here is again to locate the LoST service database any comments here frem ENUM WG? Richard ________________________________ Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Gesendet: Mo 10.04.2006 20:24 An: Henning Schulzrinne Cc: ecrit@ietf.org Betreff: [Ecrit] RE: Review of draft-ietf-ecrit-service-urn-02 Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 telephone number. To make this work using service urns, you would have to have the result of an enum dip for this number result in a urn that is not currently a valid enum service. However, if you did make a new service, it would work: e.164 is looked up in enum result is service urn urn is mapped with LoST call is sent where indicated, based on location of caller. Now, the caller would have to voluntarily put location on the call for this to work. I read: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN.=20 quite literally. urn:service.sos is a validly-assigned URN because there is an RFC that says it is (which is the same as saying it's in the IANA registry of services). "Validly-assigned" does not mean "currently active in a domain" to me. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Sunday, April 09, 2006 9:23 PM To: Rosen, Brian Cc: ecrit@ietf.org Subject: Re: Review of draft-ietf-ecrit-service-urn-02 More responses: On Apr 5, 2006, at 10:47 AM, Rosen, Brian wrote: > I have reviewed service-urn-02 and have the following comments: > > A little concerned about 1-800-LAWYER as an example. The problem here > is that there is no obvious mechanism to translate the e.164 > 1-800-LAWYER to the service urn. I suppose someone could propose an > enumservice for this purpose, but until they do, we might consider > removing this particular example Removing lawyers is always a good idea. (The similarity is that dialing this number will get you a lawyer anywhere in the US, with the law office depending on where you're calling from.) I don't quite understand your concern about needing an enum service. > > You need a statement that points out the obvious: since the service > urn > is a protocol labeling mechanism, it has no i18n implications. I'll add an I18N section. > > My biggest problem is the DDDS stuff (section 3). There is no > discussion of what domain you query the DNS for. This is an area well > worked over by other emergency stuff, and 'fragile' because what you > normally want is your "local" (as in access network) domain, and it's I don't think that's really true in general. Why should my access network have better information about these services, particularly if it has no interest in VoIP or emergency calls? I suspect that, initially, the service lookup will be offered by the VSP. They have an interest and obligation to provide the service and can't wait until every last ISP has decided to provide a mapping service. > not all that easy to determine what that is. Read the HELD and LCP > documents, and the discussion about this point. I think this document > needs to handle this. I think whatever it says is likely to have > to be > I didn't see any description of this in draft-winterbottom-geopriv- held-sighting-00. LCP seems to define, besides the usual suspects of manual configuration and DHCP, a broadcast request, not specified further. (This would be essentially a one-off version of SLP.) I think there are at least two plausible approaches to find an ISP- operated domain name, besides DHCP: (1) SLP or Bonjour; the practical problem is that SLP is seeing limited new deployments and Bonjour seems to be under the cloud of being non-IETF-developed (but comparatively widely deployed), with the IETF competitor having been sent back to the WG for a do-over (somebody might know more about this). (2) Inverse DNS: Get public IP address (via STUN, say); obtain domain name (via the usual reverse DNS lookup); use SRV or NAPTR record for that domain. This relies on the user's public IP address having a DNS entry. As far as I can tell, this seems to be almost universally true for residential broadband. (For enterprise users, I suspect that the DHCP solution is easiest.) I had suggested a version of (2). > the same as any other similar mechanism in the milieu (for example, > how > you find your LoST server). We need to decide what this text is, and > copy it into all the relevant documents. Actually, you find your LoST server via this mechanism, since it performs the translation. > > I am confused by the "Validation Mechanism" in Section 2. First of > all > the word "resource" is used here for the first time. I am assuming it > has the meaning of 3406 resource. The real problem is that the > section > in 3406 that talks about validity defines it as "is there a valid > service" rather than "is the service available". Using the DDDS > mechanism would only tell you if a service was available (in the sense > of configured, rather than in the sense of functioning) within a > domain. > While I think you could keep most of this text if you qualify it, I > think the actual answer is that the validation mechanism is IANA > assignment. I agree that this doesn't quite fit; I reread 3406 and 3406 defines validation thusly: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN.=20 [...] This seems to imply that this mechanism would allow to determine whether urn:service:timezone, say, exists or not. This would presumably be done by the lookup mechanism. I'll reword the paragraph to hopefully make the distinction clearer. (more to follow) Henning _______________________________________________ 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 Apr 12 10:39:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTgVb-00036b-2l; Wed, 12 Apr 2006 10:39:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTgVa-00036T-9P; Wed, 12 Apr 2006 10:39:50 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTgVZ-00081g-T6; Wed, 12 Apr 2006 10:39:50 -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 k3CEdXcL006610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Apr 2006 10:39:47 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k3CEdH28003334; Wed, 12 Apr 2006 10:39:31 -0400 Message-ID: <443D111B.7010100@cs.columbia.edu> Date: Wed, 12 Apr 2006 10:39:23 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stastny Richard References: <32755D354E6B65498C3BD9FD496C7D462C4984@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4984@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, __FRAUD_419_REFNUM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.5 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: enum@ietf.org, "Rosen, Brian" , ecrit@ietf.org Subject: [Ecrit] Re: URNs in ENUM (Laywer) 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: , Errors-To: ecrit-bounces@ietf.org Stastny Richard wrote: > Hmm, > > This could be done. OTOH, do all URN:service resolve with LoST No; each top-level service (sos, lawyer, etc.) could decide to use a different protocol. Whether all these layers of indirection are necessary and helpful is another question... > > This seems a bit a chicken-and-egg problem > if a user enters a service URN direct, there must be a way to resolve it > within e.g. SIP > anyway, so why burden ENUM resolvers with service resolving > do it one after the other ENUM - SIP - LoST-SIP > > especially if the UA is not capable of doing LoST > so the service URN has to be forwarded to the proxy anyway via SIP > > Richard > > ________________________________ > > Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Gesendet: Di 11.04.2006 17:53 > An: Stastny Richard; Henning Schulzrinne; enum@ietf.org > Cc: ecrit@ietf.org > Betreff: RE: URNs in ENUM (Laywer) > > > > Richard > > Read what I wrote. > > The enum dip would return urn:service.lawyer > You would use LoST (not SIP) to resolve it > That would resolve to a sip uri > > I think that's a LoST enumservice, right? > > Brian > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 11, 2006 9:50 AM > To: Rosen, Brian; Henning Schulzrinne; enum@ietf.org > Cc: ecrit@ietf.org > Subject: URNs in ENUM (Laywer) > >> Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 >> telephone number. To make this work using service urns, you would have >> to have the result of an enum dip for this number result in a urn that >> is not currently a valid enum service. However, if you did make a new >> service, it would work: > > Thank you for bringing this forward, I will crosspost this question to > the ENUM WG > > I am not really sure if you need an new Enumservice at all > > It depends if a service URN is a valid entry in a SIP URI > > If it is you do not even need a a new Enumservice to make this work, > the "sip" Enumservice would be sufficient > > The real problem here is again to locate the LoST service database > > any comments here frem ENUM WG? > > Richard > > > ________________________________ > > Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Gesendet: Mo 10.04.2006 20:24 > An: Henning Schulzrinne > Cc: ecrit@ietf.org > Betreff: [Ecrit] RE: Review of draft-ietf-ecrit-service-urn-02 > > > > Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 > telephone number. To make this work using service urns, you would have > to have the result of an enum dip for this number result in a urn that > is not currently a valid enum service. However, if you did make a new > service, it would work: > > e.164 is looked up in enum > result is service urn > urn is mapped with LoST > call is sent where indicated, based on location of caller. > > Now, the caller would have to voluntarily put location on the call for > this to work. > > I read: > Apart from attempting resolution of a URN, a URN namespace may > provide mechanisms for "validating" a URN -- i.e., determining > whether a given string is currently a validly-assigned URN. > > quite literally. urn:service.sos is a validly-assigned URN because > there is an RFC that says it is (which is the same as saying it's in the > IANA registry of services). "Validly-assigned" does not mean "currently > active in a domain" to me. > > Brian > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, April 09, 2006 9:23 PM > To: Rosen, Brian > Cc: ecrit@ietf.org > Subject: Re: Review of draft-ietf-ecrit-service-urn-02 > > More responses: > > On Apr 5, 2006, at 10:47 AM, Rosen, Brian wrote: > >> I have reviewed service-urn-02 and have the following comments: >> >> A little concerned about 1-800-LAWYER as an example. The problem here >> is that there is no obvious mechanism to translate the e.164 >> 1-800-LAWYER to the service urn. I suppose someone could propose an >> enumservice for this purpose, but until they do, we might consider >> removing this particular example > > Removing lawyers is always a good idea. (The similarity is that > dialing this number will get you a lawyer anywhere in the US, with > the law office depending on where you're calling from.) I don't quite > understand your concern about needing an enum service. > >> You need a statement that points out the obvious: since the service >> urn >> is a protocol labeling mechanism, it has no i18n implications. > > I'll add an I18N section. > >> My biggest problem is the DDDS stuff (section 3). There is no >> discussion of what domain you query the DNS for. This is an area well >> worked over by other emergency stuff, and 'fragile' because what you >> normally want is your "local" (as in access network) domain, and it's > > I don't think that's really true in general. Why should my access > network have better information about these services, particularly if > it has no interest in VoIP or emergency calls? I suspect that, > initially, the service lookup will be offered by the VSP. They have > an interest and obligation to provide the service and can't wait > until every last ISP has decided to provide a mapping service. > > >> not all that easy to determine what that is. Read the HELD and LCP >> documents, and the discussion about this point. I think this document >> needs to handle this. I think whatever it says is likely to have >> to be >> > > I didn't see any description of this in draft-winterbottom-geopriv- > held-sighting-00. LCP seems to define, besides the usual suspects of > manual configuration and DHCP, a broadcast request, not specified > further. (This would be essentially a one-off version of SLP.) > > I think there are at least two plausible approaches to find an ISP- > operated domain name, besides DHCP: > > (1) SLP or Bonjour; the practical problem is that SLP is seeing > limited new deployments and Bonjour seems to be under the cloud of > being non-IETF-developed (but comparatively widely deployed), with > the IETF competitor having been sent back to the WG for a do-over > (somebody might know more about this). > > (2) Inverse DNS: Get public IP address (via STUN, say); obtain domain > name (via the usual reverse DNS lookup); use SRV or NAPTR record for > that domain. This relies on the user's public IP address having a DNS > entry. As far as I can tell, this seems to be almost universally true > for residential broadband. (For enterprise users, I suspect that the > DHCP solution is easiest.) > > I had suggested a version of (2). > > >> the same as any other similar mechanism in the milieu (for example, >> how >> you find your LoST server). We need to decide what this text is, and >> copy it into all the relevant documents. > > Actually, you find your LoST server via this mechanism, since it > performs the translation. > > >> I am confused by the "Validation Mechanism" in Section 2. First of >> all >> the word "resource" is used here for the first time. I am assuming it >> has the meaning of 3406 resource. The real problem is that the >> section >> in 3406 that talks about validity defines it as "is there a valid >> service" rather than "is the service available". Using the DDDS >> mechanism would only tell you if a service was available (in the sense >> of configured, rather than in the sense of functioning) within a >> domain. >> While I think you could keep most of this text if you qualify it, I >> think the actual answer is that the validation mechanism is IANA >> assignment. > > I agree that this doesn't quite fit; I reread 3406 and 3406 defines > validation thusly: > > Apart from attempting resolution of a URN, a URN namespace may > provide mechanisms for "validating" a URN -- i.e., determining > whether a given string is currently a validly-assigned URN. > [...] > > This seems to imply that this mechanism would allow to determine > whether urn:service:timezone, say, exists or not. This would > presumably be done by the lookup mechanism. > > I'll reword the paragraph to hopefully make the distinction clearer. > > (more to follow) > > Henning > > > > > _______________________________________________ > 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 Apr 12 18:40:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTo18-0006qY-FH; Wed, 12 Apr 2006 18:40:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTo17-0006qT-J3 for ecrit@ietf.org; Wed, 12 Apr 2006 18:40:53 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTo17-0003eC-9M for ecrit@ietf.org; Wed, 12 Apr 2006 18:40:53 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k3CMepUe017458; Wed, 12 Apr 2006 17:40:52 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Apr 2006 23:40:51 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB012968AF5@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: bsmith@indigital.net Subject: RE: [Ecrit] ANI Date: Wed, 12 Apr 2006 23:40:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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: , Errors-To: ecrit-bounces@ietf.org Any GSM phone (circuit switched) without a UICC/SIM will recognise the following numbers: "The following emergency numbers shall be stored in the ME for use when no emergency numbers are stored in the SIM/USIM: 000, 08, 112, 110, 911 and 999." With a UICC/SIM you have the following: "When a SIM/USIM is present, subscriber specific emergency call set-up MMI shall be provided. The Home Environment operator shall specify preferred emergency call MMI(s) (e.g. 911 for US citizens or 110, 118 and 119 for Japanese citizens). This shall be stored in the SIM/USIM and the ME shall read this and use any entry of these digits to set up an emergency call. It shall be possible to store more than one instance of this field. " In addition, still in deployment: "The serving network may download additional emergency numbers to the UE in order to ensure that local emergency numbers are known to the UE. The UE shall regard these emergency numbers as valid in that country (as identified by the MCC) and shall discard them when a new country is entered" In the case that any of the above is dialled, an EMERGENCY SETUP is sent which contains no called party number. Over and above that, it is down to the local MSC. We are still completing the IMS bits that deal with the VoIP cases, but you can expert at least this. I have no direct knowledge of what 3GPP2 specify but I suspect it is something eq1uivalent. regards Keith > -----Original Message----- > From: Byron Smith [mailto:bsmith@indigital.net] > Sent: 11 April 2006 19:16 > Cc: Ecrit@Ietf.Org > Subject: Re: [Ecrit] ANI > > > Andrew Newton wrote: > > Byron Smith wrote: > >>> Out of curiosity, has there ever been in any attempt to solve the > >>> home/visited emergency dial plan issue in the Wireless E911 space? > >>> > >>> -andy > >>> > >>> > >> Perhaps I slightly over-stated the situation. > >> > >> A good many 911 tandem to PSAP trunks are "enhanced MF", or 10 > >> digits. In Indiana, probably 98% of the PSAPs are > 10-digit MF trunks. > >> > >> However, from local exchange office / or MSC to 911 tandem, easily > >> the majority, probably 80%, are 8 digit, with the NPD = 0, unless > >> they are using ISUP trunks. If SS7 ISUP, then it is 10 > digit. Again, > >> in Indiana, only about 15% of the incoming trunks to the > 911 tandem > >> are ISUP. The rest are MF. Out of 17 wireline 911 > tandems in the > >> state, only 3 are SS7 capable. Probably only about 5% of the > >> inter-tandem MF trunks are 10-digits, because few of the > originating > >> switches support anything other than 0 + 7 digits for MF > outpulsing. > > > > Byron, > > > > I made a slight context switch there and didn't adequately > state the > > question. I was not actually asking about the routing aspect of a > > visited emergency number, though that is an issue. I was actually > > wondering about the recognition of a home emergency number > being used > > in a visited network. As in, if I dial 112 in North > America, does the > > network recognize 112 as an emergency phone number. > To my knowledge, no. Generally not in the USA. > > The originating host switch for the call, be it wireline or wireless, > would have to have a translation to recognize, for example, > 112, as an > emergency call, and then route that call to an appropriate 911 > destination, typically a trunk group to a 911 tandem. > > While there is probably nothing that would preclude a > operating company > from providing a 112 code translation, or other such codes, I > doubt that > you will find it implemented in very many switches in the US. > (Actually, some codes might be a bit of a problem to > implement in that > they would be prefixes to local dial plans, but there are > usually ways > around such problems, usually involving time-outs.) > > The only places where I personally have seen this done is in > locations > that might get a lot of international visitors. For example, in the > British Virgin Islands, I believe you can dial 911, 111, or > 999, and get > the same result. > > Byron > > I was just curious if there were any attempts to solve this > problem in > > the cellular phone space. > > > > -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 Thu Apr 13 08:11:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU0fB-00059o-G9; Thu, 13 Apr 2006 08:11:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRML-0001uz-Qt; Tue, 11 Apr 2006 18:29:17 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTRMK-0006zT-Gr; Tue, 11 Apr 2006 18:29:17 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3BMSgXx012889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Apr 2006 15:28:43 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3BMSemq027845; Tue, 11 Apr 2006 15:28:41 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <063c01c65cdf$affeeda0$640fa8c0@cis.neustar.com> References: <063c01c65cdf$affeeda0$640fa8c0@cis.neustar.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 11 Apr 2006 15:27:27 -0700 To: br@brianrosen.net, "'Stark, Barbara'" , "'Stastny Richard'" , "'Marc Berryman'" , "'Marc Linsner'" , "'Andrew Newton'" , , From: Randall Gellens Subject: RE: [Ecrit] RE: [Geopriv] static location on a mobile device Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Thu, 13 Apr 2006 08:11:04 -0400 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: , Errors-To: ecrit-bounces@ietf.org At 4:45 PM -0400 4/10/06, Brian Rosen wrote: > I do think we need a flag somewhere that says "caution, location can change > at any moment". I can see how such a flag might be useful. What I was wondering about in my earlier mail was a flag that said "this device won't move", as that seems less likely to be accurate. So, the presence of your flag is a warning that the device is likely to move; its absence doesn't imply that the device won't move. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- What is mind? No matter. What is matter? Never mind. --Thomas Hewitt Key, 1799-1875 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 13 20:13:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUBvu-0004jd-Ri; Thu, 13 Apr 2006 20:13:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUBvt-0004eU-6c for ecrit@ietf.org; Thu, 13 Apr 2006 20:13:05 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUBvp-0001tW-GN for ecrit@ietf.org; Thu, 13 Apr 2006 20:13:03 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 13 Apr 2006 17:12:58 -0700 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 Date: Thu, 13 Apr 2006 17:12:57 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504B0065E@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT changes between -06/-07 draft requirements document - all sections Thread-Index: AcZBBpdWtFeIAJR/T7mS6cNDJsOwCAeE6LzQ From: "Roger Marshall" To: , "Hannes Tschofenig" , "Marc Linser" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Cc: Subject: [Ecrit] ECRIT changes between -06/-07 draft requirements document - all sections 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: , Errors-To: ecrit-bounces@ietf.org All: I have attempted to rewrite the first few ECRIT requirements in order that they conform to the insightful advice given by Steve Kent at IETF65 - specifically, as to how a protocol requirement should be worded. (ref. following jabber log entries: [... [10:17:23] Steve Kent says there are only two cases here: you are writing requirements for a protocol which will later design [10:17:29] or you are writing a protocol [10:17:44] The IETF uses an "implementation compliance" model for the latter. ...] Per the notes, I think were dealing with the first case, i.e., we're trying to write requirements which we will later design a protocol to. As a result of this more constrained approach, there is some significant impact to some of the original requirement(s) as written in -06. This is not necessarily a bad thing, but demands re-vetting with the wg. I've attempted to rewrite all these below from a protocol view, rather than proposing to throw out any which seem to be out of scope of a protocol design. Overall, I think the end product is more trackable, and results in less ambiguity. =20 The task is not complete, as I want to get some feedback on the direction I'm taking. Generally, Again, I think Steve's advice is essential for addressing the scope of creating a mapping protocol. =20 Each of the below changes have been listed separately in the issue-tracker (http://www.ietf-ecrit.org:8080/ecrit-req/). The following is a concatenated list made with RFC 2119 guidance in mind. [Section 4. High-Level Requirements] Issue 42. Re1. Proposed changed to text, to provide clarity to the protocol requirement and to provide context (e.g. during an emergency call): CHANGE FROM: "Re1. Application/Voice service provider: The existence of=20 an Application/Voice Service Provider (ASP/VSP)=20 SHOULD NOT be assumed. CHANGE TO: Re1. Application/Voice service provider existence: The=20 mapping protocol SHOULD NOT assume the existence of an=20 Application/Voice Service Provider (ASP/VSP) during an emergency=20 call. Issue 43. Re2. Proposed changed to text, to provide clarity to the protocol requirement: CHANGE FROM: Re2. International: Regional, political and organizational=20 aspects MUST be considered during the design of protocols and=20 protocol extensions. CHANGE TO: Re2. International applicability: The mapping protocol=20 and its extensiions MUST consider and incorporate regional, political=20 and organizational aspects during its design and development. Issue 44. Re3. Proposed changed to text, to avoid a protocol deployment requirement within a protocol design requirements document: CHANGE FROM: Re3. Distributed administration: Deployment of=20 emergency services MUST NOT depend on a sole central administration=20 authority. Motivation: Once common standards are established,=20 it must be possible to deploy and administer emergency calling=20 features on a regional or national basis without requiring coordination=20 with other regions or nations. The system cannot assume, for example,=20 that there is a single global entity issuing certificates for PSAPs, ASP/VSPs,=20 IAPs or other participants. CHANGE TO: Re3. Distributed administration: The mapping protocol design MUST NOT=20 be dependent on a sole central administration authority. Motivation: The design mapping protocol must make it possible to=20 deploy and administer emergency calling features on a regional=20 or national basis without requiring coordination with other regions=20 or nations. The system cannot assume, for example, that there is a=20 single global entity issuing certificates for PSAPs, ASP/VSPs,=20 IAPs or other participants. Issue 45. Re4. Proposed changed to text, to clarify protocol design requirements: CHANGE FROM: Re4. Multiple modes: Multiple communication modes,=20 such as audio, video and text MUST be supported (i.e.,=20 implemented in the protocol, though not necessarily used in all=20 calls). Motivation: In PSTN, voice and text telephony (often called TTY or=20 textphone in North America) are the only commonly supported media. =20 Emergency calling must support a variety of media. Such media should=20 include voice, conversational text=20 (RFC 4103), instant messaging and=20 video. CHANGE TO: Re4. Multi-mode communication: The mapping protocol MUST support=20 multiple communication modes, including, for example, audio, video and text. Motivation: In PSTN, voice and text telephony (often called TTY or=20 textphone in North America) are the only commonly supported media. =20 Emergency calling must support a variety of media. Such media should=20 include voice, conversational text=20 (RFC 4103), instant messaging and=20 video. Issue 46. Re6. Proposed changed to text, to reword title, clarify protocol design requirement language: CHANGE FROM: Re6. Differences of currency in mapping sources:=20 For alternate mapping, differences in currency between mapping data=20 contained within mapping sources SHOULD be minimized. Motivation: Alternative sources of mapping data may not have been=20 created or updated with the same set of information within the same=20 timeframe. CHANGE TO: Re6. Currency indication: The mapping protocol SHOULD=20 support an indicator describing how current the information provided by the=20 mapping source is. Motivation: This is especially useful when an alternate mapping is=20 requested, and alternative sources of mapping data may not have=20 been created or updated with the same set of information or within=20 the same timeframe. Differences in currency between mapping data=20 contained within mapping sources should be minimized. Issue 47. Re7. Proposed changed to text for minor rewording: CHANGE FROM: Re7. Mapping result usability: The ECRIT mapping=20 protocol MUST return a URI (or URIs) that are usable within a standard=20 signaling protocol (i.e., without special emergency extensions). Motivation: For example, a SIP specific URI returned by the mapping=20 protocol, needs to be usable within any SIP capable phone in a SIP=20 initiated emergency call. This is in contrast to a "special purpose" URI,=20 which may not be recognizable by a legacy SIP device. CHANGE TO: Re7. Mapping result usability: The mapping protocol=20 MUST return one or more URIs that are usable within a standard=20 signaling protocol (i.e., without special emergency extensions). Motivation: For example, a SIP specific URI which is returned by the mapping=20 protocol needs to be usable by any SIP capable phone within a SIP=20 initiated emergency call. This is in contrast to a "special purpose" URI,=20 which may not be recognizable by a legacy SIP device. Issue 48. Re8. Propose to change this requirement to make it specific to the mapping protocol, and because a general requirement for mapping information at the server is out of scope for the mapping protocol itself. CHANGE FROM: Re8. PSAP accessibility: The mapping information=20 MUST be available without having to enroll with a service provider. Motivation: The mapping server may well be operated by a service=20 provider, but access to the server offering the mapping must not=20 require use of a specific ISP or ASP/VSP. CHANGE TO: Re8. PSAP URI accessibility:"> The mapping protocol=20 MUST support interaction between the client and server where no=20 enrollment to a mapping service exists or is required. Motivation: The mapping server may well be operated by a service=20 provider, but access to the server offering the mapping must not=20 require use of a specific ISP or ASP/VSP. Issue 49. Re9. Propose to change this requirement to make it specific to the mapping protocol, and because a requirement for mapping server and it's internal database is out of scope for the mapping protocol itself. CHANGE FROM: =20 The mapping protocol SHOULD NOT require that data within=20 location databases be transformed or modified in any unusual or=20 unreasonable way in order for the mapping protocol to use the data. Motivation: Databases which contain civic addresses used within=20 location servers, may be used for multiple purposes and applications=20 beyond emergency service mapping. CHANGE TO: =20 The mapping protocol SHOULD support common data structures and=20 formats from the mapping server. Motivation: Location databases should not need to be transformed or=20 modified in any unusual or unreasonable way in order for the mapping=20 protocol to use the data. For example, a database which contains civic=20 addresses used by location servers, may be used for multiple=20 purposes and applications beyond emergency service location-to-PSAP=20 URI mapping. [Section 5. Identifying the Caller's Location] Issue 50. Lo1. Propose to change text to make it specific to the mapping protocol, and because a requirement for mapping server is out of scope. CHANGE FROM: Lo1. Reference datum: The mapping server MUST=20 implement support for the WGS-84 coordinate reference system and=20 MAY support other coordinate reference systems. CHANGE TO: Lo1. Reference datum: The mapping protocol MUST=20 support the WGS-84 coordinate reference system and=20 MAY support other coordinate reference systems. Issue 51. Lo2. Propose to change text to make it specific to the mapping protocol, and because a requirement for an ESRP is out of scope. CHANGE FROM: Lo2. Location provided: An Emergency Services=20 Routing Proxy (ESRP) MUST NOT remove location information after=20 performing location based routing. Motivation: The ESRP and the PSAP use the same location=20 information object, but for a different purpose. Therefore, the PSAP=20 still needs to receive the caller's location. CHANGE TO: Lo2. Location retained: The mapping protocol MUST=20 retain any location information which is provided to it,=20 even after a location based action is performed. Motivation: The ESRP and the PSAP use the same location=20 information object, but for a different purpose. Therefore,=20 It is imperative that the mapping protocol not remove location=20 Information so that the PSAP can still receive the caller=20 location. [Section 6. Emergency Identifier] Issue 52. Id1. Propose to change the intent of the requirement, from a phone/UA requirement to a mapping protocol requirement. The mapping protocol doesn't care what identifier is used to invoke an emergency call, except if it is slated to provide that identifier/dialstring as a response based on location. CHANGE FROM: Id1. Emergency identifier setup: One or more=20 emergency identifiers MUST be recognized by any device or=20 network element for call setup purposes. Motivation: There must be some way for any device or element to=20 recognize an emergency call throughout the call setup. This is=20 regardless of the device location, the application/voice service=20 provider used. An example of this might be "urn:service:sos". CHANGE TO: Id1. Emergency identifier support: The mapping=20 protocol MUST support one or more emergency identifiers for delivery=20 back to mapping clients to be used for call setup purposes. Motivation: Since there is a need for any device or network=20 element to recognize an emergency call throughout the call setup, there=20 is also a need to have the mapping protocol provide support for such an=20 identifier. This is regardless of the device location or the ASP/VSP used. =20 An example of this kind of identifier might be "urn:service:sos". [to be continued...] /end -Roger Marshall. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 14 11:03:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUPpI-0003Qv-Or; Fri, 14 Apr 2006 11:03:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUPpH-0003Qq-Ns for ecrit@ietf.org; Fri, 14 Apr 2006 11:03:11 -0400 Received: from mercury.sunrocket.com ([208.50.38.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUPpG-0004S7-ID for ecrit@ietf.org; Fri, 14 Apr 2006 11:03:11 -0400 Received: (qmail 27264 invoked from network); 14 Apr 2006 15:03:10 -0000 Received: from unknown (HELO [127.0.0.1]) ([172.16.10.86]) (envelope-sender ) by mercury.sunrocket.com (qmail-ldap-1.03) with SMTP for ; 14 Apr 2006 15:03:10 -0000 Message-ID: <443FB9B0.4040906@sunrocket.com> Date: Fri, 14 Apr 2006 11:03:12 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ecrit] SunRocket to support LoST/ECRIT 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: , Errors-To: ecrit-bounces@ietf.org All, This message is to inform all the people working hard within the ECRIT working group that SunRocket, one of the fastest growing voice service providers, recognizes the importance of the ECRIT work and the LoST protocol. SunRocket intends to develop software, field services, and work with the community to specify and refine LoST and other protocols related to the vitally important field of Internet-based emergency context resolution. If you have questions or comments, you may email me directly. -andy -- Andrew Newton SunRocket, Inc. http://www.sunrocket.com/ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 14 15:53:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUULk-0001tG-62; Fri, 14 Apr 2006 15:53:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUULi-0001kI-7F for ecrit@ietf.org; Fri, 14 Apr 2006 15:52:58 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FUULg-0006Ap-Rf for ecrit@ietf.org; Fri, 14 Apr 2006 15:52:57 -0400 Received: (qmail invoked by alias); 14 Apr 2006 19:52:47 -0000 Received: from ip-80-226-220-102.vodafone-net.de (EHLO [10.227.209.9]) [80.226.220.102] by mail.gmx.net (mp019) with SMTP; 14 Apr 2006 21:52:47 +0200 X-Authenticated: #29516787 Message-ID: <443FFD7E.8060007@gmx.net> Date: Fri, 14 Apr 2006 21:52:30 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall References: <8C837214C95C864C9F34F3635C2A657504B0065E@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657504B0065E@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Cc: ecrit@ietf.org Subject: [Ecrit] Re: ECRIT changes between -06/-07 draft requirements document - all sections 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: , Errors-To: ecrit-bounces@ietf.org Hi Roger, I also agree that some rewording is necessary. However, I wonder what the best approach is to make the best progress on the document. I would like to suggest the following approach based on your suggested rewording. I don't think that the wording changes the meaning of the individual requirements. Can you compile a new draft version to allow working group members to review the entire document? A question regarding the comments we received during the WGLC: Issue#31 to Issue#39 Do you think that the require a discussion on the mailing list (one by one)? If they are not resolved yet then the chairs are going to trigger a discussion on each of them in order to finalize the document. Ciao Hannes Roger Marshall wrote: > All: > I have attempted to rewrite the first few ECRIT requirements in order > that they conform to the insightful advice given by Steve Kent at IETF65 > - specifically, as to how a protocol requirement should be worded. > > (ref. following jabber log entries: > > [... > [10:17:23] Steve Kent says there are only two > cases here: you are writing requirements for a protocol which will later > design > [10:17:29] or you are writing a protocol > [10:17:44] The IETF uses an "implementation > compliance" model for the latter. > ...] > > Per the notes, I think were dealing with the first case, i.e., we're > trying to write requirements which we will later design a protocol to. > As a result of this more constrained approach, there is some significant > impact to some of the original requirement(s) as written in -06. This > is not necessarily a bad thing, but demands re-vetting with the wg. > I've attempted to rewrite all these below from a protocol view, rather > than proposing to throw out any which seem to be out of scope of a > protocol design. Overall, I think the end product is more trackable, > and results in less ambiguity. > > The task is not complete, as I want to get some feedback on the > direction I'm taking. Generally, Again, I think Steve's advice is > essential for addressing the scope of creating a mapping protocol. > > Each of the below changes have been listed separately in the > issue-tracker (http://www.ietf-ecrit.org:8080/ecrit-req/). The > following is a concatenated list made with RFC 2119 guidance in mind. > > > [Section 4. High-Level Requirements] > > Issue 42. Re1. Proposed changed to text, to provide clarity to the > protocol requirement and to provide context (e.g. during an emergency > call): > > CHANGE FROM: > "Re1. Application/Voice service provider: The existence of > an Application/Voice Service Provider (ASP/VSP) > SHOULD NOT be assumed. > > CHANGE TO: > Re1. Application/Voice service provider existence: The > mapping protocol SHOULD NOT assume the existence of an > Application/Voice Service Provider (ASP/VSP) during an emergency > call. > > > Issue 43. Re2. Proposed changed to text, to provide clarity to the > protocol requirement: > > CHANGE FROM: > Re2. International: Regional, political and organizational > aspects MUST be considered during the design of protocols and > protocol extensions. > > CHANGE TO: > Re2. International applicability: The mapping protocol > and its extensiions MUST consider and incorporate regional, political > and organizational aspects during its design and development. > > > Issue 44. Re3. Proposed changed to text, to avoid a protocol deployment > requirement within a protocol design requirements document: > > CHANGE FROM: > Re3. Distributed administration: Deployment of > emergency services MUST NOT depend on a sole central administration > authority. > > Motivation: Once common standards are established, > it must be possible to deploy and administer emergency calling > features on a regional or national basis without requiring coordination > with other regions or nations. The system cannot assume, for example, > that there is a single global entity issuing certificates for PSAPs, > ASP/VSPs, > IAPs or other participants. > > CHANGE TO: > Re3. Distributed administration: The mapping protocol design MUST NOT > be dependent on a sole central administration authority. > > Motivation: The design mapping protocol must make it possible to > deploy and administer emergency calling features on a regional > or national basis without requiring coordination with other regions > or nations. The system cannot assume, for example, that there is a > single global entity issuing certificates for PSAPs, ASP/VSPs, > IAPs or other participants. > > > Issue 45. Re4. Proposed changed to text, to clarify protocol design > requirements: > > CHANGE FROM: > Re4. Multiple modes: Multiple communication modes, > such as audio, video and text MUST be supported (i.e., > implemented in the protocol, though not necessarily used in all > calls). > > Motivation: In PSTN, voice and text telephony (often called TTY or > textphone in North America) are the only commonly supported media. > Emergency calling must support a variety of media. Such media should > include voice, conversational text > (RFC 4103), instant messaging and > video. > > CHANGE TO: > Re4. Multi-mode communication: The mapping protocol MUST support > multiple communication modes, including, for example, audio, video and > text. > > Motivation: In PSTN, voice and text telephony (often called TTY or > textphone in North America) are the only commonly supported media. > Emergency calling must support a variety of media. Such media should > include voice, conversational text > (RFC 4103), instant messaging and > video. > > > Issue 46. Re6. Proposed changed to text, to reword title, clarify > protocol design requirement language: > > CHANGE FROM: > Re6. Differences of currency in mapping sources: > For alternate mapping, differences in currency between mapping data > contained within mapping sources SHOULD be minimized. > > Motivation: Alternative sources of mapping data may not have been > created or updated with the same set of information within the same > timeframe. > > CHANGE TO: > Re6. Currency indication: The mapping protocol SHOULD > support an indicator describing how current the information provided by > the > mapping source is. > > Motivation: This is especially useful when an alternate mapping is > requested, and alternative sources of mapping data may not have > been created or updated with the same set of information or within > the same timeframe. Differences in currency between mapping data > contained within mapping sources should be minimized. > > > Issue 47. Re7. Proposed changed to text for minor rewording: > > CHANGE FROM: > Re7. Mapping result usability: The ECRIT mapping > protocol MUST return a URI (or URIs) that are usable within a standard > signaling protocol (i.e., without special emergency extensions). > > Motivation: For example, a SIP specific URI returned by the mapping > protocol, needs to be usable within any SIP capable phone in a SIP > initiated emergency call. This is in contrast to a "special purpose" > URI, > which may not be recognizable by a legacy SIP device. > > CHANGE TO: > Re7. Mapping result usability: The mapping protocol > MUST return one or more URIs that are usable within a standard > signaling protocol (i.e., without special emergency extensions). > > Motivation: For example, a SIP specific URI which is returned by the > mapping > protocol needs to be usable by any SIP capable phone within a SIP > initiated emergency call. This is in contrast to a "special purpose" > URI, > which may not be recognizable by a legacy SIP device. > > > Issue 48. Re8. Propose to change this requirement to make it specific > to the mapping protocol, and because a general requirement for mapping > information at the server is out of scope for the mapping protocol > itself. > > CHANGE FROM: > Re8. PSAP accessibility: The mapping information > MUST be available without having to enroll with 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 ASP/VSP. > > CHANGE TO: > Re8. PSAP URI accessibility:"> The mapping protocol > MUST support interaction between the client and server where no > enrollment to a mapping service exists or is required. > > 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 ASP/VSP. > > > Issue 49. Re9. Propose to change this requirement to make it specific > to the mapping protocol, and because a requirement for mapping server > and it's internal database is out of scope for the mapping protocol > itself. > > CHANGE FROM: > > The mapping protocol SHOULD NOT require that data within > location databases be transformed or modified in any unusual or > unreasonable way in order for the mapping protocol to use the data. > > Motivation: Databases which contain civic addresses used within > location servers, may be used for multiple purposes and applications > beyond emergency service mapping. > > CHANGE TO: > > The mapping protocol SHOULD support common data structures and > formats from the mapping server. > > Motivation: Location databases should not need to be transformed or > modified in any unusual or unreasonable way in order for the mapping > protocol to use the data. For example, a database which contains civic > addresses used by location servers, may be used for multiple > purposes and applications beyond emergency service location-to-PSAP > URI mapping. > > > [Section 5. Identifying the Caller's Location] > > Issue 50. Lo1. Propose to change text to make it specific to the > mapping protocol, and because a requirement for mapping server is out of > scope. > > CHANGE FROM: > Lo1. Reference datum: The mapping server MUST > implement support for the WGS-84 coordinate reference system and > MAY support other coordinate reference systems. > > CHANGE TO: > Lo1. Reference datum: The mapping protocol MUST > support the WGS-84 coordinate reference system and > MAY support other coordinate reference systems. > > > Issue 51. Lo2. Propose to change text to make it specific to the > mapping protocol, and because a requirement for an ESRP is out of scope. > > CHANGE FROM: > Lo2. Location provided: An Emergency Services > Routing Proxy (ESRP) MUST NOT remove location information after > performing location based routing. > > Motivation: The ESRP and the PSAP use the same location > information object, but for a different purpose. Therefore, the PSAP > still needs to receive the caller's location. > > CHANGE TO: > Lo2. Location retained: The mapping protocol MUST > retain any location information which is provided to it, > even after a location based action is performed. > > Motivation: The ESRP and the PSAP use the same location > information object, but for a different purpose. Therefore, > It is imperative that the mapping protocol not remove location > Information so that the PSAP can still receive the caller > location. > > > [Section 6. Emergency Identifier] > > > Issue 52. Id1. Propose to change the intent of the requirement, from a > phone/UA requirement to a mapping protocol requirement. The mapping > protocol doesn't care what identifier is used to invoke an emergency > call, except if it is slated to provide that identifier/dialstring as a > response based on location. > > CHANGE FROM: > Id1. Emergency identifier setup: One or more > emergency identifiers MUST be recognized by any device or > network element for call setup purposes. > > Motivation: There must be some way for any device or element to > recognize an emergency call throughout the call setup. This is > regardless of the device location, the application/voice service > provider used. An example of this might be "urn:service:sos". > > CHANGE TO: > Id1. Emergency identifier support: The mapping > protocol MUST support one or more emergency identifiers for delivery > back to mapping clients to be used for call setup purposes. > > Motivation: Since there is a need for any device or network > element to recognize an emergency call throughout the call setup, there > is also a need to have the mapping protocol provide support for such an > identifier. This is regardless of the device location or the ASP/VSP > used. > An example of this kind of identifier might be "urn:service:sos". > > > [to be continued...] > /end > > -Roger Marshall. > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 17 10:27:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVUhK-0002Yc-Ov; Mon, 17 Apr 2006 10:27:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVUhK-0002YX-7i for ecrit@ietf.org; Mon, 17 Apr 2006 10:27:26 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVUhH-0000xz-Ql for ecrit@ietf.org; Mon, 17 Apr 2006 10:27:26 -0400 Received: (qmail invoked by alias); 17 Apr 2006 14:27:21 -0000 Received: from ip-80-226-140-107.vodafone-net.de (EHLO [10.226.220.130]) [80.226.140.107] by mail.gmx.net (mp028) with SMTP; 17 Apr 2006 16:27:21 +0200 X-Authenticated: #29516787 Message-ID: <4443A5BE.3000004@gmx.net> Date: Mon, 17 Apr 2006 16:27:10 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) 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-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ecrit] draft-ietf-ecrit-security-threats-01.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: , Errors-To: ecrit-bounces@ietf.org Hi all, Tom has submitted a new draft version of "Security Threats and Requirements for Emergency Call Marking and Mapping": Abstract This document reviews the security threats associated with the two current work items of the ECRIT Working Group. The first is the marking of signalling messages to indicate that they are related to an emergency. The second is the process of mapping from locations to Universal Resource Identifiers (URIs) pointing to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network. Based on the threats, this document establishes a set of security requirements for the the mapping protocol and for the handling of emergency-marked calls. Please find the draft at: http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-security-threats-01.txt Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 17 10:37:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVUqr-0006IT-Ox; Mon, 17 Apr 2006 10:37:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVUqr-0006IG-2P for ecrit@ietf.org; Mon, 17 Apr 2006 10:37:17 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVUqp-0001Rg-Na for ecrit@ietf.org; Mon, 17 Apr 2006 10:37:17 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k3HEbDY18967 for ; Mon, 17 Apr 2006 10:37:13 -0400 (EDT) Received: from [127.0.0.1] ([47.130.17.172] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Apr 2006 10:36:55 -0400 Message-ID: <4443A802.6010301@nortel.com> Date: Mon, 17 Apr 2006 10:36:50 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-security-threats-01.txt References: <4443A5BE.3000004@gmx.net> In-Reply-To: <4443A5BE.3000004@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Apr 2006 14:36:55.0201 (UTC) FILETIME=[5FCD4910:01C6622C] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: , Errors-To: ecrit-bounces@ietf.org The changes between -00 and -01 are as follows: 1) Straightened out some awkward language in a couple of spots, particularly in the last few sentences of section 3. 2) Changed "ASP/VSP" to "service provider", in line with my response to Radhika Roy's request. Since the term was used only in connection with the fraud threat, the more generic term "service provider" applying to the defrauded entity should be unambiguous. 3) Most importantly, changed "the protocol" to "the protocol or the system within which it is implemented" in the requirements where it made sense. Hannes Tschofenig wrote: > Hi all, > > Tom has submitted a new draft version of "Security Threats and > Requirements for Emergency Call Marking and Mapping": > > Abstract > > This document reviews the security threats associated with the two > current work items of the ECRIT Working Group. The first is the > marking of signalling messages to indicate that they are related to > an emergency. The second is the process of mapping from locations to > Universal Resource Identifiers (URIs) pointing to Public Safety > Answering Points (PSAPs). This mapping occurs as part of the process > of routing emergency calls through the IP network. Based on the > threats, this document establishes a set of security requirements for > the the mapping protocol and for the handling of emergency-marked > calls. > > Please find the draft at: > http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-security-threats-01.txt > > 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 Apr 17 12:09:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVWI2-0000wS-1V; Mon, 17 Apr 2006 12:09:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVWI0-0000wN-DF for ecrit@ietf.org; Mon, 17 Apr 2006 12:09:24 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVWHw-0005dY-0C for ecrit@ietf.org; Mon, 17 Apr 2006 12:09:24 -0400 Received: (qmail invoked by alias); 17 Apr 2006 16:09:17 -0000 Received: from ip-80-226-210-96.vodafone-net.de (EHLO [10.226.140.112]) [80.226.210.96] by mail.gmx.net (mp043) with SMTP; 17 Apr 2006 18:09:17 +0200 X-Authenticated: #29516787 Message-ID: <4443BDA3.4000107@gmx.net> Date: Mon, 17 Apr 2006 18:09:07 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ecrit@ietf.org References: <4443A5BE.3000004@gmx.net> In-Reply-To: <4443A5BE.3000004@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ecrit] WGLC for "Security Threats and Requirements for Emergency Call Marking and Mapping" 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: , Errors-To: ecrit-bounces@ietf.org Hi all, we are now starting the Working Group Last Call on the "Security Threats and Requirements for Emergency Call Marking and Mapping" document. Here is the URL: http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-security-threats-01.txt (The draft should appear in the archive very soon.) The WGLC will end on April 28th, 2006. Please review this document and post your review results to the list (even if you found no complaints). Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 17 12:21:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVWTc-0003Tx-0K; Mon, 17 Apr 2006 12:21:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVWTa-0003Tm-TB for ecrit@ietf.org; Mon, 17 Apr 2006 12:21:22 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVWTZ-0006O1-44 for ecrit@ietf.org; Mon, 17 Apr 2006 12:21:22 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 17 Apr 2006 09:21:17 -0700 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 Date: Mon, 17 Apr 2006 09:21:17 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504B4EE4B@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT changes between -06/-07 draft requirements document - all sections Thread-Index: AcZf/QvbfJfwxxMTTCKOPvqa42GOlgCPQDjA From: "Roger Marshall" To: "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b Cc: ecrit@ietf.org Subject: [Ecrit] RE: ECRIT changes between -06/-07 draft requirements document - all sections 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: , Errors-To: ecrit-bounces@ietf.org Hannes: I will compile a completed draft soon, based on the 2119 rewrites. Yes, my goal is to have each requirement say something close to the same thing, but this is sometimes challenging when going from a statement about the mapping server to the mapping protocol, for example. Though I think that Issues 35, 38, and 39 may need special attention (i.e. a champion), I will attempt to clarify each, and so will include in the next version to get published. Regards, Roger Marshall.=20 >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: Friday, April 14, 2006 12:53 PM >To: Roger Marshall >Cc: ecrit@ietf.org; Marc Linser >Subject: Re: ECRIT changes between -06/-07 draft requirements=20 >document - all sections > >Hi Roger, > >I also agree that some rewording is necessary. >However, I wonder what the best approach is to make the best=20 >progress on the document. > >I would like to suggest the following approach based on your=20 >suggested rewording. I don't think that the wording changes=20 >the meaning of the individual requirements. > >Can you compile a new draft version to allow working group=20 >members to review the entire document? > >A question regarding the comments we received during the WGLC:=20 >Issue#31 to Issue#39 Do you think that the require a=20 >discussion on the mailing list (one by one)? If they are not=20 >resolved yet then the chairs are going to trigger a discussion=20 >on each of them in order to finalize the document. > >Ciao >Hannes > > > >Roger Marshall wrote: >> All: >> I have attempted to rewrite the first few ECRIT requirements=20 >in order=20 >> that they conform to the insightful advice given by Steve Kent at=20 >> IETF65 >> - specifically, as to how a protocol requirement should be worded. >>=20 >> (ref. following jabber log entries: >>=20 >> [... >> [10:17:23] Steve Kent says there are=20 >only two=20 >> cases here: you are writing requirements for a protocol which will=20 >> later design [10:17:29] or you are writing a=20 >> protocol [10:17:44] The IETF uses an=20 >> "implementation compliance" model for the latter. >> ...] >>=20 >> Per the notes, I think were dealing with the first case, i.e., we're=20 >> trying to write requirements which we will later design a=20 >protocol to. >> As a result of this more constrained approach, there is some=20 >> significant impact to some of the original requirement(s) as=20 > written=20 >> in -06. This is not necessarily a bad thing, but demands=20 >re-vetting with the wg. >> I've attempted to rewrite all these below from a protocol=20 >view, rather=20 >> than proposing to throw out any which seem to be out of scope of a=20 >> protocol design. Overall, I think the end product is more=20 >trackable,=20 >> and results in less ambiguity. >>=20 >> The task is not complete, as I want to get some feedback on the=20 >> direction I'm taking. Generally, Again, I think Steve's advice is=20 >> essential for addressing the scope of creating a mapping protocol. >>=20 >> Each of the below changes have been listed separately in the=20 >> issue-tracker (http://www.ietf-ecrit.org:8080/ecrit-req/). The=20 >> following is a concatenated list made with RFC 2119 guidance in mind. >>=20 >>=20 >> [Section 4. High-Level Requirements] >>=20 >> Issue 42. Re1. Proposed changed to text, to provide clarity to the=20 >> protocol requirement and to provide context (e.g. during an emergency >> call): >>=20 >> CHANGE FROM: >> "Re1. Application/Voice service provider: The existence of an=20 >> Application/Voice Service Provider (ASP/VSP) SHOULD NOT be assumed. >>=20 >> CHANGE TO: >> Re1. Application/Voice service provider existence: The mapping=20 >> protocol SHOULD NOT assume the existence of an Application/Voice=20 >> Service Provider (ASP/VSP) during an emergency call. >>=20 >>=20 >> Issue 43. Re2. Proposed changed to text, to provide clarity to the >> protocol requirement: >>=20 >> CHANGE FROM: >> Re2. International: Regional, political and organizational=20 >> aspects MUST be considered during the design of protocols and=20 >> protocol extensions. >>=20 >> CHANGE TO: >> Re2. International applicability: The mapping protocol=20 >> and its extensiions MUST consider and incorporate regional,=20 >political=20 >> and organizational aspects during its design and development. >>=20 >>=20 >> Issue 44. Re3. Proposed changed to text, to avoid a=20 >protocol deployment >> requirement within a protocol design requirements document: >>=20 >> CHANGE FROM: >> Re3. Distributed administration: Deployment of=20 >> emergency services MUST NOT depend on a sole central administration=20 >> authority. >>=20 >> Motivation: Once common standards are established,=20 >> it must be possible to deploy and administer emergency calling=20 >> features on a regional or national basis without requiring=20 >coordination=20 >> with other regions or nations. The system cannot assume,=20 >for example,=20 >> that there is a single global entity issuing certificates for PSAPs, >> ASP/VSPs,=20 >> IAPs or other participants. >>=20 >> CHANGE TO: >> Re3. Distributed administration: The mapping protocol=20 >design MUST NOT=20 >> be dependent on a sole central administration authority. >>=20 >> Motivation: The design mapping protocol must make it possible to=20 >> deploy and administer emergency calling features on a regional=20 >> or national basis without requiring coordination with other regions=20 >> or nations. The system cannot assume, for example, that there is a=20 >> single global entity issuing certificates for PSAPs, ASP/VSPs,=20 >> IAPs or other participants. >>=20 >>=20 >> Issue 45. Re4. Proposed changed to text, to clarify protocol design >> requirements: >>=20 >> CHANGE FROM: >> Re4. Multiple modes: Multiple communication modes,=20 >> such as audio, video and text MUST be supported (i.e.,=20 >> implemented in the protocol, though not necessarily used in all=20 >> calls). >>=20 >> Motivation: In PSTN, voice and text telephony (often called TTY or=20 >> textphone in North America) are the only commonly supported media. =20 >> Emergency calling must support a variety of media. Such media should=20 >> include voice, conversational text=20 >> (RFC 4103), instant messaging and=20 >> video. >>=20 >> CHANGE TO: >> Re4. Multi-mode communication: The mapping protocol MUST support=20 >> multiple communication modes, including, for example, audio,=20 >video and >> text. >>=20 >> Motivation: In PSTN, voice and text telephony (often called TTY or=20 >> textphone in North America) are the only commonly supported media. =20 >> Emergency calling must support a variety of media. Such media should=20 >> include voice, conversational text=20 >> (RFC 4103), instant messaging and=20 >> video. >>=20 >>=20 >> Issue 46. Re6. Proposed changed to text, to reword title, clarify >> protocol design requirement language: >>=20 >> CHANGE FROM: >> Re6. Differences of currency in mapping sources:=20 >> For alternate mapping, differences in currency between mapping data=20 >> contained within mapping sources SHOULD be minimized. >>=20 >> Motivation: Alternative sources of mapping data may not have been=20 >> created or updated with the same set of information within the same=20 >> timeframe. >>=20 >> CHANGE TO: >> Re6. Currency indication: The mapping protocol SHOULD=20 >> support an indicator describing how current the information=20 >provided by >> the=20 >> mapping source is. >>=20 >> Motivation: This is especially useful when an alternate mapping is=20 >> requested, and alternative sources of mapping data may not have=20 >> been created or updated with the same set of information or within=20 >> the same timeframe. Differences in currency between mapping data=20 >> contained within mapping sources should be minimized. >>=20 >>=20 >> Issue 47. Re7. Proposed changed to text for minor rewording: >>=20 >> CHANGE FROM: >> Re7. Mapping result usability: The ECRIT mapping=20 >> protocol MUST return a URI (or URIs) that are usable within=20 >a standard=20 >> signaling protocol (i.e., without special emergency extensions). >>=20 >> Motivation: For example, a SIP specific URI returned by the mapping=20 >> protocol, needs to be usable within any SIP capable phone in a SIP=20 >> initiated emergency call. This is in contrast to a "special purpose" >> URI,=20 >> which may not be recognizable by a legacy SIP device. >>=20 >> CHANGE TO: >> Re7. Mapping result usability: The mapping protocol=20 >> MUST return one or more URIs that are usable within a standard=20 >> signaling protocol (i.e., without special emergency extensions). >>=20 >> Motivation: For example, a SIP specific URI which is returned by the >> mapping=20 >> protocol needs to be usable by any SIP capable phone within a SIP=20 >> initiated emergency call. This is in contrast to a "special purpose" >> URI,=20 >> which may not be recognizable by a legacy SIP device. >>=20 >>=20 >> Issue 48. Re8. Propose to change this requirement to make=20 >it specific >> to the mapping protocol, and because a general requirement=20 >for mapping >> information at the server is out of scope for the mapping protocol >> itself. >>=20 >> CHANGE FROM: >> Re8. PSAP accessibility: The mapping information=20 >> MUST be available without having to enroll with a service provider. >>=20 >> Motivation: The mapping server may well be operated by a service=20 >> provider, but access to the server offering the mapping must not=20 >> require use of a specific ISP or ASP/VSP. >>=20 >> CHANGE TO: >> Re8. PSAP URI accessibility:"> The mapping protocol=20 >> MUST support interaction between the client and server where no=20 >> enrollment to a mapping service exists or is required. >>=20 >> Motivation: The mapping server may well be operated by a service=20 >> provider, but access to the server offering the mapping must not=20 >> require use of a specific ISP or ASP/VSP. >>=20 >>=20 >> Issue 49. Re9. Propose to change this requirement to make=20 >it specific >> to the mapping protocol, and because a requirement for mapping server >> and it's internal database is out of scope for the mapping protocol >> itself. >>=20 >> CHANGE FROM: >> =20 >> The mapping protocol SHOULD NOT require that data within=20 >> location databases be transformed or modified in any unusual or=20 >> unreasonable way in order for the mapping protocol to use=20 >the data. >>=20 >> Motivation: Databases which contain civic addresses used within=20 >> location servers, may be used for multiple purposes and applications=20 >> beyond emergency service mapping. >>=20 >> CHANGE TO: >> =20 >> The mapping protocol SHOULD support common data structures and=20 >> formats from the mapping server. >>=20 >> Motivation: Location databases should not need to be=20 >transformed or=20 >> modified in any unusual or unreasonable way in order for the mapping=20 >> protocol to use the data. For example, a database which=20 >contains civic=20 >> addresses used by location servers, may be used for multiple=20 >> purposes and applications beyond emergency service location-to-PSAP=20 >> URI mapping. >>=20 >>=20 >> [Section 5. Identifying the Caller's Location] >>=20 >> Issue 50. Lo1. Propose to change text to make it specific to the >> mapping protocol, and because a requirement for mapping=20 >server is out of >> scope. >>=20 >> CHANGE FROM: >> Lo1. Reference datum: The mapping server MUST=20 >> implement support for the WGS-84 coordinate reference system and=20 >> MAY support other coordinate reference systems. >>=20 >> CHANGE TO: >> Lo1. Reference datum: The mapping protocol MUST=20 >> support the WGS-84 coordinate reference system and=20 >> MAY support other coordinate reference systems. >>=20 >>=20 >> Issue 51. Lo2. Propose to change text to make it specific to the >> mapping protocol, and because a requirement for an ESRP is=20 >out of scope. >>=20 >> CHANGE FROM: >> Lo2. Location provided: An Emergency Services=20 >> Routing Proxy (ESRP) MUST NOT remove location information after=20 >> performing location based routing. >>=20 >> Motivation: The ESRP and the PSAP use the same location=20 >> information object, but for a different purpose. Therefore,=20 >the PSAP=20 >> still needs to receive the caller's location. >>=20 >> CHANGE TO: >> Lo2. Location retained: The mapping protocol MUST=20 >> retain any location information which is provided to it,=20 >> even after a location based action is performed. >>=20 >> Motivation: The ESRP and the PSAP use the same location=20 >> information object, but for a different purpose. Therefore,=20 >> It is imperative that the mapping protocol not remove location=20 >> Information so that the PSAP can still receive the caller=20 >> location. >>=20 >>=20 >> [Section 6. Emergency Identifier] >>=20 >>=20 >> Issue 52. Id1. Propose to change the intent of the=20 >requirement, from a >> phone/UA requirement to a mapping protocol requirement. The mapping >> protocol doesn't care what identifier is used to invoke an emergency >> call, except if it is slated to provide that=20 >identifier/dialstring as a >> response based on location. >>=20 >> CHANGE FROM: >> Id1. Emergency identifier setup: One or more=20 >> emergency identifiers MUST be recognized by any device or=20 >> network element for call setup purposes. >>=20 >> Motivation: There must be some way for any device or element to=20 >> recognize an emergency call throughout the call setup. This is=20 >> regardless of the device location, the application/voice service=20 >> provider used. An example of this might be "urn:service:sos". >>=20 >> CHANGE TO: >> Id1. Emergency identifier support: The mapping=20 >> protocol MUST support one or more emergency identifiers for delivery=20 >> back to mapping clients to be used for call setup purposes. >>=20 >> Motivation: Since there is a need for any device or network=20 >> element to recognize an emergency call throughout the call=20 >setup, there=20 >> is also a need to have the mapping protocol provide support=20 >for such an=20 >> identifier. This is regardless of the device location or the ASP/VSP >> used. =20 >> An example of this kind of identifier might be "urn:service:sos". >>=20 >>=20 >> [to be continued...] >> /end >>=20 >> -Roger Marshall. >>=20 >>=20 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 18 14:42:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVv9A-0004dL-5Y; Tue, 18 Apr 2006 14:41:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVv98-0004dF-Vd for ecrit@ietf.org; Tue, 18 Apr 2006 14:41:54 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVv96-0008AW-Im for ecrit@ietf.org; Tue, 18 Apr 2006 14:41:54 -0400 Received: (qmail invoked by alias); 18 Apr 2006 18:41:49 -0000 Received: from p549879CF.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.121.207] by mail.gmx.net (mp042) with SMTP; 18 Apr 2006 20:41:49 +0200 X-Authenticated: #29516787 Message-ID: <444532ED.60207@gmx.net> Date: Tue, 18 Apr 2006 20:41:49 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) 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-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ecrit] Open issues with the ECRIT Requirements draft 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: , Errors-To: ecrit-bounces@ietf.org Hi all, Roger spotted a few open issues with the ECRIT requirements draft. He needs assistance with the following issues: Issue 35: Location Validation http://www.ietf-ecrit.org:8080/ecrit-req/issue35 Issue 38: Ma5. URI alternate contact http://www.ietf-ecrit.org:8080/ecrit-req/issue38 Issue 39: Ma6. URL properties http://www.ietf-ecrit.org:8080/ecrit-req/issue39 Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 18 14:43:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvAg-00058E-Hk; Tue, 18 Apr 2006 14:43:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvAg-000589-3f for ecrit@ietf.org; Tue, 18 Apr 2006 14:43:30 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVvAb-0008C4-RK for ecrit@ietf.org; Tue, 18 Apr 2006 14:43:29 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 18 Apr 2006 11:43:25 -0700 X-IronPort-AV: i="4.04,131,1144047600"; d="scan'208"; a="1796164271:sNHT37967412" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3IIhPVM025695 for ; Tue, 18 Apr 2006 11:43:25 -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, 18 Apr 2006 11:43:25 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Apr 2006 11:43:24 -0700 From: "Marc Linsner" To: Date: Tue, 18 Apr 2006 14:43:17 -0400 Message-ID: <003101c66317$f5c67720$1f0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcZjF/HKw9LxiXtKQgKV+Eh6pDSJhA== X-OriginalArrivalTime: 18 Apr 2006 18:43:24.0795 (UTC) FILETIME=[F97FFCB0:01C66317] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ecrit] Requirements Issue 38 - MA5 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: , Errors-To: ecrit-bounces@ietf.org In an attempt to clear up the complaint that this req. doesn't contain enough information. Current: Ma5. URI alternate contact: The mapping protocol MUST support the return of a URI or contact method explicitly marked as an alternate contact. Motivation: In response to a mapping request, the mapping server may return an alternate URI. Implementation details to be described within an operational document. Proposed: Ma5. URI alternate contact: In addition to returning a primary contact, the mapping protocol MUST support the return of a URI or contact method explicitly marked as an alternate contact. Motivation: In response to a mapping request, the mapping server may return an alternate URI. Implementation details to be described within an operational document. Comments? -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 18 14:47:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvEM-00063R-Jv; Tue, 18 Apr 2006 14:47:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvEK-0005yx-Oy for ecrit@ietf.org; Tue, 18 Apr 2006 14:47:16 -0400 Received: from test-iport-2.cisco.com ([171.71.176.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVvEI-0008Gu-EY for ecrit@ietf.org; Tue, 18 Apr 2006 14:47:16 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-2.cisco.com with ESMTP; 18 Apr 2006 11:47:14 -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 k3IIlDw1011086 for ; Tue, 18 Apr 2006 11:47:13 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Apr 2006 11:47:13 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Apr 2006 11:47:13 -0700 From: "Marc Linsner" To: Date: Tue, 18 Apr 2006 14:47:06 -0400 Message-ID: <003501c66318$7e1ca810$1f0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcZjGHstpCAazagKQJW3M83YYcA+xQ== X-OriginalArrivalTime: 18 Apr 2006 18:47:13.0543 (UTC) FILETIME=[81D82970:01C66318] X-Spam-Score: 1.8 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ecrit] Requirements Issue 39 - MA6 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: , Errors-To: ecrit-bounces@ietf.org In an effort to clear up the issue with that this requirement is too vague. Current: Ma6. URL properties: The mapping protocol MUST support the ability to provide additional information that allows the mapping client 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. This determination could be made by either an ESRP, based on local policy, or by direct user choice, in the case of caller-based methods. Proposed: MA6 - URL properties: The mapping protocol MUST support the ability to provide ancillary information about a contact or URI that allows the mapping client 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. This determination could be made by either an ESRP, based on local policy, or by direct user choice, in the case of caller-based methods. Comments? -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 18 15:30:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvtk-0000GS-KI; Tue, 18 Apr 2006 15:30:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvtj-0000GM-Us for ecrit@ietf.org; Tue, 18 Apr 2006 15:30:03 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVvti-00025e-Ir for ecrit@ietf.org; Tue, 18 Apr 2006 15:30:03 -0400 Received: (qmail invoked by alias); 18 Apr 2006 19:30:01 -0000 Received: from p549879CF.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.121.207] by mail.gmx.net (mp011) with SMTP; 18 Apr 2006 21:30:01 +0200 X-Authenticated: #29516787 Message-ID: <44453E33.7020700@gmx.net> Date: Tue, 18 Apr 2006 21:29:55 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) 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-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Ecrit] Rechartering Discussion 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: , Errors-To: ecrit-bounces@ietf.org Hi all, at the last ECRIT WG meeting we had a discussion about rechartering. Jon indicated that it might be a good time to start a discussion about the text. Here is a first attempt: ------------- March 2006 Informational RFC containing terminology definitions and the requirements (Draft: "Requirements for Emergency Context Resolution with Internet Technologies"; draft-ietf-ecrit-requirements-*) May 2006 An Informational document describing the threats and security considerations (Example document: "Security Threats and Requirements for Emergency Call Marking and Mapping"; draft-taylor-ecrit-security-threats-*) March 2006 A Standards Track RFC describing how to identify a session set-up request is to an emergency response center (Draft: "A Uniform Resource Name (URN) for Services"; draft-ietf-ecrit-service-urn-*) Nov 2006 A Standards Track RFC describing how to route an emergency call based on location information (Example document: "LoST: A Location-to-Service Translation Protocol"; draft-hardie-ecrit-lost-*) TBD TBD An Informational document describing the Mapping Protocol Architecture (Example document: "Location-to-URL Mapping Architecture and Framework"; draft-schulzrinne-ecrit-mapping-arch-*) TBD TBD An Informational document describing the ECRIT Architecture (Example documents are draft-schulzrinne-sipping-emergency-arch-02.txt and draft-polk-newton-ecrit-arch-considerations-02.txt) TBD TBD A BCP RFC describing the emergency call support for devices. (Example document: "Best Current Practice for Communications Services in support of Emergency Calling"; draft-rosen-ecrit-phonebcp-*) ------------- Please note that the milestone date is missing for the last 3 items. I would like to solicit input from the group: When can we finish these documents? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 18 15:33:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvwr-0000vH-Jj; Tue, 18 Apr 2006 15:33:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvwq-0000vC-Qf for ecrit@ietf.org; Tue, 18 Apr 2006 15:33:16 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVvwq-0002D6-CJ for ecrit@ietf.org; Tue, 18 Apr 2006 15:33:16 -0400 Received: (qmail invoked by alias); 18 Apr 2006 19:33:15 -0000 Received: from p549879CF.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.121.207] by mail.gmx.net (mp010) with SMTP; 18 Apr 2006 21:33:15 +0200 X-Authenticated: #29516787 Message-ID: <44453EFA.7040309@gmx.net> Date: Tue, 18 Apr 2006 21:33:14 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) 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-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Ecrit] Design Team for ECRIT Architecture Document 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: , Errors-To: ecrit-bounces@ietf.org Hi all, a few working group members expressed interest in working on a document that describes the big picture for ECRIT. The chairs would like to form a design team to work on such a document. We have two input documents that can serve as a basis for future work: http://www.ietf-ecrit.org/cache/draft-polk-newton-ecrit-arch-considerations-02.txt http://www.ietf-ecrit.org/cache/draft-schulzrinne-sipping-emergency-arch-02.txt We have compiled a tentative list of design team members (based on the interest expressed at the Interim Meeting and at the IETF#65 WG session): - Henning Schulzrinne - James Polk - Brian Rosen - Andrew Newton - Ted Hardie (& the chairs) If you are interested in participating in the design team please let us know as soon as possible. It is expected that the working group members provide text contributions, spend time on mailing list discussions and, if needed, to participate in phone conference calls. This design team will work according to the rules outlined in RFC 2418 and http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt The mailing list archive is public: https://zeke.ecotroph.net/mailman/listinfo/ecrit-arch Thanks to Andy for setting up the mailing list. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 18 16:35:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVwul-00005M-6s; Tue, 18 Apr 2006 16:35:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVwuj-00005H-GU for ecrit@ietf.org; Tue, 18 Apr 2006 16:35:09 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVwuh-00052H-3C for ecrit@ietf.org; Tue, 18 Apr 2006 16:35:09 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Tue, 18 Apr 2006 13:35:04 -0700 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] Design Team for ECRIT Architecture Document Date: Tue, 18 Apr 2006 13:35:03 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504B4F907@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Design Team for ECRIT Architecture Document Thread-Index: AcZjHvN/iXD8pId9SUOiDO72Xbw8wgACGA3Q From: "Roger Marshall" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: , Errors-To: ecrit-bounces@ietf.org Hannes: I'd like to participate. Please include me on this list. Roger Marshall >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: Tuesday, April 18, 2006 12:33 PM >To: ecrit@ietf.org >Subject: [Ecrit] Design Team for ECRIT Architecture Document=20 > >Hi all, > >a few working group members expressed interest in working on a=20 >document that describes the big picture for ECRIT. The chairs=20 >would like to form a design team to work on such a document.=20 >We have two input documents that can serve as a basis for future work: > >http://www.ietf-ecrit.org/cache/draft-polk-newton-ecrit-arch-co >nsiderations-02.txt >http://www.ietf-ecrit.org/cache/draft-schulzrinne-sipping-emerg >ency-arch-02.txt > >We have compiled a tentative list of design team members=20 >(based on the interest expressed at the Interim Meeting and at=20 >the IETF#65 WG session): >- Henning Schulzrinne >- James Polk >- Brian Rosen >- Andrew Newton >- Ted Hardie >(& the chairs) > >If you are interested in participating in the design team=20 >please let us know as soon as possible. It is expected that=20 >the working group members provide text contributions, spend=20 >time on mailing list discussions and, if needed, to=20 >participate in phone conference calls. > >This design team will work according to the rules outlined in=20 >RFC 2418 and http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt > >The mailing list archive is public: >https://zeke.ecotroph.net/mailman/listinfo/ecrit-arch >Thanks to Andy for setting up the mailing list. > >Ciao >Hannes & Marc > >_______________________________________________ >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 Apr 18 17:01:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVxJs-0006Qo-CW; Tue, 18 Apr 2006 17:01:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVxJq-0006Qj-V3 for ecrit@ietf.org; Tue, 18 Apr 2006 17:01:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVwsL-0004uW-GT for ecrit@ietf.org; Tue, 18 Apr 2006 16:32:41 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FVwc3-0004wD-Fu for ecrit@ietf.org; Tue, 18 Apr 2006 16:15:53 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Tue, 18 Apr 2006 13:01:15 -0700 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] Requirements Issue 39 - MA6 Date: Tue, 18 Apr 2006 13:01:15 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504B4F8C3@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Requirements Issue 39 - MA6 Thread-Index: AcZjGHstpCAazagKQJW3M83YYcA+xQACjPEA From: "Roger Marshall" To: "Marc Linsner" , X-Spam-Score: -1.9 (-) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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: , Errors-To: ecrit-bounces@ietf.org Marc: I like the wording. I plan to add this as written to the next requirements version.=20 Thanks. Roger.=20 >-----Original Message----- >From: Marc Linsner [mailto:mlinsner@cisco.com]=20 >Sent: Tuesday, April 18, 2006 11:47 AM >To: ecrit@ietf.org >Subject: [Ecrit] Requirements Issue 39 - MA6 > >In an effort to clear up the issue with that this requirement=20 >is too vague. > >Current: > >Ma6. URL properties: The mapping protocol MUST support the=20 >ability to provide additional information that allows the=20 >mapping client to determine relevant properties of the URL. > >Motivation: In some cases, the same geographic area is served=20 >by several PSAPs, for example, a corporate campus might be=20 >served by both a corporate security department and the=20 >municipal PSAP. The mapping protocol should then return URLs=20 >for both, with information allowing the querying entity to=20 >choose one or the other. This determination could be made by=20 >either an ESRP, based on local policy, or by direct user=20 >choice, in the case of caller-based methods. > >Proposed: > >MA6 - URL properties: The mapping protocol MUST support the=20 >ability to provide ancillary information about a contact or=20 >URI that allows the mapping client to determine relevant=20 >properties of the URL. > >Motivation: In some cases, the same geographic area is served=20 >by several PSAPs, for example, a corporate campus might be=20 >served by both a corporate security department and the=20 >municipal PSAP. The mapping protocol should then return URLs=20 >for both, with information allowing the querying entity to=20 >choose one or the other. This determination could be made by=20 >either an ESRP, based on local policy, or by direct user=20 >choice, in the case of caller-based methods. > > > >Comments? > > >-Marc- > >_______________________________________________ >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 Apr 18 17:08:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVxRG-000070-UQ; Tue, 18 Apr 2006 17:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVxRF-00006v-BU for ecrit@ietf.org; Tue, 18 Apr 2006 17:08:45 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVwsL-0004uW-IX for ecrit@ietf.org; Tue, 18 Apr 2006 16:32:41 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FVwc1-0004wD-Lr for ecrit@ietf.org; Tue, 18 Apr 2006 16:15:51 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Tue, 18 Apr 2006 13:00:01 -0700 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] Requirements Issue 38 - MA5 Date: Tue, 18 Apr 2006 13:00:01 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504B4F8C0@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Requirements Issue 38 - MA5 Thread-Index: AcZjF/HKw9LxiXtKQgKV+Eh6pDSJhAACmXqQ From: "Roger Marshall" To: "Marc Linsner" , X-Spam-Score: -1.2 (-) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: , Errors-To: ecrit-bounces@ietf.org Marc: Thanks for this contribution. I think the reworded version makes more sense. My plan is to go ahead and add it to the next requirements draft, as written. Roger Marshall. >-----Original Message----- >From: Marc Linsner [mailto:mlinsner@cisco.com]=20 >Sent: Tuesday, April 18, 2006 11:43 AM >To: ecrit@ietf.org >Subject: [Ecrit] Requirements Issue 38 - MA5 > >In an attempt to clear up the complaint that this req. doesn't=20 >contain enough information. > >Current: > >Ma5. URI alternate contact: The mapping protocol MUST support=20 >the return of a URI or contact method explicitly marked as an=20 >alternate contact. > >Motivation: In response to a mapping request, the mapping=20 >server may return an alternate URI. Implementation details to=20 >be described within an operational document. > >Proposed: > >Ma5. URI alternate contact: In addition to returning a=20 >primary contact, the mapping protocol MUST support the return=20 >of a URI or contact method explicitly marked as an alternate contact. > >Motivation: In response to a mapping request, the mapping=20 >server may return an alternate URI. Implementation details to=20 >be described within an operational document. > > > >Comments? > >-Marc- > >_______________________________________________ >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 Apr 18 23:49:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW3hH-0002AU-VD; Tue, 18 Apr 2006 23:49:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW3hG-00027X-Hg for ecrit@ietf.org; Tue, 18 Apr 2006 23:49:42 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW3hG-0001XD-6y for ecrit@ietf.org; Tue, 18 Apr 2006 23:49:42 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 18 Apr 2006 20:49:42 -0700 X-IronPort-AV: i="4.04,132,1144047600"; d="scan'208"; a="269567814:sNHT30842670" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k3J3nfRT006715; Tue, 18 Apr 2006 20:49:41 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Apr 2006 20:49:41 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.20.22]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Apr 2006 20:49:40 -0700 Message-Id: <4.3.2.7.2.20060418224723.02988ec8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Apr 2006 22:49:39 -0500 To: Hannes Tschofenig , ecrit@ietf.org From: "James M. Polk" Subject: Re: [Ecrit] Rechartering Discussion In-Reply-To: <44453E33.7020700@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 19 Apr 2006 03:49:41.0065 (UTC) FILETIME=[49ADE390:01C66364] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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: , Errors-To: ecrit-bounces@ietf.org Hannes Brian and I are working on the last item listed, so we know we can finish that one. I know the design team will churn out an Arch ID, so that one can be finished. I have no input, other than review and comments, into Hennings LUMP Arch ID. At 09:29 PM 4/18/2006 +0200, Hannes Tschofenig wrote: >Hi all, > >at the last ECRIT WG meeting we had a discussion about rechartering. >Jon indicated that it might be a good time to start a discussion about >the text. Here is a first attempt: > >------------- > >March 2006 Informational RFC containing terminology >definitions and the requirements > >(Draft: "Requirements for Emergency Context Resolution with Internet >Technologies"; draft-ietf-ecrit-requirements-*) > >May 2006 An Informational document describing the threats >and security considerations > >(Example document: "Security Threats and Requirements for Emergency Call >Marking and Mapping"; draft-taylor-ecrit-security-threats-*) > >March 2006 A Standards Track RFC describing how to identify >a session set-up request is to an emergency response center > >(Draft: "A Uniform Resource Name (URN) for Services"; >draft-ietf-ecrit-service-urn-*) > >Nov 2006 A Standards Track RFC describing how to route an >emergency call based on location information > >(Example document: "LoST: A Location-to-Service Translation Protocol"; >draft-hardie-ecrit-lost-*) > >TBD TBD An Informational document describing the Mapping >Protocol Architecture > >(Example document: "Location-to-URL Mapping Architecture and Framework"; >draft-schulzrinne-ecrit-mapping-arch-*) > >TBD TBD An Informational document describing the ECRIT Architecture > >(Example documents are draft-schulzrinne-sipping-emergency-arch-02.txt and >draft-polk-newton-ecrit-arch-considerations-02.txt) > >TBD TBD A BCP RFC describing the emergency call support for devices. > >(Example document: "Best Current Practice for Communications Services in >support of Emergency Calling"; draft-rosen-ecrit-phonebcp-*) > >------------- > >Please note that the milestone date is missing for the last 3 items. I >would like to solicit input from the group: When can we finish these documents? > >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 Wed Apr 19 03:31:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW79u-0001YT-Nr; Wed, 19 Apr 2006 03:31:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW79t-0001YO-3z for ecrit@ietf.org; Wed, 19 Apr 2006 03:31:29 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FW79q-0003uU-Lj for ecrit@ietf.org; Wed, 19 Apr 2006 03:31:29 -0400 Received: (qmail invoked by alias); 19 Apr 2006 07:31:24 -0000 Received: from p54985A15.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.90.21] by mail.gmx.net (mp042) with SMTP; 19 Apr 2006 09:31:24 +0200 X-Authenticated: #29516787 Message-ID: <4445E74D.8010907@gmx.net> Date: Wed, 19 Apr 2006 09:31:25 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] Rechartering Discussion References: <4.3.2.7.2.20060418224723.02988ec8@email.cisco.com> In-Reply-To: <4.3.2.7.2.20060418224723.02988ec8@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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: , Errors-To: ecrit-bounces@ietf.org Hi James, James M. Polk wrote: > Hannes > > Brian and I are working on the last item listed, so we know we can > finish that one. When do you realistically expect such a document to be finished? Since it is a BCP I don't expect to get it done soon. Maybe March 2007 could be realistic? It certainly has to be some time after the mapping protocol and the location conveyance draft. Ciao Hannes > > I know the design team will churn out an Arch ID, so that one can be > finished. > > I have no input, other than review and comments, into Hennings LUMP Arch > ID. > > > At 09:29 PM 4/18/2006 +0200, Hannes Tschofenig wrote: > >> Hi all, >> >> at the last ECRIT WG meeting we had a discussion about rechartering. >> Jon indicated that it might be a good time to start a discussion >> about the text. Here is a first attempt: >> >> ------------- >> >> March 2006 Informational RFC containing terminology >> definitions and the requirements >> >> (Draft: "Requirements for Emergency Context Resolution with Internet >> Technologies"; draft-ietf-ecrit-requirements-*) >> >> May 2006 An Informational document describing the threats >> and security considerations >> >> (Example document: "Security Threats and Requirements for Emergency >> Call Marking and Mapping"; draft-taylor-ecrit-security-threats-*) >> >> March 2006 A Standards Track RFC describing how to identify >> a session set-up request is to an emergency response center >> >> (Draft: "A Uniform Resource Name (URN) for Services"; >> draft-ietf-ecrit-service-urn-*) >> >> Nov 2006 A Standards Track RFC describing how to route an >> emergency call based on location information >> >> (Example document: "LoST: A Location-to-Service Translation Protocol"; >> draft-hardie-ecrit-lost-*) >> >> TBD TBD An Informational document describing the Mapping >> Protocol Architecture >> >> (Example document: "Location-to-URL Mapping Architecture and Framework"; >> draft-schulzrinne-ecrit-mapping-arch-*) >> >> TBD TBD An Informational document describing the ECRIT >> Architecture >> >> (Example documents are draft-schulzrinne-sipping-emergency-arch-02.txt >> and draft-polk-newton-ecrit-arch-considerations-02.txt) >> >> TBD TBD A BCP RFC describing the emergency call support for >> devices. >> >> (Example document: "Best Current Practice for Communications Services >> in support of Emergency Calling"; draft-rosen-ecrit-phonebcp-*) >> >> ------------- >> >> Please note that the milestone date is missing for the last 3 items. I >> would like to solicit input from the group: When can we finish these >> documents? >> >> 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 Wed Apr 19 09:51:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWD64-0002Rk-7K; Wed, 19 Apr 2006 09:51:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWD62-0002Rf-EZ for ecrit@ietf.org; Wed, 19 Apr 2006 09:51:54 -0400 Received: from [209.108.197.38] (helo=fwc-3a.sccx.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWD61-0004HY-2k for ecrit@ietf.org; Wed, 19 Apr 2006 09:51:54 -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] Design Team for ECRIT Architecture Document Date: Wed, 19 Apr 2006 08:51:45 -0500 Message-ID: <422D410BD61FC04185076AD99AA7207A0183A144@inilmx01.lgmt.trdo> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Design Team for ECRIT Architecture Document Thread-Index: AcZjHvPQm4yijVVbRFGC63PinTJBWAAmVRhQ From: "McCalmont, Patti" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 19 Apr 2006 13:51:47.0144 (UTC) FILETIME=[66801480:01C663B8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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: , Errors-To: ecrit-bounces@ietf.org Hi Hannes, I would like to be included on this design team. Patti McCalmont -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Tuesday, April 18, 2006 2:33 PM To: ecrit@ietf.org Subject: [Ecrit] Design Team for ECRIT Architecture Document=20 Hi all, a few working group members expressed interest in working on a document=20 that describes the big picture for ECRIT. The chairs would like to form=20 a design team to work on such a document. We have two input documents=20 that can serve as a basis for future work: http://www.ietf-ecrit.org/cache/draft-polk-newton-ecrit-arch-considerati ons-02.txt http://www.ietf-ecrit.org/cache/draft-schulzrinne-sipping-emergency-arch -02.txt We have compiled a tentative list of design team members (based on the=20 interest expressed at the Interim Meeting and at the IETF#65 WG session): - Henning Schulzrinne - James Polk - Brian Rosen - Andrew Newton - Ted Hardie (& the chairs) If you are interested in participating in the design team please let us=20 know as soon as possible. It is expected that the working group members=20 provide text contributions, spend time on mailing list discussions and,=20 if needed, to participate in phone conference calls. This design team will work according to the rules outlined in RFC 2418 and http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt The mailing list archive is public: https://zeke.ecotroph.net/mailman/listinfo/ecrit-arch Thanks to Andy for setting up the mailing list. Ciao Hannes & Marc _______________________________________________ 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 Apr 19 10:07:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWDKc-0006xZ-Vp; Wed, 19 Apr 2006 10:06:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWDKb-0006wJ-HD for ecrit@ietf.org; Wed, 19 Apr 2006 10:06:57 -0400 Received: from fwc-3a.sccx.com ([199.117.205.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWDKa-0005Gu-3s for ecrit@ietf.org; Wed, 19 Apr 2006 10:06:57 -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] Rechartering Discussion Date: Wed, 19 Apr 2006 09:06:49 -0500 Message-ID: <422D410BD61FC04185076AD99AA7207A0183A152@inilmx01.lgmt.trdo> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Rechartering Discussion Thread-Index: AcZjHoDHs0ywPyz2ToyZkOt5wehbuwAmhpYQ From: "McCalmont, Patti" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 19 Apr 2006 14:06:51.0230 (UTC) FILETIME=[8160A7E0:01C663BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: , Errors-To: ecrit-bounces@ietf.org Hi Hannes, On the item listed below, how do you think this will relate to work going in other organizations such as 3GPP(already have a draft started), ESIF, PTSC and others? Is it really an architecture document since IETF's focus is on defining protocols? Should this really be an item addressed here? The other SDOs are looking at using protocols defined within ECRIT but working out the architectures of how they fit into their own networks. Guess I'm wondering if this item should really be part of this charter. Patti >TBD TBD An Informational document describing the ECRIT=20 >Architecture >(Example documents are draft-schulzrinne-sipping-emergency-arch-02.txt=20 >and draft-polk-newton-ecrit-arch-considerations-02.txt) Please note that the milestone date is missing for the last 3 items. I=20 would like to solicit input from the group: When can we finish these=20 documents? 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 Wed Apr 19 12:20:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWFPH-0007VN-1g; Wed, 19 Apr 2006 12:19:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWFPF-0007VI-LM for ecrit@ietf.org; Wed, 19 Apr 2006 12:19:54 -0400 Received: from test-iport-2.cisco.com ([171.71.176.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWFPD-0002kd-B2 for ecrit@ietf.org; Wed, 19 Apr 2006 12:19:53 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-2.cisco.com with ESMTP; 19 Apr 2006 09:19:50 -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 k3JGJoRT016540; Wed, 19 Apr 2006 09:19:50 -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, 19 Apr 2006 09:19:50 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.20.143]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Apr 2006 09:19:50 -0700 Message-Id: <4.3.2.7.2.20060419111552.068538b0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Apr 2006 11:19:49 -0500 To: Hannes Tschofenig From: "James M. Polk" Subject: Re: [Ecrit] Rechartering Discussion In-Reply-To: <4445E74D.8010907@gmx.net> References: <4.3.2.7.2.20060418224723.02988ec8@email.cisco.com> <4.3.2.7.2.20060418224723.02988ec8@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 19 Apr 2006 16:19:50.0359 (UTC) FILETIME=[154F1E70:01C663CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: ecrit-bounces@ietf.org At 09:31 AM 4/19/2006 +0200, Hannes Tschofenig wrote: >Hi James, > >James M. Polk wrote: >>Hannes >>Brian and I are working on the last item listed, so we know we can finish >>that one. > >When do you realistically expect such a document to be finished? Since it >is a BCP I don't expect to get it done soon. Maybe March 2007 could be >realistic? I would think anytime between Dec 06 and March 07 would be realistic. >It certainly has to be some time after the mapping protocol and the >location conveyance draft. Location Conveyance is (hopefully) going to WGLC within 2 months, so it is not that far away - therefore this ID will not be the holding up the BCP here. >Ciao >Hannes > >>I know the design team will churn out an Arch ID, so that one can be >>finished. >>I have no input, other than review and comments, into Hennings LUMP Arch ID. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 19 16:48:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWJax-00006w-9l; Wed, 19 Apr 2006 16:48:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWJav-00006f-N7 for ecrit@ietf.org; Wed, 19 Apr 2006 16:48:13 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWJau-0007o6-Ce for ecrit@ietf.org; Wed, 19 Apr 2006 16:48:13 -0400 Received: from az4315exch001u.wins.lucent.com (h130-131-166-103.lucent.com [130.131.166.103]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k3JKm9DT022371; Wed, 19 Apr 2006 15:48:09 -0500 (CDT) Received: by az4315exch001u.phx.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 19 Apr 2006 13:48:08 -0700 Message-ID: <17D8724A2A8D9542B2B8AE546B9E5BBC065D459D@az4315exch001u.phx.lucent.com> From: "GOLDMAN, STUART O (STUART)" To: Hannes Tschofenig , ecrit@ietf.org Subject: RE: [Ecrit] Design Team for ECRIT Architecture Document Date: Wed, 19 Apr 2006 13:48:08 -0700 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: 7aafa0432175920a4b3e118e16c5cb64 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: , Errors-To: ecrit-bounces@ietf.org Hannes, An ECRIT big picture document sounds like a great idea, so please include me on the design team. Stuart Goldman Lucent Technologies sgoldman@lucent.com 602 493 8438 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Tuesday, April 18, 2006 12:33 PM To: ecrit@ietf.org Subject: [Ecrit] Design Team for ECRIT Architecture Document Hi all, a few working group members expressed interest in working on a document that describes the big picture for ECRIT. The chairs would like to form a design team to work on such a document. We have two input documents that can serve as a basis for future work: http://www.ietf-ecrit.org/cache/draft-polk-newton-ecrit-arch-considerations-02.txt http://www.ietf-ecrit.org/cache/draft-schulzrinne-sipping-emergency-arch-02.txt We have compiled a tentative list of design team members (based on the interest expressed at the Interim Meeting and at the IETF#65 WG session): - Henning Schulzrinne - James Polk - Brian Rosen - Andrew Newton - Ted Hardie (& the chairs) If you are interested in participating in the design team please let us know as soon as possible. It is expected that the working group members provide text contributions, spend time on mailing list discussions and, if needed, to participate in phone conference calls. This design team will work according to the rules outlined in RFC 2418 and http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt The mailing list archive is public: https://zeke.ecotroph.net/mailman/listinfo/ecrit-arch Thanks to Andy for setting up the mailing list. Ciao Hannes & Marc _______________________________________________ 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 Apr 19 17:05:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWJrA-0003qZ-4P; Wed, 19 Apr 2006 17:05:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWJr8-0003qU-To for ecrit@ietf.org; Wed, 19 Apr 2006 17:04:58 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWJr6-00005T-Gc for ecrit@ietf.org; Wed, 19 Apr 2006 17:04:58 -0400 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-12.tower-126.messagelabs.com!1145480546!11049421!40 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 11498 invoked from network); 19 Apr 2006 21:04:53 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-12.tower-126.messagelabs.com with SMTP; 19 Apr 2006 21:04:53 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh3i.attrh.att.com (7.2.052) id 4426C9FE0034304E; Wed, 19 Apr 2006 17:04:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Design Team for ECRIT Architecture Document Date: Wed, 19 Apr 2006 16:04:52 -0500 Message-ID: <28F05913385EAC43AF019413F674A0170DE0C5D5@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <44453EFA.7040309@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Design Team for ECRIT Architecture Document Thread-Index: AcZjHvaJzsu30TU1TmKcZtwxoqMH5wA1TL+g From: "Dolly, Martin C, ALABS" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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: , Errors-To: ecrit-bounces@ietf.org Hannes, I would like to participate. Cheers, Martin > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, April 18, 2006 3:33 PM > To: ecrit@ietf.org > Subject: [Ecrit] Design Team for ECRIT Architecture Document=20 >=20 >=20 > Hi all, >=20 > a few working group members expressed interest in working on=20 > a document=20 > that describes the big picture for ECRIT. The chairs would=20 > like to form=20 > a design team to work on such a document. We have two input documents=20 > that can serve as a basis for future work: >=20 > http://www.ietf-ecrit.org/cache/draft-polk-newton-ecrit-arch-c onsiderations-02.txt http://www.ietf-ecrit.org/cache/draft-schulzrinne-sipping-emergency-arch-= 02.txt We have compiled a tentative list of design team members (based on the=20 interest expressed at the Interim Meeting and at the IETF#65 WG = session): - Henning Schulzrinne - James Polk - Brian Rosen - Andrew Newton - Ted Hardie (& the chairs) If you are interested in participating in the design team please let us=20 know as soon as possible. It is expected that the working group members=20 provide text contributions, spend time on mailing list discussions and,=20 if needed, to participate in phone conference calls. This design team will work according to the rules outlined in RFC 2418 and http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt The mailing list archive is public: https://zeke.ecotroph.net/mailman/listinfo/ecrit-arch Thanks to Andy for setting up the mailing list. Ciao Hannes & Marc _______________________________________________ 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 Apr 19 17:12:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWJy7-0005fV-AJ; Wed, 19 Apr 2006 17:12:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWJy6-0005fQ-8x for ecrit@ietf.org; Wed, 19 Apr 2006 17:12:10 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWJy5-0000VP-AO for ecrit@ietf.org; Wed, 19 Apr 2006 17:12:10 -0400 Received: (qmail invoked by alias); 19 Apr 2006 21:12:07 -0000 Received: from p54985A15.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.90.21] by mail.gmx.net (mp019) with SMTP; 19 Apr 2006 23:12:07 +0200 X-Authenticated: #29516787 Message-ID: <4446A7A6.5070908@gmx.net> Date: Wed, 19 Apr 2006 23:12:06 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) 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-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Subject: [Ecrit] Issue 35: Location Validation 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: , Errors-To: ecrit-bounces@ietf.org Hi all, we need to close issue#35 about location validation. The issue can be found at: http://www.ietf-ecrit.org:8080/ecrit-req/issue35. Note that I provide a summary at the end of my mail. http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-06.txt says: " Location validation: A caller location is considered valid if the civic or geographic location is recognizable within an acceptable location reference systems (e.g., USPS, WGS-84, etc.), and can be mapped to one or more PSAPs. While it is desirable to determine that a location exists, validation may not ensure that such a location exists. Location validation ensures that a location is able to be referenced for mapping, but makes no assumption about the association between the caller and the caller's location. " We had a discussion about this subject during the interim meeting: http://www.ietf-ecrit.org/Interim2006/Jabber-Log_2006-02-01.html ---------------- [07:53:24] roger: issue 15 re validation of civic [07:53:39] andy: I thought the list left the issue not about not doing it, but how. [07:53:46] roger: need to know about the language in the draft [07:54:08] brian: something about a way to do it [07:54:24] jon: related to other req. such as querying it anywhere. [07:54:37] james p.: we are no validating [07:54:56] ted: text in the issue tracker is not the meaning of validation in NENA, etc... [07:55:12] ted: this is a valuable piece of protocol machinery. [07:55:39] james: that makes sense, but the text doesn't say that [07:56:03] brian: if validation is defined as succesful mapping to the PSAP, then that is what we want. [07:56:11] james: need other word than "valid" [07:56:28] brian: what we have can be used for NENA view of the world [07:57:01] james: anything out of this building to the proper PSAP, but not floor by floor [07:57:16] brian: the requirement is to know that you can send a responder. [07:57:32] marc: not sure that is the NENA view, re ESN [07:58:04] brian: the location is knowing we can send a responder [07:58:09] nadine: agree [07:58:52] brian: definition of valdiation to be successful mapping to occur for the location [07:59:10] ted: this requirement needs the point brian is making [07:59:49] james: concerned with people thinking we mean something much more precise [08:00:12] hannes: the definition does not match the requirmenet [08:00:26] roger: let's examine the definition first [08:01:09] nadine & brian: this is a good defintion [08:01:15] james: no, that is cumbersome [08:03:04] henning: problem is that this is trying to define validation for both civic and geo. first test is syntactic validity. the description is not clear if the actual address exists. [08:03:49] henning: second test, is there a valid mapping, third, is there a street address that can be routed to. [08:04:14] brian: clarifying this is a good idea. [08:04:21] nadine: agree with 1 and 2, but not 3 [08:04:27] roger: we cannot achieve 3 [08:04:38] henning: then we need to be clear about it [08:05:36] roger: "but not equivicate to an address" ? [08:05:58] brian: add new sentence to clarify it. "while desirable to have the address exist, not guarnateed." [08:06:46] ted: wandering from the protocol requirement. an address could be invalid for other purposes but could get mapped to a PSAP. [08:07:46] ted: could I give you a PSAP based on the location given, if answer is yes then that is the one thing we care about [08:08:01] henning: just need a qualification of what it does not mean [08:08:42] brian: agree, see my previous wording [08:09:17] marc: mentions some use case in Texas. [08:09:25] brian: but that is not how it will work [08:09:40] marc: but if the address does not exist, no PSAP [08:09:46] brian: that is making an assumption [08:10:35] brian: current MSAG does address ranges, but we should have ability in future to work on single addresses [08:11:07] marc: do you believe it shouldn't return an answer? [08:11:10] brian: ? [08:11:41] ted: in some administrations, the answer will be "here is your PSAP, and btw the address you gave is foobar" [08:13:18] nadine: be able to distinguish if it is the "right" PSAP vs "default" PSAP? [08:13:47] ted: for validation it would be "right". [08:14:33] henning: this has implication on protocol design choices. [08:15:57] henning: difference in use case in validation and non-validation (emergency case) and the bits on the wire in the protocol [08:16:00] If the case is that the address is 125 main street, and 124 and 126 exist but 125 does not, would validation indicate that the address is syntactically valid, the psap returned would be for 124 and/or 126? [08:17:19] are you asking a question for the room? [08:17:36] yes, but we've moved on abit [08:18:06] I was trying to clarify comments from several people [08:19:21] brian: answering randy's q: "I can map it, but it isn't really valid. But in an emergency, it would send you to the closest PSAP." [08:19:32] Thanks, sounds reasonable to me [08:19:46] marc: result should be saying there is a problem in XML [08:19:51] brian: yes [08:20:12] brian: it is desirable to say you can get a mapping, but there is a problem with the address. [08:21:20] henning: even in a real emergency query, this is nothing wrong with indicating that the address is foobar as long as the PSAP is returned [08:22:11] ted: in a real emergency only look at the one thing they map on. validation may be a different task. [08:22:47] brian: but that work for you [08:22:56] ted: that is why this is desirable. [08:23:04] nadine: ? [08:23:17] nadine: if you only know that it is a known range [08:24:34] andy: just need to make sure that implementers don't let the error show up in the emergency case [08:24:58] roger: do we agree that in addition to the URL that it is desirable to have a result code? [08:25:10] henning: generally, yup/ [08:25:27] is the audio being recorded? [08:26:10] henning: it is more than a status code [08:26:16] roger: additional information? [08:27:13] hannes: Validation Resolution: it MAY be possible to return additional information which can be used to determine the preceision or resolution of the returned sip uri, for example ---------------- The meeting minutes of the interim meeting indicate: http://www.ietf-ecrit.org/Interim2006/MeetingMinutes.html ---------------- Issue 15 Validation of civil location has been hanging around for a while. Should it stay in the 02 draft? Andrew thought the issue was how we would do validation, not whether. Brian wants to leave the language in, but would like to know if people think it's adequate (we're using motivations text to describe what validation means). "A successful mapping will work". We actually do have other requirements that talk about this (doing queries at any time), but we don't describe it anywhere else. Are we actually validating? We don't mean NEMA validation, only asking whether it's enough to get back a PSAP mapping. Passing back "here's the PSAP" would be sufficient. Can we use another word? "Validation" has lots of baggage. Brian wants to make sure that we can get to NEMA validation - "a location that a responder knows how to get to". "A location that can be sucessfully mapped to one or more PSAPs". We're trying to encompass both civil location and geolocation in one sentence - this is one reason why it's cumbersome. If all of the city of Washington goes to one PSAP but the location isn't valid, we still have a problem. MSAG values have the same problem, because they carry street number ranges and a "valid" street number may not exactly exist - and the best MSAG validators today can't guarantee that the address exists. An address can be "valid enough" to get to the right PSAP, even if it's not valid to respond to. Texas has one PSAP entry - so anything would work as long as it's in Texas? No, the current MSAG works on address ranges - but the street exists. Brian would like for this to work on individual addresses, not ranges. Brian thinks that local PSAPs should be determining what happens for various values of "invalid", since calls are going to go somewhere! Ted thinks that there's a lot of variation in what administrations do now and will do in the future. Will the protocol allow us to tell that we got to the right PSAP, or just got a PSAP? Henning - just returning a SIP URI to let someone ask "where the heck are you?" isn't sufficient when we're actually routing an emergency call. We always get a SIP URI, we're trying to figure out what getting a SIP URI actually means for an operational system. "I got a match on all the XML tags except this one" would be an acceptable response, and this would be desirable. This could happen at validation time or at emergency call routing time. Validation may mean "I like the only tags that I care about, and didn't look at the ones I don't care about". Do we agree that we need a result code, in addition to a URI? Partial validation may be the common case (public verifiers won't know suite numbers/room numbers, for example). Is this MUST/SHOULD/MAY? The protocol MUST have the mechanism (whether it gets used or not is up to the administration). And we need to be consistent in our RFC 2119 usage (which is always problematic for requirements documents anyway, since the meaning is a protocol-mechanism meaning, not a protocol-usage meaning). We're making a lot of these requirements MUSTs, and that may make the resulting protocols clumsy. If we use 2119, we should be using MUST, MAY and SHOULD, not just MUST. Tom pointed out that some mechanisms may be provided by extensions, but are not required in the base protocol. Henning says we're not writing a BCP, so we should consider NOT using 2119 language. Randy suggested that we actually spell out "must support", etc. and not rely on 2119. Henning - then we should have consistent terminology, whether it's upper case or lower case. Randy will audit the existing document, but needs input from others. What about returning an indicator of the resolution of the mapping that is returned? Brian suggested text for a mechanism to indicate that a location or part of location does not exist, even if it can be mapped. Should this point out the invalid pieces? Aren't these administration-specific? Tags are roughly self-describing, but we can't pick one hierarchy - what gets returned needs to be free-form. James - doesn't the text say "location should be sent even if it's considered unreliable?" Is this OK? We will leave L01 language as is, change "location validation" in terminology, and we are adding two new requirements to this section. ---------------- The discussions regarding Issue#15 caused us to change the following requirement into two requirements: http://www.ietf-ecrit.org:8080/ecrit-req/issue15 " > Lo1. Validation of Civic Location: It MUST be possible to >validate a > civic location prior to its use in an actual emergency call. > > Motivation: Location validation provides an opportunity to help > assure ahead of time, whether successful mapping to the > appropriate PSAP will likely occur when it is required. > Validation may also help to avoid delays during emergency call > setup due to invalid locations. " to: " Lo1X. Validation Resolution: The mapping protocol MUST support the return of additional information which can be used to determine the precision or resolution of the data elements used to determine a PSAP URI, for example. Lo1XX. Indication of non-existent location: The protocol MUST support a mechanism to indicate that a location or a part of a location is known to not exist, even if a valid location-to-PSAP uri mapping can be provided. " The term validation appears only in the following sections. Section 1 (Introduction): " As used in this document, validation of location does not require to ascertain whether the location actually exists. For example, validation might only check that the house number in a civic address falls within the assigned range, not whether that building exists at that spot. However, such higher precision validation is desirable. " Section 2 (Terminology): " Location validation: A caller location is considered valid if the civic or geographic location is recognizable within an acceptable location reference systems (e.g., USPS, WGS-84, etc.), and can be mapped to one or more PSAPs. While it is desirable to determine that a location exists, validation may not ensure that such a location exists. Location validation ensures that a location is able to be referenced for mapping, but makes no assumption about the association between the caller and the caller's location. " Section 7 (Mapping Protocol): " Ma22. Validation of civic location: The mapping protocol MUST implement a method via a mapping request, that makes it possible for a mapping server to validate a civic location prior to that location's use in an actual emergency call. Motivation: Location validation provides an opportunity to help assure ahead of time, whether successful mapping to the appropriate PSAP will likely occur when it is required. Validation may also help to avoid delays during emergency call setup due to invalid locations. Ma23. Validation resolution: The mapping protocol MUST support (i.e., required to implement, but not required for use) the return of additional information which can be used to determine the precision or resolution of the data elements used to determine a PSAP URI. Motivation: The mapping server may not use all the data elements in the provided location information to determine a match, or may be able to find a match based on all of the information except for some specific data elements. The uniqueness of this information set may be used to differentiate among emergency jurisdictions. Precision or resolution in the context of this requirement might mean, for example, explicit identification of the data elements that were used successfully in the mapping. Ma25. Limits to validation: Successful validation of a civic location MUST NOT be required to place an emergency call. Motivation: In some cases, a civic location may not be considered valid. This fact should not result in the call being dropped or rejected by any entity along the signaling path to the PSAP. " I think we need to differentiate civic and geospatial location information. Geospatial location information: * Can the request be mapped to one or more PSAPs? This is normal mapping protocol operation. Nothing special here. * Does the address exist? There is no question that this address exists if the coordinate reference system was understood. Civic location information: * Can the request be mapped to one or more PSAPs? The text from Ma23 is applicable here: Motivation: The mapping server may not use all the data elements in the provided location information to determine a match, or may be able to find a match based on all of the information except for some specific data elements. The uniqueness of this information set may be used to differentiate among emergency jurisdictions. Precision or resolution in the context of this requirement might mean, for example, explicit identification of the data elements that were used successfully in the mapping. * Does the address exist? It is possible that a given civic address does not exist. An additional database, which contains the list of existing addresses, needs to be available. What we can do is to be more specific about the type of behavior we want from the mapping protocol. Do we want the client to be able to express that the mapping server should check the civic address for existence? Do we want the mapping server to be able to indicate that the civic address was checked against the database? I don't think anything needs to be done with regard to geospatial location info. Do we need something else? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 19 17:16:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWK21-0006yS-28; Wed, 19 Apr 2006 17:16:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWK1z-0006vs-U2 for ecrit@ietf.org; Wed, 19 Apr 2006 17:16:11 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWK1z-0000kA-Dk for ecrit@ietf.org; Wed, 19 Apr 2006 17:16:11 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 19 Apr 2006 14:16:10 -0700 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 Date: Wed, 19 Apr 2006 14:16:09 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504BBB685@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review comments -- draft-ietf-ecrit-requirements-06.txt Thread-Index: AcZDgPUuEmFUjtAsSzKrG0OBwwIU7ALFmigQBVdZUrA= From: "Roger Marshall" To: "Bob Natale" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: ecrit@ietf.org Subject: [Ecrit] RE: Review comments -- draft-ietf-ecrit-requirements-06.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: , Errors-To: ecrit-bounces@ietf.org Bob: Thanks for your comments on the draft.=20 Most of your comments have been taken into account per my responses, (see inline). However, due to a mistake on my part, not all which were noted will make it into the very next version, but rather the follow-on version. My apologies for missing those. Thanks. Roger Marshall. >-----Original Message----- >From: Bob Natale [mailto:bnatale@nextone.com]=20 >Sent: Thursday, March 23, 2006 8:49 AM >To: hgs+ecrit@cs.columbia.edu; Roger Marshall >Cc: ecrit@ietf.org >Subject: Review comments -- draft-ietf-ecrit-requirements-06.txt=20 > >Hi, > >FWIW, my review comments below. > >This is my first review of an ECRIT document and a view of my=20 >comments are motivated by associated interest in the SPEERMINT=20 >work, so feel free to calibrate accordingly. (Also, written=20 >on a plane under less than ideal conditions. :) > >Overall, I think it is an excellent document (informative,=20 >well-organized), and a very good model to follow for similar=20 >documents (esp. the "Motivation" >notes). > >Cheers, >BobN >- - - - >C1: Sec 1., Introduction, p. 3: > "This document only focuses on end-to-end IP-based calls,=20 >i.e., where > the emergency call originates from an IP end system and terminates > into an IP-capable PSAP, conveyed entirely over an IP network. > ... > Ideally, the mapping protocol would yield a URI from a preferred set > of URIs (e.g., SIP:URI, SIPS:URI) which would allow an=20 >emergency call > to be completed using IP end-to-end. Despite this goal, some PSAPs > may not immediately have IP based connectivity, and therefore it is > imperative that the URI scheme not be fixed, in order to ensure > support for a less preferred set of URIs, such as a TEL URI=20 >which may > be used to complete a call via the PSTN." > >The rationale behind the "Despite..." in the second quoted paragraph >*seems* >to be inconsistent with the document focus stated in the first=20 >quoted paragraph. I understand that "focus" does not mean=20 >exclusivity; but I think the gap between focus on "all IP" and=20 >a (realistic) recognition of the need to support PSTN=20 >connectivity is too wide to accept without explicit=20 >explanation in the document. I am stressing this point a bit=20 >more than I would otherwise, because I think the same=20 >(realistic) recognition might be needed in other current RAI=20 >Area efforts. If you have a suggested rewrite of the text, I'd be happy to receive it. > >C2: Sec. 2, Terminology, p. 6: >NIT: The defection of ESRP needs a closing paren on the last=20 >sentence, or removal of the opening paren. > Changes made. >C3: Sec. 2, Terminology, p. 8: >The definition for VSP again brings in PSTN termination (realistic). >Is this also valid for SPEERMINT consideration (perhaps=20 >especially in the Access SP entities)? > I'm not sure what changes should be made to the text here. >C4: Sec. 4, High-Level Requirements, p. 13: >The phrase "in any unusual or unreasonable way" is not=20 >sufficiently empirical -- how can compliance be verified? > I'll leave this one to the list for input. >C5: Sec. 5, Identifying the Caller's Location, p. 14: >NIT: First sentence: "direct" s/b "directly". > Changes made to follow-on version. >C6: Sec. 5, Identifying the Caller's Location, p. 14: >Suggest that a better moniker for Lo2 (currently "Location=20 >provided") might be "Location object/info preservation", or=20 >something like that. > Changes made to follow-on version. >C7: Sec. 6, Emergency Identifiers, p. 15: >Concerning the assertion in Id3 that "This marking mechanism=20 >must be different than QoS marking"...why? What, precisely,=20 >is meant by "QoS marking". Why isn't "Emergency Call" a valid=20 >QoS "marking"? Any tie-in with MLPP stuff? > I'll leave this one to be brought to the list. >C8: Sec. 6, Emergency Identifiers, p. 15: >Suggest that the "and" in Id5 should break it into two=20 >separate requirements. (General requirements practice of mine=20 >-- might be excessive on my part, but if accepted, might also=20 >apply to other cases in this draft). > Paragraph has been reworded. >C9: Sec. 6, Emergency Identifiers, p. 16: >Concerning this text in Id11 -- "MUST support (i.e.,=20 >implement, though not necessarily use)": >(a) I don't really understand what is meant: My supposition is=20 >that there must be at least one use case to justify=20 >implementation. What is the intended scope of "not necessarily use"? >(b) [This point was made by another commenter, on an earlier=20 >version of the draft, I believe.] Regardless of (a), the=20 >various forms in which that general text (i.e., the=20 >parenthetical explanatory text following "MUST support") is=20 >used throughout the document is very confusing. > Changed throughout. >C10: Sec. 7, Mapping Protocol, p. 18: >the single sentence that constitutes the entire first=20 >paragraph is hard to follow -- I think there is a wording=20 >problem centered on the word "one", as well as the need for an=20 >overall re-write...? > Text has been reworded. >C11: Sec. 7, Mapping Protocol, p. 19: >I think that the inclusion of "Motivation" statements for each=20 >requirement is a very good idea (and I propose to use it in=20 >the SPEERMINT Requirements BCP). I read that you deliberately=20 >removed that part from at least one of the requirements in=20 >this draft (e.g., Ma4). I would like to ask that "Motivation"=20 >statements be provided for all Requirements statements. It's=20 >very helpful info. Motivation sections now accompany each stated requirement. >- - - - - >-----Original Message----- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Wednesday, March 08, 2006 3:50 PM >To: i-d-announce@ietf.org >Cc: ecrit@ietf.org >Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-requirements-06.txt=20 > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. >This draft is a work item of the Emergency Context Resolution=20 >with Internet Technologies Working Group of the IETF. > > Title : Requirements for Emergency Context Resolution >with Internet Technologies > Author(s) : H. Schulzrinne, R. Marshall > Filename : draft-ietf-ecrit-requirements-06.txt > Pages : 29 > Date : 2006-3-8 >=09 >This document enumerates requirements for the context resolution of > 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-ietf-ecrit-requiremen >ts-06.txt > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 19 18:03:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWKlR-0004HL-T7; Wed, 19 Apr 2006 18:03:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWKlQ-0004HG-QY for ecrit@ietf.org; Wed, 19 Apr 2006 18:03:08 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWKlO-0002GW-VT for ecrit@ietf.org; Wed, 19 Apr 2006 18:03:08 -0400 Received: from brtech by cdx28.winwebhosting.com with local (Exim 4.52) id 1FWKlG-0001j2-7S; Wed, 19 Apr 2006 17:02:58 -0500 Received: from 209.173.53.233 ([209.173.53.233]) (SquirrelMail authenticated user br@brianrosen.net) by www.brianrosen.net with HTTP; Wed, 19 Apr 2006 17:02:58 -0500 (CDT) Message-ID: <59517.209.173.53.233.1145484178.squirrel@www.brianrosen.net> In-Reply-To: <4446A7A6.5070908@gmx.net> References: <4446A7A6.5070908@gmx.net> Date: Wed, 19 Apr 2006 17:02:58 -0500 (CDT) Subject: Re: [Ecrit] Issue 35: Location Validation From: br@brianrosen.net To: "Hannes Tschofenig" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32037 500] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/3rdparty/squirrelmail/src/compose.php X-Source-Dir: :/base/3rdparty/squirrelmail/src X-Spam-Score: 0.2 (/) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f 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: , Errors-To: ecrit-bounces@ietf.org In North America, validation is a well known, and required step in processing a civic location. In the current system, there is no validation of geo. In the end, validation in the current system means: Do we know where this location is; can we send someone to help by giving him this location? To do that, there is presently a database, called the Master Street Address Guide, which contains a list of all the "known" street addresses. Validation, today, means that before a location is put into the database that is actually used to determine address when an emergency call is made (the "ALI" database), the location is looked up in the MSAG. If there is a match, the update to the ALI is permitted. If there is no match, the update is not allowed and the carrier attempting to update the ALI has to go figure out what happened. The MSAG database sometimes also is aligned with the database used to dispatch responders. A location submitted to the responder Computer Aided Dispatch system must be "MSAG Valid". The emergency call system in North America is heavily dependent on validation; many attempts at coming up with a location don't yield something unique enough to use for locating where someone is unambiguously so that help can be dispatched correctly to where they are when they can't answer questions. This is a firm requirement for us, and we really, really need to have it. The current MSAG would be the natural beginning source of the mapping database envisioned by ecrit. There are a whole host of formatting and correlation issues. It is essential that validation happen BEFORE an emergency call. Ideally, it would happen when it happens now; when a location is put into the database that stores location (the Location Server). Given the current design of the ecrit mechanisms, and accepted requirements, the minimal way to do validation is to allow a mapping any time (like when the location is put into the Location Server), and return some kind of error when the location presented is not in the database. So validation means "I have no mapping for that location". A better answer would be to have a mechanism in LoST specifically for validation that could return more information than just "I have no mapping". For example, it would be helpful to return possible alternative valid mappings. A typical example is you query for "100 Main St" and the mapping server returns "I don't have a 100 Main St, but I have a 100 N Main St or 100 S Main St". You could also return an indication of which elements in the input location were valid (Country, State, and City was valid, but Street Name was not). It would also be useful to return information not included in the original request (for example, you query with the postal community name, but leave off county and jurisdictional community name, if a unique mapping was found, the missing data was supplied). It would also be good to have a form of validation for geo, which amounts to "there are no URIs for the service you requested with the location you provided". If you ask for police while you are in the middle of the Atlantic Ocean, you might get that response. Brian > Hi all, > > we need to close issue#35 about location validation. The issue can be > found at: http://www.ietf-ecrit.org:8080/ecrit-req/issue35. > > Note that I provide a summary at the end of my mail. > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-06.txt > says: > > " > Location validation: A caller location is considered valid if the > civic or geographic location is recognizable within an acceptable > location reference systems (e.g., USPS, WGS-84, etc.), and can be > mapped to one or more PSAPs. While it is desirable to determine > that a location exists, validation may not ensure that such a > location exists. Location validation ensures that a location is > able to be referenced for mapping, but makes no assumption about > the association between the caller and the caller's location. > " > > We had a discussion about this subject during the interim meeting: > http://www.ietf-ecrit.org/Interim2006/Jabber-Log_2006-02-01.html > > ---------------- > > [07:53:24] roger: issue 15 re validation of civic > [07:53:39] andy: I thought the list left the issue not about > not doing it, but how. > [07:53:46] roger: need to know about the language in the draft > [07:54:08] brian: something about a way to do it > [07:54:24] jon: related to other req. such as querying it > anywhere. > [07:54:37] james p.: we are no validating > [07:54:56] ted: text in the issue tracker is not the meaning > of validation in NENA, etc... > [07:55:12] ted: this is a valuable piece of protocol machinery. > [07:55:39] james: that makes sense, but the text doesn't say > that > [07:56:03] brian: if validation is defined as succesful > mapping to the PSAP, then that is what we want. > [07:56:11] james: need other word than "valid" > [07:56:28] brian: what we have can be used for NENA view of > the world > [07:57:01] james: anything out of this building to the proper > PSAP, but not floor by floor > [07:57:16] brian: the requirement is to know that you can send > a responder. > [07:57:32] marc: not sure that is the NENA view, re ESN > [07:58:04] brian: the location is knowing we can send a > responder > [07:58:09] nadine: agree > [07:58:52] brian: definition of valdiation to be successful > mapping to occur for the location > [07:59:10] ted: this requirement needs the point brian is making > [07:59:49] james: concerned with people thinking we mean > something much more precise > [08:00:12] hannes: the definition does not match the requirmenet > [08:00:26] roger: let's examine the definition first > [08:01:09] nadine & brian: this is a good defintion > [08:01:15] james: no, that is cumbersome > [08:03:04] henning: problem is that this is trying to define > validation for both civic and geo. first test is syntactic validity. the > description is not clear if the actual address exists. > [08:03:49] henning: second test, is there a valid mapping, > third, is there a street address that can be routed to. > [08:04:14] brian: clarifying this is a good idea. > [08:04:21] nadine: agree with 1 and 2, but not 3 > [08:04:27] roger: we cannot achieve 3 > [08:04:38] henning: then we need to be clear about it > [08:05:36] roger: "but not equivicate to an address" ? > [08:05:58] brian: add new sentence to clarify it. "while > desirable to have the address exist, not guarnateed." > [08:06:46] ted: wandering from the protocol requirement. an > address could be invalid for other purposes but could get mapped to a > PSAP. > [08:07:46] ted: could I give you a PSAP based on the location > given, if answer is yes then that is the one thing we care about > [08:08:01] henning: just need a qualification of what it does > not mean > [08:08:42] brian: agree, see my previous wording > [08:09:17] marc: mentions some use case in Texas. > [08:09:25] brian: but that is not how it will work > [08:09:40] marc: but if the address does not exist, no PSAP > [08:09:46] brian: that is making an assumption > [08:10:35] brian: current MSAG does address ranges, but we > should have ability in future to work on single addresses > [08:11:07] marc: do you believe it shouldn't return an answer? > [08:11:10] brian: ? > [08:11:41] ted: in some administrations, the answer will be > "here is your PSAP, and btw the address you gave is foobar" > [08:13:18] nadine: be able to distinguish if it is the "right" > PSAP vs "default" PSAP? > [08:13:47] ted: for validation it would be "right". > [08:14:33] henning: this has implication on protocol design > choices. > [08:15:57] henning: difference in use case in validation and > non-validation (emergency case) and the bits on the wire in the protocol > [08:16:00] If the case is that the address is 125 main > street, and 124 and 126 exist but 125 does not, would validation > indicate that the address is syntactically valid, the psap returned > would be for 124 and/or 126? > [08:17:19] are you asking a question for the room? > [08:17:36] yes, but we've moved on abit > [08:18:06] I was trying to clarify comments from several > people > [08:19:21] brian: answering randy's q: "I can map it, but it > isn't really valid. But in an emergency, it would send you to the > closest PSAP." > [08:19:32] Thanks, sounds reasonable to me > [08:19:46] marc: result should be saying there is a problem in > XML > [08:19:51] brian: yes > [08:20:12] brian: it is desirable to say you can get a > mapping, but there is a problem with the address. > [08:21:20] henning: even in a real emergency query, this is > nothing wrong with indicating that the address is foobar as long as the > PSAP is returned > [08:22:11] ted: in a real emergency only look at the one thing > they map on. validation may be a different task. > [08:22:47] brian: but that work for you > [08:22:56] ted: that is why this is desirable. > [08:23:04] nadine: ? > [08:23:17] nadine: if you only know that it is a known range > [08:24:34] andy: just need to make sure that implementers > don't let the error show up in the emergency case > [08:24:58] roger: do we agree that in addition to the URL that > it is desirable to have a result code? > [08:25:10] henning: generally, yup/ > [08:25:27] is the audio being recorded? > [08:26:10] henning: it is more than a status code > [08:26:16] roger: additional information? > [08:27:13] hannes: Validation Resolution: it MAY be possible > to return additional information which can be used to determine the > preceision or resolution of the returned sip uri, for example > > ---------------- > > The meeting minutes of the interim meeting indicate: > http://www.ietf-ecrit.org/Interim2006/MeetingMinutes.html > > ---------------- > > Issue 15 > > Validation of civil location has been hanging around for a while. Should > it stay in the 02 draft? Andrew thought the issue was how we would do > validation, not whether. Brian wants to leave the language in, but would > like to know if people think it's adequate (we're using motivations text > to describe what validation means). "A successful mapping will work". > > We actually do have other requirements that talk about this (doing > queries at any time), but we don't describe it anywhere else. > > Are we actually validating? We don't mean NEMA validation, only asking > whether it's enough to get back a PSAP mapping. Passing back "here's the > PSAP" would be sufficient. Can we use another word? "Validation" has > lots of baggage. Brian wants to make sure that we can get to NEMA > validation - "a location that a responder knows how to get to". "A > location that can be sucessfully mapped to one or more PSAPs". > > We're trying to encompass both civil location and geolocation in one > sentence - this is one reason why it's cumbersome. If all of the city of > Washington goes to one PSAP but the location isn't valid, we still have > a problem. MSAG values have the same problem, because they carry street > number ranges and a "valid" street number may not exactly exist - and > the best MSAG validators today can't guarantee that the address exists. > > An address can be "valid enough" to get to the right PSAP, even if it's > not valid to respond to. Texas has one PSAP entry - so anything would > work as long as it's in Texas? No, the current MSAG works on address > ranges - but the street exists. Brian would like for this to work on > individual addresses, not ranges. > > Brian thinks that local PSAPs should be determining what happens for > various values of "invalid", since calls are going to go somewhere! > > Ted thinks that there's a lot of variation in what administrations do > now and will do in the future. > > Will the protocol allow us to tell that we got to the right PSAP, or > just got a PSAP? > > Henning - just returning a SIP URI to let someone ask "where the heck > are you?" isn't sufficient when we're actually routing an emergency call. > > We always get a SIP URI, we're trying to figure out what getting a SIP > URI actually means for an operational system. > > "I got a match on all the XML tags except this one" would be an > acceptable response, and this would be desirable. This could happen at > validation time or at emergency call routing time. > > Validation may mean "I like the only tags that I care about, and didn't > look at the ones I don't care about". > > Do we agree that we need a result code, in addition to a URI? Partial > validation may be the common case (public verifiers won't know suite > numbers/room numbers, for example). > > Is this MUST/SHOULD/MAY? The protocol MUST have the mechanism (whether > it gets used or not is up to the administration). > > And we need to be consistent in our RFC 2119 usage (which is always > problematic for requirements documents anyway, since the meaning is a > protocol-mechanism meaning, not a protocol-usage meaning). We're making > a lot of these requirements MUSTs, and that may make the resulting > protocols clumsy. If we use 2119, we should be using MUST, MAY and > SHOULD, not just MUST. > > Tom pointed out that some mechanisms may be provided by extensions, but > are not required in the base protocol. > > Henning says we're not writing a BCP, so we should consider NOT using > 2119 language. > > Randy suggested that we actually spell out "must support", etc. and not > rely on 2119. Henning - then we should have consistent terminology, > whether it's upper case or lower case. Randy will audit the existing > document, but needs input from others. > > What about returning an indicator of the resolution of the mapping that > is returned? > > Brian suggested text for a mechanism to indicate that a location or part > of location does not exist, even if it can be mapped. Should this point > out the invalid pieces? Aren't these administration-specific? Tags are > roughly self-describing, but we can't pick one hierarchy - what gets > returned needs to be free-form. > > James - doesn't the text say "location should be sent even if it's > considered unreliable?" Is this OK? > > We will leave L01 language as is, change "location validation" in > terminology, and we are adding two new requirements to this section. > > ---------------- > > The discussions regarding Issue#15 caused us to change the following > requirement into two requirements: > http://www.ietf-ecrit.org:8080/ecrit-req/issue15 > > " > > Lo1. Validation of Civic Location: It MUST be possible to > >validate a > > civic location prior to its use in an actual emergency call. > > > > Motivation: Location validation provides an opportunity to help > > assure ahead of time, whether successful mapping to the > > appropriate PSAP will likely occur when it is required. > > Validation may also help to avoid delays during emergency call > > setup due to invalid locations. > > " > > to: > > " > Lo1X. Validation Resolution: The mapping protocol > MUST support the return of additional information which can be used > to determine the precision or resolution of the data elements used to > determine a PSAP URI, for example. > > Lo1XX. Indication of non-existent location: The > protocol MUST support a mechanism to indicate that a location or a > part of a location is known to not exist, even if a valid location-to-PSAP > uri mapping can be provided. > " > > The term validation appears only in the following sections. > > Section 1 (Introduction): > > " > As used in this document, validation of location does not require to > ascertain whether the location actually exists. For example, > validation might only check that the house number in a civic address > falls within the assigned range, not whether that building exists at > that spot. However, such higher precision validation is desirable. > " > > Section 2 (Terminology): > " > Location validation: A caller location is considered valid if the > civic or geographic location is recognizable within an acceptable > location reference systems (e.g., USPS, WGS-84, etc.), and can be > mapped to one or more PSAPs. While it is desirable to determine > that a location exists, validation may not ensure that such a > location exists. Location validation ensures that a location is > able to be referenced for mapping, but makes no assumption about > the association between the caller and the caller's location. > " > > Section 7 (Mapping Protocol): > > " > Ma22. Validation of civic location: The mapping protocol MUST > implement a method via a mapping request, that makes it possible > for a mapping server to validate a civic location prior to that > location's use in an actual emergency call. > > Motivation: Location validation provides an opportunity to help > assure ahead of time, whether successful mapping to the > appropriate PSAP will likely occur when it is required. > Validation may also help to avoid delays during emergency call > setup due to invalid locations. > > Ma23. Validation resolution: The mapping protocol MUST support > (i.e., required to implement, but not required for use) the return > of additional information which can be used to determine the > precision or resolution of the data elements used to determine a > PSAP URI. > > Motivation: The mapping server may not use all the data elements > in the provided location information to determine a match, or may > be able to find a match based on all of the information except for > some specific data elements. The uniqueness of this information > set may be used to differentiate among emergency jurisdictions. > Precision or resolution in the context of this requirement might > mean, for example, explicit identification of the data elements > that were used successfully in the mapping. > > Ma25. Limits to validation: Successful validation of a civic > location MUST NOT be required to place an emergency call. > > Motivation: In some cases, a civic location may not be considered > valid. This fact should not result in the call being dropped or > rejected by any entity along the signaling path to the PSAP. > " > > I think we need to differentiate civic and geospatial location > information. > > Geospatial location information: > > * Can the request be mapped to one or more PSAPs? > > This is normal mapping protocol operation. Nothing special here. > > * Does the address exist? > > There is no question that this address exists > if the coordinate reference system was understood. > > > Civic location information: > > * Can the request be mapped to one or more PSAPs? > > The text from Ma23 is applicable here: > > Motivation: The mapping server may not use all the data elements > in the provided location information to determine a match, or may > be able to find a match based on all of the information except for > some specific data elements. The uniqueness of this information > set may be used to differentiate among emergency jurisdictions. > Precision or resolution in the context of this requirement might > mean, for example, explicit identification of the data elements > that were used successfully in the mapping. > > * Does the address exist? > > It is possible that a given civic address does not exist. > An additional database, which contains the list of existing > addresses, needs to be available. > > > What we can do is to be more specific about the type of behavior we want > from the mapping protocol. > Do we want the client to be able to express that the mapping server > should check the civic address for existence? > Do we want the mapping server to be able to indicate that the civic > address was checked against the database? > I don't think anything needs to be done with regard to geospatial > location info. > > Do we need something else? > > 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 Wed Apr 19 18:23:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWL56-0001sw-Mn; Wed, 19 Apr 2006 18:23:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWL55-0001sr-FN for ecrit@ietf.org; Wed, 19 Apr 2006 18:23:27 -0400 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.43) id 1FWL53-00036T-BT for ecrit@ietf.org; Wed, 19 Apr 2006 18:23:27 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 19 Apr 2006 15:23:24 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k3JMNFRh023563; Wed, 19 Apr 2006 15:23:23 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Apr 2006 15:23:19 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.20.143]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Apr 2006 15:23:18 -0700 Message-Id: <4.3.2.7.2.20060419170909.028cc038@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Apr 2006 17:23:17 -0500 To: br@brianrosen.net, "Hannes Tschofenig" From: "James M. Polk" Subject: Re: [Ecrit] Issue 35: Location Validation In-Reply-To: <59517.209.173.53.233.1145484178.squirrel@www.brianrosen.ne t> References: <4446A7A6.5070908@gmx.net> <4446A7A6.5070908@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 19 Apr 2006 22:23:18.0498 (UTC) FILETIME=[DBF90C20:01C663FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2bb8c7db26f2d12109e0cd8e454db52 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: , Errors-To: ecrit-bounces@ietf.org I agree with almost everything Brian says (surprise!), especially about how to work out additional info if a match isn't made. I'm weary about how to pull this off for geo though, due to the rigidity of what doesn't constitute a match. Given that GPS accuracy is roughly within 15 ft after a few minutes and within a few feet after a bit longer (you get the idea of increasing accuracry with time), with some reports where they are might fall *just* outside of a valid location match, and return an error. This might just occur for someone in the middle of the street, say at a car accident or a hurt child next to their bike, and no one wants this not getting through to a PSAP. Geo almost should have a match to some PSAP if the caller is within a jurisdiction (say a country or state or province or county), and not only when they are at a street address that's nice and neat like civic addresses, but this is an interesting problem we haven't really gotten into to solve for yet, have we. How does the Phase-II cellular world solve this validation question when presented with GPS coordinates to a wreck down a canyon road that has no (housing) lot addresses? If this isn't solved for in an agreed upon way, this almost begs for a "Geo Considerations" ID to have a specific discussion about. At 05:02 PM 4/19/2006 -0500, br@brianrosen.net wrote: >In North America, validation is a well known, and required step in >processing a civic location. In the current system, there is no >validation of geo. > >In the end, validation in the current system means: > Do we know where this location is; can we send someone to help > by giving him this location? > >To do that, there is presently a database, called the Master Street >Address Guide, which contains a list of all the "known" street addresses. >Validation, today, means that before a location is put into the database >that is actually used to determine address when an emergency call is made >(the "ALI" database), the location is looked up in the MSAG. If there is >a match, the update to the ALI is permitted. If there is no match, the >update is not allowed and the carrier attempting to update the ALI has to >go figure out what happened. > >The MSAG database sometimes also is aligned with the database used to >dispatch responders. A location submitted to the responder Computer Aided >Dispatch system must be "MSAG Valid". > >The emergency call system in North America is heavily dependent on >validation; many attempts at coming up with a location don't yield >something unique enough to use for locating where someone is unambiguously >so that help can be dispatched correctly to where they are when they can't >answer questions. This is a firm requirement for us, and we really, >really need to have it. > >The current MSAG would be the natural beginning source of the mapping >database envisioned by ecrit. There are a whole host of formatting and >correlation issues. > >It is essential that validation happen BEFORE an emergency call. Ideally, >it would happen when it happens now; when a location is put into the >database that stores location (the Location Server). > >Given the current design of the ecrit mechanisms, and accepted >requirements, the minimal way to do validation is to allow a mapping any >time (like when the location is put into the Location Server), and return >some kind of error when the location presented is not in the database. So >validation means "I have no mapping for that location". > >A better answer would be to have a mechanism in LoST specifically for >validation that could return more information than just "I have no >mapping". For example, it would be helpful to return possible alternative >valid mappings. A typical example is you query for "100 Main St" and the >mapping server returns "I don't have a 100 Main St, but I have a 100 N >Main St or 100 S Main St". You could also return an indication of which >elements in the input location were valid (Country, State, and City was >valid, but Street Name was not). It would also be useful to return >information not included in the original request (for example, you query >with the postal community name, but leave off county and jurisdictional >community name, if a unique mapping was found, the missing data was >supplied). > >It would also be good to have a form of validation for geo, which amounts >to "there are no URIs for the service you requested with the >location you provided". If you ask for police while you are in the middle >of the Atlantic Ocean, you might get that response. > > >Brian > > Hi all, > > > > we need to close issue#35 about location validation. The issue can be > > found at: http://www.ietf-ecrit.org:8080/ecrit-req/issue35. > > > > Note that I provide a summary at the end of my mail. > > > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-06.txt > > says: > > > > " > > Location validation: A caller location is considered valid if the > > civic or geographic location is recognizable within an acceptable > > location reference systems (e.g., USPS, WGS-84, etc.), and can be > > mapped to one or more PSAPs. While it is desirable to determine > > that a location exists, validation may not ensure that such a > > location exists. Location validation ensures that a location is > > able to be referenced for mapping, but makes no assumption about > > the association between the caller and the caller's location. > > " > > > > We had a discussion about this subject during the interim meeting: > > http://www.ietf-ecrit.org/Interim2006/Jabber-Log_2006-02-01.html > > > > ---------------- > > > > [07:53:24] roger: issue 15 re validation of civic > > [07:53:39] andy: I thought the list left the issue not about > > not doing it, but how. > > [07:53:46] roger: need to know about the language in the draft > > [07:54:08] brian: something about a way to do it > > [07:54:24] jon: related to other req. such as querying it > > anywhere. > > [07:54:37] james p.: we are no validating > > [07:54:56] ted: text in the issue tracker is not the meaning > > of validation in NENA, etc... > > [07:55:12] ted: this is a valuable piece of protocol machinery. > > [07:55:39] james: that makes sense, but the text doesn't say > > that > > [07:56:03] brian: if validation is defined as succesful > > mapping to the PSAP, then that is what we want. > > [07:56:11] james: need other word than "valid" > > [07:56:28] brian: what we have can be used for NENA view of > > the world > > [07:57:01] james: anything out of this building to the proper > > PSAP, but not floor by floor > > [07:57:16] brian: the requirement is to know that you can send > > a responder. > > [07:57:32] marc: not sure that is the NENA view, re ESN > > [07:58:04] brian: the location is knowing we can send a > > responder > > [07:58:09] nadine: agree > > [07:58:52] brian: definition of valdiation to be successful > > mapping to occur for the location > > [07:59:10] ted: this requirement needs the point brian is making > > [07:59:49] james: concerned with people thinking we mean > > something much more precise > > [08:00:12] hannes: the definition does not match the requirmenet > > [08:00:26] roger: let's examine the definition first > > [08:01:09] nadine & brian: this is a good defintion > > [08:01:15] james: no, that is cumbersome > > [08:03:04] henning: problem is that this is trying to define > > validation for both civic and geo. first test is syntactic validity. the > > description is not clear if the actual address exists. > > [08:03:49] henning: second test, is there a valid mapping, > > third, is there a street address that can be routed to. > > [08:04:14] brian: clarifying this is a good idea. > > [08:04:21] nadine: agree with 1 and 2, but not 3 > > [08:04:27] roger: we cannot achieve 3 > > [08:04:38] henning: then we need to be clear about it > > [08:05:36] roger: "but not equivicate to an address" ? > > [08:05:58] brian: add new sentence to clarify it. "while > > desirable to have the address exist, not guarnateed." > > [08:06:46] ted: wandering from the protocol requirement. an > > address could be invalid for other purposes but could get mapped to a > > PSAP. > > [08:07:46] ted: could I give you a PSAP based on the location > > given, if answer is yes then that is the one thing we care about > > [08:08:01] henning: just need a qualification of what it does > > not mean > > [08:08:42] brian: agree, see my previous wording > > [08:09:17] marc: mentions some use case in Texas. > > [08:09:25] brian: but that is not how it will work > > [08:09:40] marc: but if the address does not exist, no PSAP > > [08:09:46] brian: that is making an assumption > > [08:10:35] brian: current MSAG does address ranges, but we > > should have ability in future to work on single addresses > > [08:11:07] marc: do you believe it shouldn't return an answer? > > [08:11:10] brian: ? > > [08:11:41] ted: in some administrations, the answer will be > > "here is your PSAP, and btw the address you gave is foobar" > > [08:13:18] nadine: be able to distinguish if it is the "right" > > PSAP vs "default" PSAP? > > [08:13:47] ted: for validation it would be "right". > > [08:14:33] henning: this has implication on protocol design > > choices. > > [08:15:57] henning: difference in use case in validation and > > non-validation (emergency case) and the bits on the wire in the protocol > > [08:16:00] If the case is that the address is 125 main > > street, and 124 and 126 exist but 125 does not, would validation > > indicate that the address is syntactically valid, the psap returned > > would be for 124 and/or 126? > > [08:17:19] are you asking a question for the room? > > [08:17:36] yes, but we've moved on abit > > [08:18:06] I was trying to clarify comments from several > > people > > [08:19:21] brian: answering randy's q: "I can map it, but it > > isn't really valid. But in an emergency, it would send you to the > > closest PSAP." > > [08:19:32] Thanks, sounds reasonable to me > > [08:19:46] marc: result should be saying there is a problem in > > XML > > [08:19:51] brian: yes > > [08:20:12] brian: it is desirable to say you can get a > > mapping, but there is a problem with the address. > > [08:21:20] henning: even in a real emergency query, this is > > nothing wrong with indicating that the address is foobar as long as the > > PSAP is returned > > [08:22:11] ted: in a real emergency only look at the one thing > > they map on. validation may be a different task. > > [08:22:47] brian: but that work for you > > [08:22:56] ted: that is why this is desirable. > > [08:23:04] nadine: ? > > [08:23:17] nadine: if you only know that it is a known range > > [08:24:34] andy: just need to make sure that implementers > > don't let the error show up in the emergency case > > [08:24:58] roger: do we agree that in addition to the URL that > > it is desirable to have a result code? > > [08:25:10] henning: generally, yup/ > > [08:25:27] is the audio being recorded? > > [08:26:10] henning: it is more than a status code > > [08:26:16] roger: additional information? > > [08:27:13] hannes: Validation Resolution: it MAY be possible > > to return additional information which can be used to determine the > > preceision or resolution of the returned sip uri, for example > > > > ---------------- > > > > The meeting minutes of the interim meeting indicate: > > http://www.ietf-ecrit.org/Interim2006/MeetingMinutes.html > > > > ---------------- > > > > Issue 15 > > > > Validation of civil location has been hanging around for a while. Should > > it stay in the 02 draft? Andrew thought the issue was how we would do > > validation, not whether. Brian wants to leave the language in, but would > > like to know if people think it's adequate (we're using motivations text > > to describe what validation means). "A successful mapping will work". > > > > We actually do have other requirements that talk about this (doing > > queries at any time), but we don't describe it anywhere else. > > > > Are we actually validating? We don't mean NEMA validation, only asking > > whether it's enough to get back a PSAP mapping. Passing back "here's the > > PSAP" would be sufficient. Can we use another word? "Validation" has > > lots of baggage. Brian wants to make sure that we can get to NEMA > > validation - "a location that a responder knows how to get to". "A > > location that can be sucessfully mapped to one or more PSAPs". > > > > We're trying to encompass both civil location and geolocation in one > > sentence - this is one reason why it's cumbersome. If all of the city of > > Washington goes to one PSAP but the location isn't valid, we still have > > a problem. MSAG values have the same problem, because they carry street > > number ranges and a "valid" street number may not exactly exist - and > > the best MSAG validators today can't guarantee that the address exists. > > > > An address can be "valid enough" to get to the right PSAP, even if it's > > not valid to respond to. Texas has one PSAP entry - so anything would > > work as long as it's in Texas? No, the current MSAG works on address > > ranges - but the street exists. Brian would like for this to work on > > individual addresses, not ranges. > > > > Brian thinks that local PSAPs should be determining what happens for > > various values of "invalid", since calls are going to go somewhere! > > > > Ted thinks that there's a lot of variation in what administrations do > > now and will do in the future. > > > > Will the protocol allow us to tell that we got to the right PSAP, or > > just got a PSAP? > > > > Henning - just returning a SIP URI to let someone ask "where the heck > > are you?" isn't sufficient when we're actually routing an emergency call. > > > > We always get a SIP URI, we're trying to figure out what getting a SIP > > URI actually means for an operational system. > > > > "I got a match on all the XML tags except this one" would be an > > acceptable response, and this would be desirable. This could happen at > > validation time or at emergency call routing time. > > > > Validation may mean "I like the only tags that I care about, and didn't > > look at the ones I don't care about". > > > > Do we agree that we need a result code, in addition to a URI? Partial > > validation may be the common case (public verifiers won't know suite > > numbers/room numbers, for example). > > > > Is this MUST/SHOULD/MAY? The protocol MUST have the mechanism (whether > > it gets used or not is up to the administration). > > > > And we need to be consistent in our RFC 2119 usage (which is always > > problematic for requirements documents anyway, since the meaning is a > > protocol-mechanism meaning, not a protocol-usage meaning). We're making > > a lot of these requirements MUSTs, and that may make the resulting > > protocols clumsy. If we use 2119, we should be using MUST, MAY and > > SHOULD, not just MUST. > > > > Tom pointed out that some mechanisms may be provided by extensions, but > > are not required in the base protocol. > > > > Henning says we're not writing a BCP, so we should consider NOT using > > 2119 language. > > > > Randy suggested that we actually spell out "must support", etc. and not > > rely on 2119. Henning - then we should have consistent terminology, > > whether it's upper case or lower case. Randy will audit the existing > > document, but needs input from others. > > > > What about returning an indicator of the resolution of the mapping that > > is returned? > > > > Brian suggested text for a mechanism to indicate that a location or part > > of location does not exist, even if it can be mapped. Should this point > > out the invalid pieces? Aren't these administration-specific? Tags are > > roughly self-describing, but we can't pick one hierarchy - what gets > > returned needs to be free-form. > > > > James - doesn't the text say "location should be sent even if it's > > considered unreliable?" Is this OK? > > > > We will leave L01 language as is, change "location validation" in > > terminology, and we are adding two new requirements to this section. > > > > ---------------- > > > > The discussions regarding Issue#15 caused us to change the following > > requirement into two requirements: > > http://www.ietf-ecrit.org:8080/ecrit-req/issue15 > > > > " > > > Lo1. Validation of Civic Location: It MUST be possible to > > >validate a > > > civic location prior to its use in an actual emergency call. > > > > > > Motivation: Location validation provides an opportunity to help > > > assure ahead of time, whether successful mapping to the > > > appropriate PSAP will likely occur when it is required. > > > Validation may also help to avoid delays during emergency call > > > setup due to invalid locations. > > > > " > > > > to: > > > > " > > Lo1X. Validation Resolution: The mapping protocol > > MUST support the return of additional information which can be used > > to determine the precision or resolution of the data elements used to > > determine a PSAP URI, for example. > > > > Lo1XX. Indication of non-existent location: The > > protocol MUST support a mechanism to indicate that a location or a > > part of a location is known to not exist, even if a valid location-to-PSAP > > uri mapping can be provided. > > " > > > > The term validation appears only in the following sections. > > > > Section 1 (Introduction): > > > > " > > As used in this document, validation of location does not require to > > ascertain whether the location actually exists. For example, > > validation might only check that the house number in a civic address > > falls within the assigned range, not whether that building exists at > > that spot. However, such higher precision validation is desirable. > > " > > > > Section 2 (Terminology): > > " > > Location validation: A caller location is considered valid if the > > civic or geographic location is recognizable within an acceptable > > location reference systems (e.g., USPS, WGS-84, etc.), and can be > > mapped to one or more PSAPs. While it is desirable to determine > > that a location exists, validation may not ensure that such a > > location exists. Location validation ensures that a location is > > able to be referenced for mapping, but makes no assumption about > > the association between the caller and the caller's location. > > " > > > > Section 7 (Mapping Protocol): > > > > " > > Ma22. Validation of civic location: The mapping protocol MUST > > implement a method via a mapping request, that makes it possible > > for a mapping server to validate a civic location prior to that > > location's use in an actual emergency call. > > > > Motivation: Location validation provides an opportunity to help > > assure ahead of time, whether successful mapping to the > > appropriate PSAP will likely occur when it is required. > > Validation may also help to avoid delays during emergency call > > setup due to invalid locations. > > > > Ma23. Validation resolution: The mapping protocol MUST support > > (i.e., required to implement, but not required for use) the return > > of additional information which can be used to determine the > > precision or resolution of the data elements used to determine a > > PSAP URI. > > > > Motivation: The mapping server may not use all the data elements > > in the provided location information to determine a match, or may > > be able to find a match based on all of the information except for > > some specific data elements. The uniqueness of this information > > set may be used to differentiate among emergency jurisdictions. > > Precision or resolution in the context of this requirement might > > mean, for example, explicit identification of the data elements > > that were used successfully in the mapping. > > > > Ma25. Limits to validation: Successful validation of a civic > > location MUST NOT be required to place an emergency call. > > > > Motivation: In some cases, a civic location may not be considered > > valid. This fact should not result in the call being dropped or > > rejected by any entity along the signaling path to the PSAP. > > " > > > > I think we need to differentiate civic and geospatial location > > information. > > > > Geospatial location information: > > > > * Can the request be mapped to one or more PSAPs? > > > > This is normal mapping protocol operation. Nothing special here. > > > > * Does the address exist? > > > > There is no question that this address exists > > if the coordinate reference system was understood. > > > > > > Civic location information: > > > > * Can the request be mapped to one or more PSAPs? > > > > The text from Ma23 is applicable here: > > > > Motivation: The mapping server may not use all the data elements > > in the provided location information to determine a match, or may > > be able to find a match based on all of the information except for > > some specific data elements. The uniqueness of this information > > set may be used to differentiate among emergency jurisdictions. > > Precision or resolution in the context of this requirement might > > mean, for example, explicit identification of the data elements > > that were used successfully in the mapping. > > > > * Does the address exist? > > > > It is possible that a given civic address does not exist. > > An additional database, which contains the list of existing > > addresses, needs to be available. > > > > > > What we can do is to be more specific about the type of behavior we want > > from the mapping protocol. > > Do we want the client to be able to express that the mapping server > > should check the civic address for existence? > > Do we want the mapping server to be able to indicate that the civic > > address was checked against the database? > > I don't think anything needs to be done with regard to geospatial > > location info. > > > > Do we need something else? > > > > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 19 19:33:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWMB8-0006XE-43; Wed, 19 Apr 2006 19:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWMB6-0006X9-UU for ecrit@ietf.org; Wed, 19 Apr 2006 19:33:44 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWMB4-0007c0-KD for ecrit@ietf.org; Wed, 19 Apr 2006 19:33:44 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 19 Apr 2006 16:33:41 -0700 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] Issue 35: Location Validation Date: Wed, 19 Apr 2006 16:33:40 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504BBB7FA@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Issue 35: Location Validation Thread-Index: AcZj/+aJ+lnwlAw7RW+hcTe5Xl181QABex5g From: "Roger Marshall" To: "James M. Polk" , , "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92bf9d0448089f15cee3c3c378c3e25d 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: , Errors-To: ecrit-bounces@ietf.org I think Brian answered most of these, but since I didn't see them captured individually, here's my take: [from Hannes, (ref. re-pasted from summary at end)] What we can do is to be more specific about the type of behavior we want from the mapping protocol. Do we want the client to be able to express that the mapping server should check the civic address for existence? [RM] - Yes, I think so. I propose the following new requirements: LoX'. The mapping protocol MUST support a mechanism which provides an indication as to whether a specific civic location exists. LoX''. The mapping protocol MUST support a mechanism which provides an indication that specific civic location does not exist exactly, but does fall within a acceptable range of (address) values. LoX'''. The mapping protocol MUST support a mechanism which provides alternate location choices, based on matching criteria (e.g., if 123 Main St. DNE, might return "'123 S. Main St.' or '123 N. Main St.' alternates exist"). LoX''''. The mapping protocol MUST support a mechanism which provides an indication of which data elements of a civic location were, and were not found in the database (e.g., "'123 Main St. Mytown' not found, but 'Main St. Mytown' was found". Do we want the mapping server to be able to indicate that the civic address was checked against the database? [RM] - Yes, and precisely which database. Here's my suggested requirement: LoY. The mapping protocol MUST support a mechanism which provides an indication as to a specific "type" of location database used for either civic or geographic location matching (e.g., USPS, MSAG, GDT, etc.). I don't think anything needs to be done with regard to geospatial location info.=20 [RM] - I agree that for the requirements draft, geo is probably covered well enough, but as James pointed out, a subsequent geo-specific draft would be useful. Roger Marshall. >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com]=20 >Sent: Wednesday, April 19, 2006 3:23 PM >To: br@brianrosen.net; Hannes Tschofenig >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] Issue 35: Location Validation > >I agree with almost everything Brian says (surprise!),=20 >especially about how to work out additional info if a match isn't made. > >I'm weary about how to pull this off for geo though, due to=20 >the rigidity of what doesn't constitute a match. Given that=20 >GPS accuracy is roughly within >15 ft after a few minutes and within a few feet after a bit=20 >longer (you get the idea of increasing accuracry with time),=20 >with some reports where they are might fall *just* outside of=20 >a valid location match, and return an error. This might just=20 >occur for someone in the middle of the street, say at a car=20 >accident or a hurt child next to their bike, and no one wants=20 >this not getting through to a PSAP. > >Geo almost should have a match to some PSAP if the caller is=20 >within a jurisdiction (say a country or state or province or=20 >county), and not only when they are at a street address that's=20 >nice and neat like civic addresses, but this is an interesting=20 >problem we haven't really gotten into to solve for yet, have we. > >How does the Phase-II cellular world solve this validation=20 >question when presented with GPS coordinates to a wreck down a=20 >canyon road that has no >(housing) lot addresses? > >If this isn't solved for in an agreed upon way, this almost=20 >begs for a "Geo Considerations" ID to have a specific discussion about. > >At 05:02 PM 4/19/2006 -0500, br@brianrosen.net wrote: >>In North America, validation is a well known, and required step in=20 >>processing a civic location. In the current system, there is no=20 >>validation of geo. >> >>In the end, validation in the current system means: >> Do we know where this location is; can we send someone to help >> by giving him this location? >> >>To do that, there is presently a database, called the Master Street=20 >>Address Guide, which contains a list of all the "known"=20 >street addresses. >>Validation, today, means that before a location is put into the=20 >>database that is actually used to determine address when an emergency=20 >>call is made (the "ALI" database), the location is looked up in the=20 >>MSAG. If there is a match, the update to the ALI is permitted. If=20 >>there is no match, the update is not allowed and the carrier=20 >attempting=20 >>to update the ALI has to go figure out what happened. >> >>The MSAG database sometimes also is aligned with the database used to=20 >>dispatch responders. A location submitted to the responder Computer=20 >>Aided Dispatch system must be "MSAG Valid". >> >>The emergency call system in North America is heavily dependent on=20 >>validation; many attempts at coming up with a location don't yield=20 >>something unique enough to use for locating where someone is=20 >>unambiguously so that help can be dispatched correctly to where they=20 >>are when they can't answer questions. This is a firm requirement for=20 >>us, and we really, really need to have it. >> >>The current MSAG would be the natural beginning source of the mapping=20 >>database envisioned by ecrit. There are a whole host of=20 >formatting and=20 >>correlation issues. >> >>It is essential that validation happen BEFORE an emergency call. =20 >>Ideally, it would happen when it happens now; when a location is put=20 >>into the database that stores location (the Location Server). >> >>Given the current design of the ecrit mechanisms, and accepted=20 >>requirements, the minimal way to do validation is to allow a mapping=20 >>any time (like when the location is put into the Location=20 >Server), and=20 >>return some kind of error when the location presented is not in the=20 >>database. So validation means "I have no mapping for that location". >> >>A better answer would be to have a mechanism in LoST specifically for=20 >>validation that could return more information than just "I have no=20 >>mapping". For example, it would be helpful to return possible=20 >>alternative valid mappings. A typical example is you query for "100=20 >>Main St" and the mapping server returns "I don't have a 100 Main St,=20 >>but I have a 100 N Main St or 100 S Main St". You could also=20 >return an=20 >>indication of which elements in the input location were valid=20 >(Country,=20 >>State, and City was valid, but Street Name was not). It=20 >would also be=20 >>useful to return information not included in the original=20 >request (for=20 >>example, you query with the postal community name, but leave=20 >off county=20 >>and jurisdictional community name, if a unique mapping was found, the=20 >>missing data was supplied). >> >>It would also be good to have a form of validation for geo, which=20 >>amounts to "there are no URIs for the service you requested with the=20 >> location you provided". If you ask for police while you are in=20 >>the middle of the Atlantic Ocean, you might get that response. >> >> >>Brian >> > Hi all, >> > >> > we need to close issue#35 about location validation. The issue can=20 >> > be found at: http://www.ietf-ecrit.org:8080/ecrit-req/issue35. >> > >> > Note that I provide a summary at the end of my mail. >> > >> >=20 >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-06 >> > .txt >> > says: >> > >> > " >> > Location validation: A caller location is considered=20 >valid if the >> > civic or geographic location is recognizable within=20 >an acceptable >> > location reference systems (e.g., USPS, WGS-84,=20 >etc.), and can be >> > mapped to one or more PSAPs. While it is desirable=20 >to determine >> > that a location exists, validation may not ensure=20 >that such a >> > location exists. Location validation ensures that=20 >a location is >> > able to be referenced for mapping, but makes no=20 >assumption about >> > the association between the caller and the caller's=20 >location. >> > " >> > >> > We had a discussion about this subject during the interim meeting: >> > http://www.ietf-ecrit.org/Interim2006/Jabber-Log_2006-02-01.html >> > >> > ---------------- >> > >> > [07:53:24] roger: issue 15 re validation of civic=20 >> > [07:53:39] andy: I thought the list left the issue not=20 >> > about not doing it, but how. >> > [07:53:46] roger: need to know about the language in the=20 >> > draft [07:54:08] brian: something about a way to do it=20 >> > [07:54:24] jon: related to other req. such as=20 >querying it=20 >> > anywhere. >> > [07:54:37] james p.: we are no validating [07:54:56]=20 >> > ted: text in the issue tracker is not the meaning of=20 >> > validation in NENA, etc... >> > [07:55:12] ted: this is a valuable piece of=20 >protocol machinery. >> > [07:55:39] james: that makes sense, but the text doesn't=20 >> > say that [07:56:03] brian: if validation is defined as=20 >> > succesful mapping to the PSAP, then that is what we want. >> > [07:56:11] james: need other word than "valid" >> > [07:56:28] brian: what we have can be used for NENA view=20 >> > of the world [07:57:01] james: anything out of this=20 >> > building to the proper PSAP, but not floor by floor [07:57:16]=20 >> > brian: the requirement is to know that you can send a=20 >> > responder. >> > [07:57:32] marc: not sure that is the NENA view, re ESN=20 >> > [07:58:04] brian: the location is knowing we can send a=20 >> > responder [07:58:09] nadine: agree [07:58:52] =20 >> > brian: definition of valdiation to be successful mapping to occur=20 >> > for the location [07:59:10] ted: this requirement needs=20 >> > the point brian is making [07:59:49] james:=20 >concerned with=20 >> > people thinking we mean something much more precise [08:00:12]=20 >> > hannes: the definition does not match the requirmenet=20 >> > [08:00:26] roger: let's examine the definition first=20 >> > [08:01:09] nadine & brian: this is a good defintion=20 >> > [08:01:15] james: no, that is cumbersome [08:03:04]=20 >> > henning: problem is that this is trying to define=20 >> > validation for both civic and geo. first test is syntactic=20 >validity.=20 >> > the description is not clear if the actual address exists. >> > [08:03:49] henning: second test, is there a=20 >valid mapping,=20 >> > third, is there a street address that can be routed to. >> > [08:04:14] brian: clarifying this is a good idea. >> > [08:04:21] nadine: agree with 1 and 2, but not 3=20 >> > [08:04:27] roger: we cannot achieve 3 [08:04:38]=20 >=20 >> > henning: then we need to be clear about it [08:05:36] =20 >> > roger: "but not equivicate to an address" ? >> > [08:05:58] brian: add new sentence to clarify it. "while=20 >> > desirable to have the address exist, not guarnateed." >> > [08:06:46] ted: wandering from the protocol requirement.=20 >> > an address could be invalid for other purposes but could=20 >get mapped=20 >> > to a PSAP. >> > [08:07:46] ted: could I give you a PSAP based on the=20 >> > location given, if answer is yes then that is the one=20 >thing we care=20 >> > about [08:08:01] henning: just need a qualification of=20 >> > what it does not mean [08:08:42] brian: agree, see my=20 >> > previous wording [08:09:17] marc: mentions some use case=20 >> > in Texas. >> > [08:09:25] brian: but that is not how it will work=20 >> > [08:09:40] marc: but if the address does not exist, no=20 >> > PSAP [08:09:46] brian: that is making an assumption=20 >> > [08:10:35] brian: current MSAG does address=20 >ranges, but we=20 >> > should have ability in future to work on single addresses=20 >[08:11:07]=20 >> > marc: do you believe it shouldn't return an answer? >> > [08:11:10] brian: ? >> > [08:11:41] ted: in some administrations, the answer will=20 >> > be "here is your PSAP, and btw the address you gave is foobar" >> > [08:13:18] nadine: be able to distinguish if it=20 >is the "right" >> > PSAP vs "default" PSAP? >> > [08:13:47] ted: for validation it would be "right". >> > [08:14:33] henning: this has implication on protocol=20 >> > design choices. >> > [08:15:57] henning: difference in use case in validation=20 >> > and non-validation (emergency case) and the bits on the=20 >wire in the=20 >> > protocol [08:16:00] If the case is that the address is=20 >> > 125 main street, and 124 and 126 exist but 125 does not, would=20 >> > validation indicate that the address is syntactically valid, the=20 >> > psap returned would be for 124 and/or 126? >> > [08:17:19] are you asking a question for the room? >> > [08:17:36] yes, but we've moved on abit [08:18:06]=20 >> > I was trying to clarify comments from several people=20 >> > [08:19:21] brian: answering randy's q: "I can=20 >map it, but=20 >> > it isn't really valid. But in an emergency, it would send=20 >you to the=20 >> > closest PSAP." >> > [08:19:32] Thanks, sounds reasonable to me [08:19:46]=20 >> > marc: result should be saying there is a problem in XML=20 >> > [08:19:51] brian: yes [08:20:12] brian: it is=20 >> > desirable to say you can get a mapping, but there is a=20 >problem with=20 >> > the address. >> > [08:21:20] henning: even in a real emergency query, this=20 >> > is nothing wrong with indicating that the address is=20 >foobar as long=20 >> > as the PSAP is returned [08:22:11] ted: in a real=20 >> > emergency only look at the one thing they map on.=20 >validation may be=20 >> > a different task. >> > [08:22:47] brian: but that work for you [08:22:56]=20 >> > ted: that is why this is desirable. >> > [08:23:04] nadine: ? >> > [08:23:17] nadine: if you only know that it is a known=20 >> > range [08:24:34] andy: just need to make sure that=20 >> > implementers don't let the error show up in the emergency case=20 >> > [08:24:58] roger: do we agree that in addition=20 >to the URL=20 >> > that it is desirable to have a result code? >> > [08:25:10] henning: generally, yup/ [08:25:27] =20 >> > is the audio being recorded? >> > [08:26:10] henning: it is more than a status code=20 >> > [08:26:16] roger: additional information? >> > [08:27:13] hannes: Validation Resolution: it MAY be=20 >> > possible to return additional information which can be used to=20 >> > determine the preceision or resolution of the returned sip=20 >uri, for=20 >> > example >> > >> > ---------------- >> > >> > The meeting minutes of the interim meeting indicate: >> > http://www.ietf-ecrit.org/Interim2006/MeetingMinutes.html >> > >> > ---------------- >> > >> > Issue 15 >> > >> > Validation of civil location has been hanging around for a while.=20 >> > Should it stay in the 02 draft? Andrew thought the issue=20 >was how we=20 >> > would do validation, not whether. Brian wants to leave the=20 >language=20 >> > in, but would like to know if people think it's adequate (we're=20 >> > using motivations text to describe what validation means).=20 >"A successful mapping will work". >> > >> > We actually do have other requirements that talk about this (doing=20 >> > queries at any time), but we don't describe it anywhere else. >> > >> > Are we actually validating? We don't mean NEMA validation, only=20 >> > asking whether it's enough to get back a PSAP mapping.=20 >Passing back=20 >> > "here's the PSAP" would be sufficient. Can we use another word?=20 >> > "Validation" has lots of baggage. Brian wants to make sure that we=20 >> > can get to NEMA validation - "a location that a responder=20 >knows how=20 >> > to get to". "A location that can be sucessfully mapped to=20 >one or more PSAPs". >> > >> > We're trying to encompass both civil location and=20 >geolocation in one=20 >> > sentence - this is one reason why it's cumbersome. If all of the=20 >> > city of Washington goes to one PSAP but the location isn't=20 >valid, we=20 >> > still have a problem. MSAG values have the same problem, because=20 >> > they carry street number ranges and a "valid" street=20 >number may not=20 >> > exactly exist - and the best MSAG validators today can't=20 >guarantee that the address exists. >> > >> > An address can be "valid enough" to get to the right PSAP, even if=20 >> > it's not valid to respond to. Texas has one PSAP entry -=20 >so anything=20 >> > would work as long as it's in Texas? No, the current MSAG works on=20 >> > address ranges - but the street exists. Brian would like=20 >for this to=20 >> > work on individual addresses, not ranges. >> > >> > Brian thinks that local PSAPs should be determining what=20 >happens for=20 >> > various values of "invalid", since calls are going to go somewhere! >> > >> > Ted thinks that there's a lot of variation in what administrations=20 >> > do now and will do in the future. >> > >> > Will the protocol allow us to tell that we got to the=20 >right PSAP, or=20 >> > just got a PSAP? >> > >> > Henning - just returning a SIP URI to let someone ask "where the=20 >> > heck are you?" isn't sufficient when we're actually=20 >routing an emergency call. >> > >> > We always get a SIP URI, we're trying to figure out what getting a=20 >> > SIP URI actually means for an operational system. >> > >> > "I got a match on all the XML tags except this one" would be an=20 >> > acceptable response, and this would be desirable. This=20 >could happen=20 >> > at validation time or at emergency call routing time. >> > >> > Validation may mean "I like the only tags that I care about, and=20 >> > didn't look at the ones I don't care about". >> > >> > Do we agree that we need a result code, in addition to a URI?=20 >> > Partial validation may be the common case (public verifiers won't=20 >> > know suite numbers/room numbers, for example). >> > >> > Is this MUST/SHOULD/MAY? The protocol MUST have the mechanism=20 >> > (whether it gets used or not is up to the administration). >> > >> > And we need to be consistent in our RFC 2119 usage (which=20 >is always=20 >> > problematic for requirements documents anyway, since the=20 >meaning is=20 >> > a protocol-mechanism meaning, not a protocol-usage meaning). We're=20 >> > making a lot of these requirements MUSTs, and that may make the=20 >> > resulting protocols clumsy. If we use 2119, we should be=20 >using MUST,=20 >> > MAY and SHOULD, not just MUST. >> > >> > Tom pointed out that some mechanisms may be provided by=20 >extensions,=20 >> > but are not required in the base protocol. >> > >> > Henning says we're not writing a BCP, so we should consider NOT=20 >> > using >> > 2119 language. >> > >> > Randy suggested that we actually spell out "must support",=20 >etc. and=20 >> > not rely on 2119. Henning - then we should have consistent=20 >> > terminology, whether it's upper case or lower case. Randy=20 >will audit=20 >> > the existing document, but needs input from others. >> > >> > What about returning an indicator of the resolution of the mapping=20 >> > that is returned? >> > >> > Brian suggested text for a mechanism to indicate that a=20 >location or=20 >> > part of location does not exist, even if it can be mapped. Should=20 >> > this point out the invalid pieces? Aren't these=20 >> > administration-specific? Tags are roughly self-describing, but we=20 >> > can't pick one hierarchy - what gets returned needs to be=20 >free-form. >> > >> > James - doesn't the text say "location should be sent even if it's=20 >> > considered unreliable?" Is this OK? >> > >> > We will leave L01 language as is, change "location validation" in=20 >> > terminology, and we are adding two new requirements to=20 >this section. >> > >> > ---------------- >> > >> > The discussions regarding Issue#15 caused us to change the=20 >following=20 >> > requirement into two requirements: >> > http://www.ietf-ecrit.org:8080/ecrit-req/issue15 >> > >> > " >> > > Lo1. Validation of Civic Location: It MUST be possible to >> > >validate a >> > > civic location prior to its use in an actual=20 >emergency call. >> > > >> > > Motivation: Location validation provides an=20 >opportunity to help >> > > assure ahead of time, whether successful mapping to the >> > > appropriate PSAP will likely occur when it is required. >> > > Validation may also help to avoid delays during=20 >emergency call >> > > setup due to invalid locations. >> > >> > " >> > >> > to: >> > >> > " >> > Lo1X. Validation Resolution: The mapping protocol MUST=20 >support the=20 >> > return of additional information which can be used to=20 >determine the=20 >> > precision or resolution of the data elements used to determine a=20 >> > PSAP URI, for example. >> > >> > Lo1XX. Indication of non-existent location: The protocol MUST=20 >> > support a mechanism to indicate that a location or a part of a=20 >> > location is known to not exist, even if a valid=20 >location-to-PSAP uri=20 >> > mapping can be provided. >> > " >> > >> > The term validation appears only in the following sections. >> > >> > Section 1 (Introduction): >> > >> > " >> > As used in this document, validation of location does=20 >not require to >> > ascertain whether the location actually exists. For example, >> > validation might only check that the house number in a=20 >civic address >> > falls within the assigned range, not whether that=20 >building exists at >> > that spot. However, such higher precision validation=20 >is desirable. >> > " >> > >> > Section 2 (Terminology): >> > " >> > Location validation: A caller location is considered=20 >valid if the >> > civic or geographic location is recognizable within=20 >an acceptable >> > location reference systems (e.g., USPS, WGS-84,=20 >etc.), and can be >> > mapped to one or more PSAPs. While it is desirable=20 >to determine >> > that a location exists, validation may not ensure=20 >that such a >> > location exists. Location validation ensures that=20 >a location is >> > able to be referenced for mapping, but makes no=20 >assumption about >> > the association between the caller and the caller's=20 >location. >> > " >> > >> > Section 7 (Mapping Protocol): >> > >> > " >> > Ma22. Validation of civic location: The mapping protocol MUST >> > implement a method via a mapping request, that=20 >makes it possible >> > for a mapping server to validate a civic location=20 >prior to that >> > location's use in an actual emergency call. >> > >> > Motivation: Location validation provides an=20 >opportunity to help >> > assure ahead of time, whether successful mapping to the >> > appropriate PSAP will likely occur when it is required. >> > Validation may also help to avoid delays during=20 >emergency call >> > setup due to invalid locations. >> > >> > Ma23. Validation resolution: The mapping protocol MUST support >> > (i.e., required to implement, but not required for=20 >use) the return >> > of additional information which can be used to determine the >> > precision or resolution of the data elements used=20 >to determine a >> > PSAP URI. >> > >> > Motivation: The mapping server may not use all the=20 >data elements >> > in the provided location information to determine a=20 >match, or may >> > be able to find a match based on all of the=20 >information except for >> > some specific data elements. The uniqueness of=20 >this information >> > set may be used to differentiate among emergency=20 >jurisdictions. >> > Precision or resolution in the context of this=20 >requirement might >> > mean, for example, explicit identification of the=20 >data elements >> > that were used successfully in the mapping. >> > >> > Ma25. Limits to validation: Successful validation of a civic >> > location MUST NOT be required to place an emergency call. >> > >> > Motivation: In some cases, a civic location may not=20 >be considered >> > valid. This fact should not result in the call=20 >being dropped or >> > rejected by any entity along the signaling path to the PSAP. >> > " >> > >> > I think we need to differentiate civic and geospatial location=20 >> > information. >> > >> > Geospatial location information: >> > >> > * Can the request be mapped to one or more PSAPs? >> > >> > This is normal mapping protocol operation. Nothing=20 >special here. >> > >> > * Does the address exist? >> > >> > There is no question that this address exists >> > if the coordinate reference system was understood. >> > >> > >> > Civic location information: >> > >> > * Can the request be mapped to one or more PSAPs? >> > >> > The text from Ma23 is applicable here: >> > >> > Motivation: The mapping server may not use all the=20 >data elements >> > in the provided location information to determine a=20 >match, or may >> > be able to find a match based on all of the=20 >information except for >> > some specific data elements. The uniqueness of=20 >this information >> > set may be used to differentiate among emergency=20 >jurisdictions. >> > Precision or resolution in the context of this=20 >requirement might >> > mean, for example, explicit identification of the=20 >data elements >> > that were used successfully in the mapping. >> > >> > * Does the address exist? >> > >> > It is possible that a given civic address does not exist. >> > An additional database, which contains the list of existing >> > addresses, needs to be available. >> > >> > >> > What we can do is to be more specific about the type of=20 >behavior we=20 >> > want from the mapping protocol. >> > Do we want the client to be able to express that the=20 >mapping server=20 >> > should check the civic address for existence? >> > Do we want the mapping server to be able to indicate that=20 >the civic=20 >> > address was checked against the database? >> > I don't think anything needs to be done with regard to geospatial=20 >> > location info. >> > >> > Do we need something else? >> > >> > 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 > >_______________________________________________ >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 Apr 19 20:05:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWMfp-0007L4-5e; Wed, 19 Apr 2006 20:05:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWMfn-0007Ky-G5 for ecrit@ietf.org; Wed, 19 Apr 2006 20:05:27 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWMfl-0000EG-Jb for ecrit@ietf.org; Wed, 19 Apr 2006 20:05:27 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Apr 2006 19:05:20 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 19 Apr 2006 19:05:20 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Apr 2006 19:05:22 -0500 Message-ID: From: "Thomson, Martin" To: "James M. Polk" Date: Wed, 19 Apr 2006 19:05:08 -0500 Subject: RE: [Ecrit] Issue 35: Location Validation - Geodetic 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 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 20 Apr 2006 00:05:22.0648 (UTC) FILETIME=[1E402D80:01C6640E] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Issue 35: Location Validation - Geodetic Thread-Index: AcZj/+M3bWQG4S6BQJKXbbojbP3sLgACliyt X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e831a3b581a967a651997b2cbc2bae7 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: , Errors-To: ecrit-bounces@ietf.org I don't think that this is a real problem. Geodetic information would be e= valuated against a set of PSAP boundary polygons, not converted to civic, a= s you seem to imply (my reading). Presumably there would be no black spots= not covered by PSAPs, except perhaps in international waters (and I'm happ= y to leave that one for now). A request for a route occurs at an instant i= n time, with the information that is available at that time, irrespective o= f it's accuracy. =20 There is no real concept of validation in Phase-II E-911. Currently, each = serving cell is mapped to a PSAP and the switch routes the call to the SR b= ased on the serving cell identifier. That is, routes are statically config= ured. If J-STD 36-B with it's X-Y routing functionality were more widely d= eployed, then a coarse estimate would be used (almost as coarse as cell in = effect) against the PSAP boundaries, which are represented as polygonal are= as. =20 The point being that geodetic infomation is rarely, if ever going to produc= e a no-route result. That problem is one for civic addresses. Civic valid= ation may also be a problem only in certain countries; for routing, Austral= ia would be fine with one civic field only, which would make our validation= database very easy to implement. =20 Cheers, Martin =20 p.s.Note that PSAP boundaries for wireline and cellular can differ slightly= because of this. It's possible to reach different PSAPs from a landline a= nd mobile phone right next to each other. And yes, misrouting is very comm= on, X-Y is supposed to help with that...a little. ________________________________ From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Thu 4/20/2006 8:23 AM To: br@brianrosen.net; Hannes Tschofenig Cc: ecrit@ietf.org Subject: Re: [Ecrit] Issue 35: Location Validation I agree with almost everything Brian says (surprise!), especially about how to work out additional info if a match isn't made. I'm weary about how to pull this off for geo though, due to the rigidity of what doesn't constitute a match. Given that GPS accuracy is roughly within 15 ft after a few minutes and within a few feet after a bit longer (you get the idea of increasing accuracry with time), with some reports where they are might fall *just* outside of a valid location match, and return an error. This might just occur for someone in the middle of the street, say at a car accident or a hurt child next to their bike, and no one wants this not getting through to a PSAP. Geo almost should have a match to some PSAP if the caller is within a jurisdiction (say a country or state or province or county), and not only when they are at a street address that's nice and neat like civic addresses, but this is an interesting problem we haven't really gotten into to solve for yet, have we. How does the Phase-II cellular world solve this validation question when presented with GPS coordinates to a wreck down a canyon road that has no (housing) lot addresses? If this isn't solved for in an agreed upon way, this almost begs for a "Geo Considerations" ID to have a specific discussion about. At 05:02 PM 4/19/2006 -0500, br@brianrosen.net wrote: >In North America, validation is a well known, and required step in >processing a civic location. In the current system, there is no >validation of geo. > >In the end, validation in the current system means: > Do we know where this location is; can we send someone to help > by giving him this location? > >To do that, there is presently a database, called the Master Street >Address Guide, which contains a list of all the "known" street addresses. >Validation, today, means that before a location is put into the database >that is actually used to determine address when an emergency call is made >(the "ALI" database), the location is looked up in the MSAG. If there is >a match, the update to the ALI is permitted. If there is no match, the >update is not allowed and the carrier attempting to update the ALI has to >go figure out what happened. > >The MSAG database sometimes also is aligned with the database used to >dispatch responders. A location submitted to the responder Computer Aided >Dispatch system must be "MSAG Valid". > >The emergency call system in North America is heavily dependent on >validation; many attempts at coming up with a location don't yield >something unique enough to use for locating where someone is unambiguously >so that help can be dispatched correctly to where they are when they can't >answer questions. This is a firm requirement for us, and we really, >really need to have it. > >The current MSAG would be the natural beginning source of the mapping >database envisioned by ecrit. There are a whole host of formatting and >correlation issues. > >It is essential that validation happen BEFORE an emergency call. Ideally, >it would happen when it happens now; when a location is put into the >database that stores location (the Location Server). > >Given the current design of the ecrit mechanisms, and accepted >requirements, the minimal way to do validation is to allow a mapping any >time (like when the location is put into the Location Server), and return >some kind of error when the location presented is not in the database. So >validation means "I have no mapping for that location". > >A better answer would be to have a mechanism in LoST specifically for >validation that could return more information than just "I have no >mapping". For example, it would be helpful to return possible alternative >valid mappings. A typical example is you query for "100 Main St" and the >mapping server returns "I don't have a 100 Main St, but I have a 100 N >Main St or 100 S Main St". You could also return an indication of which >elements in the input location were valid (Country, State, and City was >valid, but Street Name was not). It would also be useful to return >information not included in the original request (for example, you query >with the postal community name, but leave off county and jurisdictional >community name, if a unique mapping was found, the missing data was >supplied). > >It would also be good to have a form of validation for geo, which amounts >to "there are no URIs for the service you requested with the >location you provided". If you ask for police while you are in the middle >of the Atlantic Ocean, you might get that response. > > >Brian > > Hi all, > > > > we need to close issue#35 about location validation. The issue can be > > found at: http://www.ietf-ecrit.org:8080/ecrit-req/issue35. > > > > Note that I provide a summary at the end of my mail. > > > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-06.tx= t > > says: > > > > " > > Location validation: A caller location is considered valid if the > > civic or geographic location is recognizable within an acceptabl= e > > location reference systems (e.g., USPS, WGS-84, etc.), and can b= e > > mapped to one or more PSAPs. While it is desirable to determine > > that a location exists, validation may not ensure that such a > > location exists. Location validation ensures that a location is > > able to be referenced for mapping, but makes no assumption about > > the association between the caller and the caller's location. > > " > > > > We had a discussion about this subject during the interim meeting: > > http://www.ietf-ecrit.org/Interim2006/Jabber-Log_2006-02-01.html > > > > ---------------- > > > > [07:53:24] roger: issue 15 re validation of civic > > [07:53:39] andy: I thought the list left the issue not about > > not doing it, but how. > > [07:53:46] roger: need to know about the language in the draf= t > > [07:54:08] brian: something about a way to do it > > [07:54:24] jon: related to other req. such as querying it > > anywhere. > > [07:54:37] james p.: we are no validating > > [07:54:56] ted: text in the issue tracker is not the meaning > > of validation in NENA, etc... > > [07:55:12] ted: this is a valuable piece of protocol machiner= y. > > [07:55:39] james: that makes sense, but the text doesn't say > > that > > [07:56:03] brian: if validation is defined as succesful > > mapping to the PSAP, then that is what we want. > > [07:56:11] james: need other word than "valid" > > [07:56:28] brian: what we have can be used for NENA view of > > the world > > [07:57:01] james: anything out of this building to the proper > > PSAP, but not floor by floor > > [07:57:16] brian: the requirement is to know that you can sen= d > > a responder. > > [07:57:32] marc: not sure that is the NENA view, re ESN > > [07:58:04] brian: the location is knowing we can send a > > responder > > [07:58:09] nadine: agree > > [07:58:52] brian: definition of valdiation to be successful > > mapping to occur for the location > > [07:59:10] ted: this requirement needs the point brian is mak= ing > > [07:59:49] james: concerned with people thinking we mean > > something much more precise > > [08:00:12] hannes: the definition does not match the requirme= net > > [08:00:26] roger: let's examine the definition first > > [08:01:09] nadine & brian: this is a good defintion > > [08:01:15] james: no, that is cumbersome > > [08:03:04] henning: problem is that this is trying to define > > validation for both civic and geo. first test is syntactic validity. th= e > > description is not clear if the actual address exists. > > [08:03:49] henning: second test, is there a valid mapping, > > third, is there a street address that can be routed to. > > [08:04:14] brian: clarifying this is a good idea. > > [08:04:21] nadine: agree with 1 and 2, but not 3 > > [08:04:27] roger: we cannot achieve 3 > > [08:04:38] henning: then we need to be clear about it > > [08:05:36] roger: "but not equivicate to an address" ? > > [08:05:58] brian: add new sentence to clarify it. "while > > desirable to have the address exist, not guarnateed." > > [08:06:46] ted: wandering from the protocol requirement. an > > address could be invalid for other purposes but could get mapped to a > > PSAP. > > [08:07:46] ted: could I give you a PSAP based on the location > > given, if answer is yes then that is the one thing we care about > > [08:08:01] henning: just need a qualification of what it does > > not mean > > [08:08:42] brian: agree, see my previous wording > > [08:09:17] marc: mentions some use case in Texas. > > [08:09:25] brian: but that is not how it will work > > [08:09:40] marc: but if the address does not exist, no PSAP > > [08:09:46] brian: that is making an assumption > > [08:10:35] brian: current MSAG does address ranges, but we > > should have ability in future to work on single addresses > > [08:11:07] marc: do you believe it shouldn't return an answer= ? > > [08:11:10] brian: ? > > [08:11:41] ted: in some administrations, the answer will be > > "here is your PSAP, and btw the address you gave is foobar" > > [08:13:18] nadine: be able to distinguish if it is the "right= " > > PSAP vs "default" PSAP? > > [08:13:47] ted: for validation it would be "right". > > [08:14:33] henning: this has implication on protocol design > > choices. > > [08:15:57] henning: difference in use case in validation and > > non-validation (emergency case) and the bits on the wire in the protoco= l > > [08:16:00] If the case is that the address is 125 main > > street, and 124 and 126 exist but 125 does not, would validation > > indicate that the address is syntactically valid, the psap returned > > would be for 124 and/or 126? > > [08:17:19] are you asking a question for the room? > > [08:17:36] yes, but we've moved on abit > > [08:18:06] I was trying to clarify comments from several > > people > > [08:19:21] brian: answering randy's q: "I can map it, but it > > isn't really valid. But in an emergency, it would send you to the > > closest PSAP." > > [08:19:32] Thanks, sounds reasonable to me > > [08:19:46] marc: result should be saying there is a problem i= n > > XML > > [08:19:51] brian: yes > > [08:20:12] brian: it is desirable to say you can get a > > mapping, but there is a problem with the address. > > [08:21:20] henning: even in a real emergency query, this is > > nothing wrong with indicating that the address is foobar as long as the > > PSAP is returned > > [08:22:11] ted: in a real emergency only look at the one thin= g > > they map on. validation may be a different task. > > [08:22:47] brian: but that work for you > > [08:22:56] ted: that is why this is desirable. > > [08:23:04] nadine: ? > > [08:23:17] nadine: if you only know that it is a known range > > [08:24:34] andy: just need to make sure that implementers > > don't let the error show up in the emergency case > > [08:24:58] roger: do we agree that in addition to the URL tha= t > > it is desirable to have a result code? > > [08:25:10] henning: generally, yup/ > > [08:25:27] is the audio being recorded? > > [08:26:10] henning: it is more than a status code > > [08:26:16] roger: additional information? > > [08:27:13] hannes: Validation Resolution: it MAY be possible > > to return additional information which can be used to determine the > > preceision or resolution of the returned sip uri, for example > > > > ---------------- > > > > The meeting minutes of the interim meeting indicate: > > http://www.ietf-ecrit.org/Interim2006/MeetingMinutes.html > > > > ---------------- > > > > Issue 15 > > > > Validation of civil location has been hanging around for a while. Shoul= d > > it stay in the 02 draft? Andrew thought the issue was how we would do > > validation, not whether. Brian wants to leave the language in, but woul= d > > like to know if people think it's adequate (we're using motivations tex= t > > to describe what validation means). "A successful mapping will work". > > > > We actually do have other requirements that talk about this (doing > > queries at any time), but we don't describe it anywhere else. > > > > Are we actually validating? We don't mean NEMA validation, only asking > > whether it's enough to get back a PSAP mapping. Passing back "here's th= e > > PSAP" would be sufficient. Can we use another word? "Validation" has > > lots of baggage. Brian wants to make sure that we can get to NEMA > > validation - "a location that a responder knows how to get to". "A > > location that can be sucessfully mapped to one or more PSAPs". > > > > We're trying to encompass both civil location and geolocation in one > > sentence - this is one reason why it's cumbersome. If all of the city o= f > > Washington goes to one PSAP but the location isn't valid, we still have > > a problem. MSAG values have the same problem, because they carry street > > number ranges and a "valid" street number may not exactly exist - and > > the best MSAG validators today can't guarantee that the address exists. > > > > An address can be "valid enough" to get to the right PSAP, even if it's > > not valid to respond to. Texas has one PSAP entry - so anything would > > work as long as it's in Texas? No, the current MSAG works on address > > ranges - but the street exists. Brian would like for this to work on > > individual addresses, not ranges. > > > > Brian thinks that local PSAPs should be determining what happens for > > various values of "invalid", since calls are going to go somewhere! > > > > Ted thinks that there's a lot of variation in what administrations do > > now and will do in the future. > > > > Will the protocol allow us to tell that we got to the right PSAP, or > > just got a PSAP? > > > > Henning - just returning a SIP URI to let someone ask "where the heck > > are you?" isn't sufficient when we're actually routing an emergency cal= l. > > > > We always get a SIP URI, we're trying to figure out what getting a SIP > > URI actually means for an operational system. > > > > "I got a match on all the XML tags except this one" would be an > > acceptable response, and this would be desirable. This could happen at > > validation time or at emergency call routing time. > > > > Validation may mean "I like the only tags that I care about, and didn't > > look at the ones I don't care about". > > > > Do we agree that we need a result code, in addition to a URI? Partial > > validation may be the common case (public verifiers won't know suite > > numbers/room numbers, for example). > > > > Is this MUST/SHOULD/MAY? The protocol MUST have the mechanism (whether > > it gets used or not is up to the administration). > > > > And we need to be consistent in our RFC 2119 usage (which is always > > problematic for requirements documents anyway, since the meaning is a > > protocol-mechanism meaning, not a protocol-usage meaning). We're making > > a lot of these requirements MUSTs, and that may make the resulting > > protocols clumsy. If we use 2119, we should be using MUST, MAY and > > SHOULD, not just MUST. > > > > Tom pointed out that some mechanisms may be provided by extensions, but > > are not required in the base protocol. > > > > Henning says we're not writing a BCP, so we should consider NOT using > > 2119 language. > > > > Randy suggested that we actually spell out "must support", etc. and not > > rely on 2119. Henning - then we should have consistent terminology, > > whether it's upper case or lower case. Randy will audit the existing > > document, but needs input from others. > > > > What about returning an indicator of the resolution of the mapping that > > is returned? > > > > Brian suggested text for a mechanism to indicate that a location or par= t > > of location does not exist, even if it can be mapped. Should this point > > out the invalid pieces? Aren't these administration-specific? Tags are > > roughly self-describing, but we can't pick one hierarchy - what gets > > returned needs to be free-form. > > > > James - doesn't the text say "location should be sent even if it's > > considered unreliable?" Is this OK? > > > > We will leave L01 language as is, change "location validation" in > > terminology, and we are adding two new requirements to this section. > > > > ---------------- > > > > The discussions regarding Issue#15 caused us to change the following > > requirement into two requirements: > > http://www.ietf-ecrit.org:8080/ecrit-req/issue15 > > > > " > > > Lo1. Validation of Civic Location: It MUST be possible to > > >validate a > > > civic location prior to its use in an actual emergency call. > > > > > > Motivation: Location validation provides an opportunity to help > > > assure ahead of time, whether successful mapping to the > > > appropriate PSAP will likely occur when it is required. > > > Validation may also help to avoid delays during emergency call > > > setup due to invalid locations. > > > > " > > > > to: > > > > " > > Lo1X. Validation Resolution: The mapping protocol > > MUST support the return of additional information which can be used > > to determine the precision or resolution of the data elements used to > > determine a PSAP URI, for example. > > > > Lo1XX. Indication of non-existent location: The > > protocol MUST support a mechanism to indicate that a location or a > > part of a location is known to not exist, even if a valid location-to-P= SAP > > uri mapping can be provided. > > " > > > > The term validation appears only in the following sections. > > > > Section 1 (Introduction): > > > > " > > As used in this document, validation of location does not require t= o > > ascertain whether the location actually exists. For example, > > validation might only check that the house number in a civic addres= s > > falls within the assigned range, not whether that building exists a= t > > that spot. However, such higher precision validation is desirable. > > " > > > > Section 2 (Terminology): > > " > > Location validation: A caller location is considered valid if the > > civic or geographic location is recognizable within an acceptabl= e > > location reference systems (e.g., USPS, WGS-84, etc.), and can b= e > > mapped to one or more PSAPs. While it is desirable to determine > > that a location exists, validation may not ensure that such a > > location exists. Location validation ensures that a location is > > able to be referenced for mapping, but makes no assumption about > > the association between the caller and the caller's location. > > " > > > > Section 7 (Mapping Protocol): > > > > " > > Ma22. Validation of civic location: The mapping protocol MUST > > implement a method via a mapping request, that makes it possible > > for a mapping server to validate a civic location prior to that > > location's use in an actual emergency call. > > > > Motivation: Location validation provides an opportunity to help > > assure ahead of time, whether successful mapping to the > > appropriate PSAP will likely occur when it is required. > > Validation may also help to avoid delays during emergency call > > setup due to invalid locations. > > > > Ma23. Validation resolution: The mapping protocol MUST support > > (i.e., required to implement, but not required for use) the retu= rn > > of additional information which can be used to determine the > > precision or resolution of the data elements used to determine a > > PSAP URI. > > > > Motivation: The mapping server may not use all the data elements > > in the provided location information to determine a match, or ma= y > > be able to find a match based on all of the information except f= or > > some specific data elements. The uniqueness of this information > > set may be used to differentiate among emergency jurisdictions. > > Precision or resolution in the context of this requirement might > > mean, for example, explicit identification of the data elements > > that were used successfully in the mapping. > > > > Ma25. Limits to validation: Successful validation of a civic > > location MUST NOT be required to place an emergency call. > > > > Motivation: In some cases, a civic location may not be considere= d > > valid. This fact should not result in the call being dropped or > > rejected by any entity along the signaling path to the PSAP. > > " > > > > I think we need to differentiate civic and geospatial location > > information. > > > > Geospatial location information: > > > > * Can the request be mapped to one or more PSAPs? > > > > This is normal mapping protocol operation. Nothing special here. > > > > * Does the address exist? > > > > There is no question that this address exists > > if the coordinate reference system was understood. > > > > > > Civic location information: > > > > * Can the request be mapped to one or more PSAPs? > > > > The text from Ma23 is applicable here: > > > > Motivation: The mapping server may not use all the data elements > > in the provided location information to determine a match, or ma= y > > be able to find a match based on all of the information except f= or > > some specific data elements. The uniqueness of this information > > set may be used to differentiate among emergency jurisdictions. > > Precision or resolution in the context of this requirement might > > mean, for example, explicit identification of the data elements > > that were used successfully in the mapping. > > > > * Does the address exist? > > > > It is possible that a given civic address does not exist. > > An additional database, which contains the list of existing > > addresses, needs to be available. > > > > > > What we can do is to be more specific about the type of behavior we wan= t > > from the mapping protocol. > > Do we want the client to be able to express that the mapping server > > should check the civic address for existence? > > Do we want the mapping server to be able to indicate that the civic > > address was checked against the database? > > I don't think anything needs to be done with regard to geospatial > > location info. > > > > Do we need something else? > > > > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 19 21:21:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWNrO-0005C7-3v; Wed, 19 Apr 2006 21:21:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWNrN-0005By-DK for ecrit@ietf.org; Wed, 19 Apr 2006 21:21:29 -0400 Received: from 82.db.1243.static.theplanet.com ([67.18.219.130] helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWNrK-0004Q2-Uf for ecrit@ietf.org; Wed, 19 Apr 2006 21:21:29 -0400 Received: from s010600095b9792b5.vc.shawcable.net ([70.79.6.118] helo=[192.168.0.101]) by dns.aliantmedia.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1FWNrG-0002x3-6I; Wed, 19 Apr 2006 20:21:22 -0500 Message-ID: <4446E210.9000202@ntt-at.com> Date: Wed, 19 Apr 2006 18:21:20 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Design Team for ECRIT Architecture Document References: <44453EFA.7040309@gmx.net> In-Reply-To: <44453EFA.7040309@gmx.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Hannes; I would like to be part of it. Thanks. Shida Hannes Tschofenig wrote: > Hi all, > > a few working group members expressed interest in working on a > document that describes the big picture for ECRIT. The chairs would > like to form a design team to work on such a document. We have two > input documents that can serve as a basis for future work: > > http://www.ietf-ecrit.org/cache/draft-polk-newton-ecrit-arch-considerations-02.txt > > http://www.ietf-ecrit.org/cache/draft-schulzrinne-sipping-emergency-arch-02.txt > > > We have compiled a tentative list of design team members (based on the > interest expressed at the Interim Meeting and at the IETF#65 WG session): > - Henning Schulzrinne > - James Polk > - Brian Rosen > - Andrew Newton > - Ted Hardie > (& the chairs) > > If you are interested in participating in the design team please let > us know as soon as possible. It is expected that the working group > members provide text contributions, spend time on mailing list > discussions and, if needed, to participate in phone conference calls. > > This design team will work according to the rules outlined in RFC 2418 > and http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt > > The mailing list archive is public: > https://zeke.ecotroph.net/mailman/listinfo/ecrit-arch > Thanks to Andy for setting up the mailing list. > > Ciao > Hannes & Marc > > _______________________________________________ > 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 Apr 19 21:29:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWNzE-0007Ob-2D; Wed, 19 Apr 2006 21:29:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWNzC-0007OW-7G for ecrit@ietf.org; Wed, 19 Apr 2006 21:29:34 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWNzA-0004sn-68 for ecrit@ietf.org; Wed, 19 Apr 2006 21:29:34 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DC8585C9 for ; Thu, 20 Apr 2006 03:29:20 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 03:29:20 +0200 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 03:29:20 +0200 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Apr 2006 20:29:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Apr 2006 21:29:16 -0400 Message-ID: <67048CBE51B1644D89DDD3B7C9F2D19EE0F777@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Getting location behind NAT Thread-Index: AcZkGdXOsB35OhvdQsesaaqEg6yjLg== From: "Eric Turcotte \(QC/EMC\)" To: X-OriginalArrivalTime: 20 Apr 2006 01:29:17.0626 (UTC) FILETIME=[D754D9A0:01C66419] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Ecrit] Getting location behind NAT 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="===============0476053064==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0476053064== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66419.D6B439AD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66419.D6B439AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I was wondering how a UAC gets its location from a DHCP Server behind a NAT. Is this addressed in the current GEO RFC or CIVIC drafts? http://tools.ietf.org/html?rfc=3D&draft=3Ddraft-ietf-geopriv-dhcp-civil-0= 9&s ubmit=3DSubmit http://tools.ietf.org/html/rfc3825 Thanks, Eric. ------_=_NextPart_001_01C66419.D6B439AD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Getting location behind NAT

Hi,
I was wondering how a UAC gets its = location from a DHCP Server behind a NAT. Is this addressed in the = current GEO  RFC or CIVIC drafts?

http://tools.ietf.org/html?rfc=3D&draft=3Ddraft-ietf-g= eopriv-dhcp-civil-09&submit=3DSubmit
http://tools.ietf.org/html/rfc3825
Thanks,
Eric.

------_=_NextPart_001_01C66419.D6B439AD-- --===============0476053064== 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 --===============0476053064==-- From ecrit-bounces@ietf.org Wed Apr 19 21:29:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWNzN-0007R5-7x; Wed, 19 Apr 2006 21:29:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWNzL-0007R0-Gl for ecrit@ietf.org; Wed, 19 Apr 2006 21:29:43 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWNzK-0004ut-Cn for ecrit@ietf.org; Wed, 19 Apr 2006 21:29:43 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 19 Apr 2006 18:29:42 -0700 X-IronPort-AV: i="4.04,137,1144047600"; d="scan'208"; a="1796849563:sNHT38370028" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3K1Tfw1002978; Wed, 19 Apr 2006 18:29:41 -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, 19 Apr 2006 18:29:41 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.20.143]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Apr 2006 18:29:40 -0700 Message-Id: <4.3.2.7.2.20060419202415.0287b020@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Apr 2006 20:29:39 -0500 To: "Thomson, Martin" From: "James M. Polk" Subject: RE: [Ecrit] Issue 35: Location Validation - Geodetic In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Apr 2006 01:29:40.0587 (UTC) FILETIME=[E5046BB0:01C66419] X-Spam-Score: 0.0 (/) X-Scan-Signature: 07d4bcb4600b627a0786c2557bc62e06 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: , Errors-To: ecrit-bounces@ietf.org Well... this actually brings out the point I was trying to get to, that civic has to be to a registered or validated address, and geo can be to anywhere. Meaning the two systems aren't held to the same standard. As much as anything, I'm being mischievous today At 07:05 PM 4/19/2006 -0500, Thomson, Martin wrote: >I don't think that this is a real problem. Geodetic information would be >evaluated against a set of PSAP boundary polygons, not converted to civic, >as you seem to imply (my reading). Presumably there would be no black >spots not covered by PSAPs, except perhaps in international waters (and >I'm happy to leave that one for now). A request for a route occurs at an >instant in time, with the information that is available at that time, >irrespective of it's accuracy. > >There is no real concept of validation in Phase-II E-911. Currently, each >serving cell is mapped to a PSAP and the switch routes the call to the SR >based on the serving cell identifier. That is, routes are statically >configured. If J-STD 36-B with it's X-Y routing functionality were more >widely deployed, then a coarse estimate would be used (almost as coarse as >cell in effect) against the PSAP boundaries, which are represented as >polygonal areas. > >The point being that geodetic infomation is rarely, if ever going to >produce a no-route result. That problem is one for civic >addresses. Civic validation may also be a problem only in certain >countries; for routing, Australia would be fine with one civic field only, >which would make our validation database very easy to implement. > >Cheers, >Martin > >p.s.Note that PSAP boundaries for wireline and cellular can differ >slightly because of this. It's possible to reach different PSAPs from a >landline and mobile phone right next to each other. And yes, misrouting >is very common, X-Y is supposed to help with that...a little. > >________________________________ > >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Thu 4/20/2006 8:23 AM >To: br@brianrosen.net; Hannes Tschofenig >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] Issue 35: Location Validation > > > >I agree with almost everything Brian says (surprise!), especially about how >to work out additional info if a match isn't made. > >I'm weary about how to pull this off for geo though, due to the rigidity of >what doesn't constitute a match. Given that GPS accuracy is roughly within >15 ft after a few minutes and within a few feet after a bit longer (you get >the idea of increasing accuracry with time), with some reports where they >are might fall *just* outside of a valid location match, and return an >error. This might just occur for someone in the middle of the street, say >at a car accident or a hurt child next to their bike, and no one wants this >not getting through to a PSAP. > >Geo almost should have a match to some PSAP if the caller is within a >jurisdiction (say a country or state or province or county), and not only >when they are at a street address that's nice and neat like civic >addresses, but this is an interesting problem we haven't really gotten into >to solve for yet, have we. > >How does the Phase-II cellular world solve this validation question when >presented with GPS coordinates to a wreck down a canyon road that has no >(housing) lot addresses? > >If this isn't solved for in an agreed upon way, this almost begs for a "Geo >Considerations" ID to have a specific discussion about. > >At 05:02 PM 4/19/2006 -0500, br@brianrosen.net wrote: > >In North America, validation is a well known, and required step in > >processing a civic location. In the current system, there is no > >validation of geo. > > > >In the end, validation in the current system means: > > Do we know where this location is; can we send someone to help > > by giving him this location? > > > >To do that, there is presently a database, called the Master Street > >Address Guide, which contains a list of all the "known" street addresses. > >Validation, today, means that before a location is put into the database > >that is actually used to determine address when an emergency call is made > >(the "ALI" database), the location is looked up in the MSAG. If there is > >a match, the update to the ALI is permitted. If there is no match, the > >update is not allowed and the carrier attempting to update the ALI has to > >go figure out what happened. > > > >The MSAG database sometimes also is aligned with the database used to > >dispatch responders. A location submitted to the responder Computer Aided > >Dispatch system must be "MSAG Valid". > > > >The emergency call system in North America is heavily dependent on > >validation; many attempts at coming up with a location don't yield > >something unique enough to use for locating where someone is unambiguously > >so that help can be dispatched correctly to where they are when they can't > >answer questions. This is a firm requirement for us, and we really, > >really need to have it. > > > >The current MSAG would be the natural beginning source of the mapping > >database envisioned by ecrit. There are a whole host of formatting and > >correlation issues. > > > >It is essential that validation happen BEFORE an emergency call. Ideally, > >it would happen when it happens now; when a location is put into the > >database that stores location (the Location Server). > > > >Given the current design of the ecrit mechanisms, and accepted > >requirements, the minimal way to do validation is to allow a mapping any > >time (like when the location is put into the Location Server), and return > >some kind of error when the location presented is not in the database. So > >validation means "I have no mapping for that location". > > > >A better answer would be to have a mechanism in LoST specifically for > >validation that could return more information than just "I have no > >mapping". For example, it would be helpful to return possible alternative > >valid mappings. A typical example is you query for "100 Main St" and the > >mapping server returns "I don't have a 100 Main St, but I have a 100 N > >Main St or 100 S Main St". You could also return an indication of which > >elements in the input location were valid (Country, State, and City was > >valid, but Street Name was not). It would also be useful to return > >information not included in the original request (for example, you query > >with the postal community name, but leave off county and jurisdictional > >community name, if a unique mapping was found, the missing data was > >supplied). > > > >It would also be good to have a form of validation for geo, which amounts > >to "there are no URIs for the service you requested with the > >location you provided". If you ask for police while you are in the middle > >of the Atlantic Ocean, you might get that response. > > > > > >Brian > > > Hi all, > > > > > > we need to close issue#35 about location validation. The issue can be > > > found at: http://www.ietf-ecrit.org:8080/ecrit-req/issue35. > > > > > > Note that I provide a summary at the end of my mail. > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-06.txt > > > says: > > > > > > " > > > Location validation: A caller location is considered valid if the > > > civic or geographic location is recognizable within an acceptable > > > location reference systems (e.g., USPS, WGS-84, etc.), and can be > > > mapped to one or more PSAPs. While it is desirable to determine > > > that a location exists, validation may not ensure that such a > > > location exists. Location validation ensures that a location is > > > able to be referenced for mapping, but makes no assumption about > > > the association between the caller and the caller's location. > > > " > > > > > > We had a discussion about this subject during the interim meeting: > > > http://www.ietf-ecrit.org/Interim2006/Jabber-Log_2006-02-01.html > > > > > > ---------------- > > > > > > [07:53:24] roger: issue 15 re validation of civic > > > [07:53:39] andy: I thought the list left the issue not about > > > not doing it, but how. > > > [07:53:46] roger: need to know about the language in the draft > > > [07:54:08] brian: something about a way to do it > > > [07:54:24] jon: related to other req. such as querying it > > > anywhere. > > > [07:54:37] james p.: we are no validating > > > [07:54:56] ted: text in the issue tracker is not the meaning > > > of validation in NENA, etc... > > > [07:55:12] ted: this is a valuable piece of protocol machinery. > > > [07:55:39] james: that makes sense, but the text doesn't say > > > that > > > [07:56:03] brian: if validation is defined as succesful > > > mapping to the PSAP, then that is what we want. > > > [07:56:11] james: need other word than "valid" > > > [07:56:28] brian: what we have can be used for NENA view of > > > the world > > > [07:57:01] james: anything out of this building to the proper > > > PSAP, but not floor by floor > > > [07:57:16] brian: the requirement is to know that you can send > > > a responder. > > > [07:57:32] marc: not sure that is the NENA view, re ESN > > > [07:58:04] brian: the location is knowing we can send a > > > responder > > > [07:58:09] nadine: agree > > > [07:58:52] brian: definition of valdiation to be successful > > > mapping to occur for the location > > > [07:59:10] ted: this requirement needs the point brian is > making > > > [07:59:49] james: concerned with people thinking we mean > > > something much more precise > > > [08:00:12] hannes: the definition does not match the > requirmenet > > > [08:00:26] roger: let's examine the definition first > > > [08:01:09] nadine & brian: this is a good defintion > > > [08:01:15] james: no, that is cumbersome > > > [08:03:04] henning: problem is that this is trying to define > > > validation for both civic and geo. first test is syntactic validity. the > > > description is not clear if the actual address exists. > > > [08:03:49] henning: second test, is there a valid mapping, > > > third, is there a street address that can be routed to. > > > [08:04:14] brian: clarifying this is a good idea. > > > [08:04:21] nadine: agree with 1 and 2, but not 3 > > > [08:04:27] roger: we cannot achieve 3 > > > [08:04:38] henning: then we need to be clear about it > > > [08:05:36] roger: "but not equivicate to an address" ? > > > [08:05:58] brian: add new sentence to clarify it. "while > > > desirable to have the address exist, not guarnateed." > > > [08:06:46] ted: wandering from the protocol requirement. an > > > address could be invalid for other purposes but could get mapped to a > > > PSAP. > > > [08:07:46] ted: could I give you a PSAP based on the location > > > given, if answer is yes then that is the one thing we care about > > > [08:08:01] henning: just need a qualification of what it does > > > not mean > > > [08:08:42] brian: agree, see my previous wording > > > [08:09:17] marc: mentions some use case in Texas. > > > [08:09:25] brian: but that is not how it will work > > > [08:09:40] marc: but if the address does not exist, no PSAP > > > [08:09:46] brian: that is making an assumption > > > [08:10:35] brian: current MSAG does address ranges, but we > > > should have ability in future to work on single addresses > > > [08:11:07] marc: do you believe it shouldn't return an answer? > > > [08:11:10] brian: ? > > > [08:11:41] ted: in some administrations, the answer will be > > > "here is your PSAP, and btw the address you gave is foobar" > > > [08:13:18] nadine: be able to distinguish if it is the "right" > > > PSAP vs "default" PSAP? > > > [08:13:47] ted: for validation it would be "right". > > > [08:14:33] henning: this has implication on protocol design > > > choices. > > > [08:15:57] henning: difference in use case in validation and > > > non-validation (emergency case) and the bits on the wire in the protocol > > > [08:16:00] If the case is that the address is 125 main > > > street, and 124 and 126 exist but 125 does not, would validation > > > indicate that the address is syntactically valid, the psap returned > > > would be for 124 and/or 126? > > > [08:17:19] are you asking a question for the room? > > > [08:17:36] yes, but we've moved on abit > > > [08:18:06] I was trying to clarify comments from several > > > people > > > [08:19:21] brian: answering randy's q: "I can map it, but it > > > isn't really valid. But in an emergency, it would send you to the > > > closest PSAP." > > > [08:19:32] Thanks, sounds reasonable to me > > > [08:19:46] marc: result should be saying there is a problem in > > > XML > > > [08:19:51] brian: yes > > > [08:20:12] brian: it is desirable to say you can get a > > > mapping, but there is a problem with the address. > > > [08:21:20] henning: even in a real emergency query, this is > > > nothing wrong with indicating that the address is foobar as long as the > > > PSAP is returned > > > [08:22:11] ted: in a real emergency only look at the one thing > > > they map on. validation may be a different task. > > > [08:22:47] brian: but that work for you > > > [08:22:56] ted: that is why this is desirable. > > > [08:23:04] nadine: ? > > > [08:23:17] nadine: if you only know that it is a known range > > > [08:24:34] andy: just need to make sure that implementers > > > don't let the error show up in the emergency case > > > [08:24:58] roger: do we agree that in addition to the URL that > > > it is desirable to have a result code? > > > [08:25:10] henning: generally, yup/ > > > [08:25:27] is the audio being recorded? > > > [08:26:10] henning: it is more than a status code > > > [08:26:16] roger: additional information? > > > [08:27:13] hannes: Validation Resolution: it MAY be possible > > > to return additional information which can be used to determine the > > > preceision or resolution of the returned sip uri, for example > > > > > > ---------------- > > > > > > The meeting minutes of the interim meeting indicate: > > > http://www.ietf-ecrit.org/Interim2006/MeetingMinutes.html > > > > > > ---------------- > > > > > > Issue 15 > > > > > > Validation of civil location has been hanging around for a while. Should > > > it stay in the 02 draft? Andrew thought the issue was how we would do > > > validation, not whether. Brian wants to leave the language in, but would > > > like to know if people think it's adequate (we're using motivations text > > > to describe what validation means). "A successful mapping will work". > > > > > > We actually do have other requirements that talk about this (doing > > > queries at any time), but we don't describe it anywhere else. > > > > > > Are we actually validating? We don't mean NEMA validation, only asking > > > whether it's enough to get back a PSAP mapping. Passing back "here's the > > > PSAP" would be sufficient. Can we use another word? "Validation" has > > > lots of baggage. Brian wants to make sure that we can get to NEMA > > > validation - "a location that a responder knows how to get to". "A > > > location that can be sucessfully mapped to one or more PSAPs". > > > > > > We're trying to encompass both civil location and geolocation in one > > > sentence - this is one reason why it's cumbersome. If all of the city of > > > Washington goes to one PSAP but the location isn't valid, we still have > > > a problem. MSAG values have the same problem, because they carry street > > > number ranges and a "valid" street number may not exactly exist - and > > > the best MSAG validators today can't guarantee that the address exists. > > > > > > An address can be "valid enough" to get to the right PSAP, even if it's > > > not valid to respond to. Texas has one PSAP entry - so anything would > > > work as long as it's in Texas? No, the current MSAG works on address > > > ranges - but the street exists. Brian would like for this to work on > > > individual addresses, not ranges. > > > > > > Brian thinks that local PSAPs should be determining what happens for > > > various values of "invalid", since calls are going to go somewhere! > > > > > > Ted thinks that there's a lot of variation in what administrations do > > > now and will do in the future. > > > > > > Will the protocol allow us to tell that we got to the right PSAP, or > > > just got a PSAP? > > > > > > Henning - just returning a SIP URI to let someone ask "where the heck > > > are you?" isn't sufficient when we're actually routing an emergency call. > > > > > > We always get a SIP URI, we're trying to figure out what getting a SIP > > > URI actually means for an operational system. > > > > > > "I got a match on all the XML tags except this one" would be an > > > acceptable response, and this would be desirable. This could happen at > > > validation time or at emergency call routing time. > > > > > > Validation may mean "I like the only tags that I care about, and didn't > > > look at the ones I don't care about". > > > > > > Do we agree that we need a result code, in addition to a URI? Partial > > > validation may be the common case (public verifiers won't know suite > > > numbers/room numbers, for example). > > > > > > Is this MUST/SHOULD/MAY? The protocol MUST have the mechanism (whether > > > it gets used or not is up to the administration). > > > > > > And we need to be consistent in our RFC 2119 usage (which is always > > > problematic for requirements documents anyway, since the meaning is a > > > protocol-mechanism meaning, not a protocol-usage meaning). We're making > > > a lot of these requirements MUSTs, and that may make the resulting > > > protocols clumsy. If we use 2119, we should be using MUST, MAY and > > > SHOULD, not just MUST. > > > > > > Tom pointed out that some mechanisms may be provided by extensions, but > > > are not required in the base protocol. > > > > > > Henning says we're not writing a BCP, so we should consider NOT using > > > 2119 language. > > > > > > Randy suggested that we actually spell out "must support", etc. and not > > > rely on 2119. Henning - then we should have consistent terminology, > > > whether it's upper case or lower case. Randy will audit the existing > > > document, but needs input from others. > > > > > > What about returning an indicator of the resolution of the mapping that > > > is returned? > > > > > > Brian suggested text for a mechanism to indicate that a location or part > > > of location does not exist, even if it can be mapped. Should this point > > > out the invalid pieces? Aren't these administration-specific? Tags are > > > roughly self-describing, but we can't pick one hierarchy - what gets > > > returned needs to be free-form. > > > > > > James - doesn't the text say "location should be sent even if it's > > > considered unreliable?" Is this OK? > > > > > > We will leave L01 language as is, change "location validation" in > > > terminology, and we are adding two new requirements to this section. > > > > > > ---------------- > > > > > > The discussions regarding Issue#15 caused us to change the following > > > requirement into two requirements: > > > http://www.ietf-ecrit.org:8080/ecrit-req/issue15 > > > > > > " > > > > Lo1. Validation of Civic Location: It MUST be possible to > > > >validate a > > > > civic location prior to its use in an actual emergency call. > > > > > > > > Motivation: Location validation provides an opportunity to help > > > > assure ahead of time, whether successful mapping to the > > > > appropriate PSAP will likely occur when it is required. > > > > Validation may also help to avoid delays during emergency call > > > > setup due to invalid locations. > > > > > > " > > > > > > to: > > > > > > " > > > Lo1X. Validation Resolution: The mapping protocol > > > MUST support the return of additional information which can be used > > > to determine the precision or resolution of the data elements used to > > > determine a PSAP URI, for example. > > > > > > Lo1XX. Indication of non-existent location: The > > > protocol MUST support a mechanism to indicate that a location or a > > > part of a location is known to not exist, even if a valid > location-to-PSAP > > > uri mapping can be provided. > > > " > > > > > > The term validation appears only in the following sections. > > > > > > Section 1 (Introduction): > > > > > > " > > > As used in this document, validation of location does not require to > > > ascertain whether the location actually exists. For example, > > > validation might only check that the house number in a civic address > > > falls within the assigned range, not whether that building exists at > > > that spot. However, such higher precision validation is desirable. > > > " > > > > > > Section 2 (Terminology): > > > " > > > Location validation: A caller location is considered valid if the > > > civic or geographic location is recognizable within an acceptable > > > location reference systems (e.g., USPS, WGS-84, etc.), and can be > > > mapped to one or more PSAPs. While it is desirable to determine > > > that a location exists, validation may not ensure that such a > > > location exists. Location validation ensures that a location is > > > able to be referenced for mapping, but makes no assumption about > > > the association between the caller and the caller's location. > > > " > > > > > > Section 7 (Mapping Protocol): > > > > > > " > > > Ma22. Validation of civic location: The mapping protocol MUST > > > implement a method via a mapping request, that makes it possible > > > for a mapping server to validate a civic location prior to that > > > location's use in an actual emergency call. > > > > > > Motivation: Location validation provides an opportunity to help > > > assure ahead of time, whether successful mapping to the > > > appropriate PSAP will likely occur when it is required. > > > Validation may also help to avoid delays during emergency call > > > setup due to invalid locations. > > > > > > Ma23. Validation resolution: The mapping protocol MUST support > > > (i.e., required to implement, but not required for use) the return > > > of additional information which can be used to determine the > > > precision or resolution of the data elements used to determine a > > > PSAP URI. > > > > > > Motivation: The mapping server may not use all the data elements > > > in the provided location information to determine a match, or may > > > be able to find a match based on all of the information except for > > > some specific data elements. The uniqueness of this information > > > set may be used to differentiate among emergency jurisdictions. > > > Precision or resolution in the context of this requirement might > > > mean, for example, explicit identification of the data elements > > > that were used successfully in the mapping. > > > > > > Ma25. Limits to validation: Successful validation of a civic > > > location MUST NOT be required to place an emergency call. > > > > > > Motivation: In some cases, a civic location may not be considered > > > valid. This fact should not result in the call being dropped or > > > rejected by any entity along the signaling path to the PSAP. > > > " > > > > > > I think we need to differentiate civic and geospatial location > > > information. > > > > > > Geospatial location information: > > > > > > * Can the request be mapped to one or more PSAPs? > > > > > > This is normal mapping protocol operation. Nothing special here. > > > > > > * Does the address exist? > > > > > > There is no question that this address exists > > > if the coordinate reference system was understood. > > > > > > > > > Civic location information: > > > > > > * Can the request be mapped to one or more PSAPs? > > > > > > The text from Ma23 is applicable here: > > > > > > Motivation: The mapping server may not use all the data elements > > > in the provided location information to determine a match, or may > > > be able to find a match based on all of the information except for > > > some specific data elements. The uniqueness of this information > > > set may be used to differentiate among emergency jurisdictions. > > > Precision or resolution in the context of this requirement might > > > mean, for example, explicit identification of the data elements > > > that were used successfully in the mapping. > > > > > > * Does the address exist? > > > > > > It is possible that a given civic address does not exist. > > > An additional database, which contains the list of existing > > > addresses, needs to be available. > > > > > > > > > What we can do is to be more specific about the type of behavior we want > > > from the mapping protocol. > > > Do we want the client to be able to express that the mapping server > > > should check the civic address for existence? > > > Do we want the mapping server to be able to indicate that the civic > > > address was checked against the database? > > > I don't think anything needs to be done with regard to geospatial > > > location info. > > > > > > Do we need something else? > > > > > > 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 > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > > > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 19 23:08:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWPWQ-0000Ad-8F; Wed, 19 Apr 2006 23:07:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWPWO-0000AA-Gr for ecrit@ietf.org; Wed, 19 Apr 2006 23:07:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWOhw-000746-Dd for ecrit@ietf.org; Wed, 19 Apr 2006 22:15:48 -0400 Received: from 82.db.1243.static.theplanet.com ([67.18.219.130] helo=dns.aliantmedia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FWOLT-0003T2-T9 for ecrit@ietf.org; Wed, 19 Apr 2006 21:52:37 -0400 Received: from s010600095b9792b5.vc.shawcable.net ([70.79.6.118] helo=[192.168.0.101]) by dns.aliantmedia.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1FWOLL-0004HF-Eg; Wed, 19 Apr 2006 20:52:27 -0500 Message-ID: <4446E956.9090206@ntt-at.com> Date: Wed, 19 Apr 2006 18:52:22 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] Requirements Issue 38 - MA5 References: <003101c66317$f5c67720$1f0d0d0a@amer.cisco.com> In-Reply-To: <003101c66317$f5c67720$1f0d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.6 (--) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Marc; I am probably just ignorant but which URI alternate contact is being talked about here? Is this URI for more appropriate LOST server for the location in request or is it PSAP's URI? If it's PSAP isn't this already covered with Ma16? Is there anyway to indicate the protocol in use? If I am using XMPP but the LOST server only returns URI for SIP I will have no way to contact PSAP. This might be out of scope, but if ECRIT is to be used by protocols other than SIP, it seems necessary to have this capability. This is probably been discussed in the past, and I apologize if I am digging the same thing once again. Thanks & Regards Shida Marc Linsner wrote: > In an attempt to clear up the complaint that this req. doesn't contain > enough information. > > Current: > > Ma5. URI alternate contact: The mapping protocol MUST support the return of > a URI or contact method explicitly marked as an alternate contact. > > Motivation: In response to a mapping request, the mapping server may return > an alternate URI. Implementation details to be described within an > operational document. > > Proposed: > > Ma5. URI alternate contact: In addition to returning a primary contact, the > mapping protocol MUST support the return of a URI or contact method > explicitly marked as an alternate contact. > > Motivation: In response to a mapping request, the mapping server may return > an alternate URI. Implementation details to be described within an > operational document. > > > > Comments? > > -Marc- > > _______________________________________________ > 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 Thu Apr 20 03:28:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWTa7-0000OM-Pu; Thu, 20 Apr 2006 03:28:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWTZU-0008K4-8K for ecrit@ietf.org; Thu, 20 Apr 2006 03:27:24 -0400 Received: from 82.db.1243.static.theplanet.com ([67.18.219.130] helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWTUd-0005Td-9Q for ecrit@ietf.org; Thu, 20 Apr 2006 03:22:25 -0400 Received: from s010600095b9792b5.vc.shawcable.net ([70.79.6.118] helo=[192.168.0.101]) by dns.aliantmedia.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1FWTUb-00036j-N5; Thu, 20 Apr 2006 02:22:22 -0500 Message-ID: <444736A6.4030500@ntt-at.com> Date: Thu, 20 Apr 2006 00:22:14 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 Subject: Re: [Ecrit] Requirements Issue 38 - MA5 References: <003101c66317$f5c67720$1f0d0d0a@amer.cisco.com> <4446E956.9090206@ntt-at.com> In-Reply-To: <4446E956.9090206@ntt-at.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Sorry I re-read the introduction and realized that the current spec is heavily dependent on SIP, so please forget my second comment. Regards Shida Shida Schubert wrote: > Hi Marc; > > I am probably just ignorant but which URI alternate contact is being > talked about here? Is this URI for more appropriate LOST server for > the location in request or is it PSAP's URI? If it's PSAP isn't this > already > covered with Ma16? > > Is there anyway to indicate the protocol in use? If I am using XMPP but > the LOST server only returns URI for SIP I will have no way to contact > PSAP. This might be out of scope, but if ECRIT is to be used by protocols > other than SIP, it seems necessary to have this capability. This is > probably > been discussed in the past, and I apologize if I am digging the same thing > once again. > > Thanks & Regards > Shida > > Marc Linsner wrote: > >> In an attempt to clear up the complaint that this req. doesn't contain >> enough information. >> >> Current: >> >> Ma5. URI alternate contact: The mapping protocol MUST support the return of >> a URI or contact method explicitly marked as an alternate contact. >> >> Motivation: In response to a mapping request, the mapping server may return >> an alternate URI. Implementation details to be described within an >> operational document. >> >> Proposed: >> >> Ma5. URI alternate contact: In addition to returning a primary contact, the >> mapping protocol MUST support the return of a URI or contact method >> explicitly marked as an alternate contact. >> >> Motivation: In response to a mapping request, the mapping server may return >> an alternate URI. Implementation details to be described within an >> operational document. >> >> >> >> Comments? >> >> -Marc- >> >> _______________________________________________ >> 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 Thu Apr 20 04:03:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWU8O-0002Xh-RM; Thu, 20 Apr 2006 04:03:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWU67-0001bg-5Q for ecrit@ietf.org; Thu, 20 Apr 2006 04:01:07 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWU0L-0006wD-R1 for ecrit@ietf.org; Thu, 20 Apr 2006 03:55:13 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k3K7t73N005240; Thu, 20 Apr 2006 09:55:07 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k3K7t3Sn030429; Thu, 20 Apr 2006 09:55:06 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 09:55:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Rechartering Discussion Date: Thu, 20 Apr 2006 09:54:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Rechartering Discussion Thread-Index: AcZjHoDHs0ywPyz2ToyZkOt5wehbuwAmhpYQAAImwPA= From: "Tschofenig, Hannes" To: "McCalmont, Patti" , "Hannes Tschofenig" , X-OriginalArrivalTime: 20 Apr 2006 07:55:05.0077 (UTC) FILETIME=[BC499250:01C6644F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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: , Errors-To: ecrit-bounces@ietf.org Hi Patti, the document that is going to be produced by the design team should provide information about the interation between the different protocols/extensions we are developing and reusing (e.g., Geopriv and SIP stuff). =20 For example, draft-polk-newton-ecrit-arch-considerations-02.txt already describes the different steps that might need to be executed. We essentially describe these steps in more detail. Another example can be found in the protocol interactions we discussed at the ECRIT session at IETF#65 as part of Henning's presentation: (slide 3 - slide 5) http://www3.ietf.org/proceedings/06mar/slides/ecrit-3/sld1.htm A document with such a content is, in my view, an 'architecture' document. We could also call it 'framework' if this is a less overloaded term.=20 Although the details of the document are for further study we are basically going to capture what we discussed during the last year (plus a number of new things that will come up with the ongoing work). There is currently no document that describes the big picture. Several working group members repeately asked for such a document and hence we are going to work on it. I think it is a very reasonable to capture these discussions and we have support from our AD todo it.=20 Ciao Hannes PS: The design team might also want to take a look at the work done by the 3GPP and other organizations, for example.=20 > Hi Hannes, >=20 > On the item listed below, how do you think this will relate to work > going in other organizations such as 3GPP(already have a=20 > draft started), > ESIF, PTSC and others? Is it really an architecture document since > IETF's focus is on defining protocols? Should this really be an item > addressed here? The other SDOs are looking at using protocols defined > within ECRIT but working out the architectures of how they fit into > their own networks. >=20 > Guess I'm wondering if this item should really be part of=20 > this charter. >=20 > Patti >=20 >=20 > >TBD TBD An Informational document describing the ECRIT=20 > >Architecture >=20 > >(Example documents are=20 > draft-schulzrinne-sipping-emergency-arch-02.txt=20 > >and draft-polk-newton-ecrit-arch-considerations-02.txt) >=20 >=20 >=20 > Please note that the milestone date is missing for the last 3=20 > items. I=20 > would like to solicit input from the group: When can we finish these=20 > documents? >=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 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 20 04:16:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWUKk-0005dY-2l; Thu, 20 Apr 2006 04:16:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWUKi-0005dO-79 for ecrit@ietf.org; Thu, 20 Apr 2006 04:16:12 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWUKg-0008M1-Pg for ecrit@ietf.org; Thu, 20 Apr 2006 04:16:12 -0400 Received: (qmail invoked by alias); 20 Apr 2006 08:16:09 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp020) with SMTP; 20 Apr 2006 10:16:09 +0200 X-Authenticated: #29516787 Message-ID: <4447434A.1030405@gmx.net> Date: Thu, 20 Apr 2006 10:16:10 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Eric Turcotte (QC/EMC)" Subject: Re: [Ecrit] Getting location behind NAT References: <67048CBE51B1644D89DDD3B7C9F2D19EE0F777@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <67048CBE51B1644D89DDD3B7C9F2D19EE0F777@ecamlmw720.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) 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: , Errors-To: ecrit-bounces@ietf.org Hi Eric, you raise an interesting question. Could you describe your deployment environment a little bit more. For example, are you talking about a DSL environment? Ciao Hannes Eric Turcotte (QC/EMC) wrote: > Hi, > I was wondering how a UAC gets its location from a DHCP Server behind a > NAT. Is this addressed in the current GEO RFC or CIVIC drafts? > > _http://tools.ietf.org/html?rfc=&draft=draft-ietf-geopriv-dhcp-civil-09&submit=Submit_ > > > _http://tools.ietf.org/html/rfc3825_ > Thanks, > Eric. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Thu Apr 20 07:40:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWXWO-0006Ht-0q; Thu, 20 Apr 2006 07:40:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWXWN-0006Ho-JV for ecrit@ietf.org; Thu, 20 Apr 2006 07:40:27 -0400 Received: from [205.151.208.34] (helo=fw.tr.xittelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWXWL-0001o1-Ag for ecrit@ietf.org; Thu, 20 Apr 2006 07:40:27 -0400 Received: from [192.168.2.139] (helo=gestionfm) by fw.tr.xittelecom.com with esmtp (Exim 3.36 #1 (Debian)) id 1Fhml4-0004Ws-00; Sun, 21 May 2006 08:10:06 -0400 From: "Francois D. Menard" To: "'Hannes Tschofenig'" , "'Eric Turcotte \(QC/EMC\)'" Subject: RE: [Ecrit] Getting location behind NAT Date: Thu, 20 Apr 2006 07:40:22 -0400 Message-ID: <002d01c6646f$3b532510$8b02a8c0@gestionfm> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4447434A.1030405@gmx.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-index: AcZkUsV8yVd3yQGBTHGsU5Hbc5VXPAAHEEUA X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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: , Errors-To: ecrit-bounces@ietf.org Has anybody standardized the process of grabbing location from the = outside nat interface to regurgitate on the inside? If the outside is PPPoE = like on DSL networks? F.=20 -- Fran=E7ois D. M=E9nard Charg=E9 de projet Xit t=E9l=E9com inc. 1350 rue Royale #800 Trois-Rivi=E8res, QC, G9A 4J4 Canada fmenard@xittelecom.com Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 =20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: 20 avril 2006 04:16 To: Eric Turcotte (QC/EMC) Cc: ecrit@ietf.org Subject: Re: [Ecrit] Getting location behind NAT Hi Eric, you raise an interesting question. Could you describe your deployment environment a little bit more. For example, are you talking about a DSL environment? Ciao Hannes Eric Turcotte (QC/EMC) wrote: > Hi, > I was wondering how a UAC gets its location from a DHCP Server behind=20 > a NAT. Is this addressed in the current GEO RFC or CIVIC drafts? >=20 > = _http://tools.ietf.org/html?rfc=3D&draft=3Ddraft-ietf-geopriv-dhcp-civil-= 0 > 9&submit=3DSubmit_=20 > = 9&submit=3DSubmit> >=20 > _http://tools.ietf.org/html/rfc3825_ > Thanks, > Eric. >=20 >=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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 20 08:00:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWXp9-0003CZ-FQ; Thu, 20 Apr 2006 07:59:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWXp7-0003CU-Jp for ecrit@ietf.org; Thu, 20 Apr 2006 07:59:49 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWXp7-0002lE-1M for ecrit@ietf.org; Thu, 20 Apr 2006 07:59:49 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k3KBxjA7016718; Thu, 20 Apr 2006 13:59:45 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k3KBxi18024174; Thu, 20 Apr 2006 13:59:44 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 13:59:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Getting location behind NAT Date: Thu, 20 Apr 2006 13:59:18 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Getting location behind NAT Thread-Index: AcZkUsV8yVd3yQGBTHGsU5Hbc5VXPAAHEEUAAACK7MA= From: "Tschofenig, Hannes" To: "Francois D. Menard" , "Hannes Tschofenig" , "Eric Turcotte \(QC/EMC\)" X-OriginalArrivalTime: 20 Apr 2006 11:59:43.0345 (UTC) FILETIME=[E9378610:01C66471] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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: , Errors-To: ecrit-bounces@ietf.org Hi Francois, we are currently discussing this aspect in the Geopriv working group.=20 A design team was created to look at this aspect. The Geopriv is the = right place to discuss this topic.=20 =20 You might want to take a look at = http://zeke.ecotroph.net/pipermail/geopriv-l7/ to see whether the = scenario you have in mind is actually the same as the one we are = currently investigating.=20 Ciao Hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: Francois D. Menard [mailto:fmenard@xittelecom.com]=20 > Gesendet: Donnerstag, 20. April 2006 13:40 > An: 'Hannes Tschofenig'; 'Eric Turcotte (QC/EMC)' > Cc: ecrit@ietf.org > Betreff: RE: [Ecrit] Getting location behind NAT >=20 > Has anybody standardized the process of grabbing location=20 > from the outside > nat interface to regurgitate on the inside? If the outside=20 > is PPPoE like on > DSL networks? >=20 >=20 > F.=20 >=20 >=20 > -- > Fran=E7ois D. M=E9nard > Charg=E9 de projet > Xit t=E9l=E9com inc. > 1350 rue Royale #800 > Trois-Rivi=E8res, QC, G9A 4J4 > Canada > fmenard@xittelecom.com > Tel: (819) 374-2556 ext. 268 > Fax: (819) 374-0395 > Cell: (819) 692-1383 > =20 >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: 20 avril 2006 04:16 > To: Eric Turcotte (QC/EMC) > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Getting location behind NAT >=20 > Hi Eric, >=20 > you raise an interesting question. Could you describe your deployment > environment a little bit more. For example, are you talking=20 > about a DSL > environment? >=20 > Ciao > Hannes >=20 > Eric Turcotte (QC/EMC) wrote: > > Hi, > > I was wondering how a UAC gets its location from a DHCP=20 > Server behind=20 > > a NAT. Is this addressed in the current GEO RFC or CIVIC drafts? > >=20 > >=20 > = _http://tools.ietf.org/html?rfc=3D&draft=3Ddraft-ietf-geopriv-dhcp-civil-= 0 > > 9&submit=3DSubmit_=20 > >=20 > = > 9&submit=3DSubmit> > >=20 > > _http://tools.ietf.org/html/rfc3825_ > > Thanks, > > Eric. > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=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 Thu Apr 20 09:08:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWYu2-0000ZA-GI; Thu, 20 Apr 2006 09:08:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWYu1-0000Z4-CZ for ecrit@ietf.org; Thu, 20 Apr 2006 09:08:57 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWYu1-0006a8-44 for ecrit@ietf.org; Thu, 20 Apr 2006 09:08:57 -0400 Received: from brtech by cdx28.winwebhosting.com with local (Exim 4.52) id 1FWYtw-0000TM-DO; Thu, 20 Apr 2006 08:08:52 -0500 Received: from 209.173.53.233 ([209.173.53.233]) (SquirrelMail authenticated user br@brianrosen.net) by www.brianrosen.net with HTTP; Thu, 20 Apr 2006 08:08:52 -0500 (CDT) Message-ID: <44627.209.173.53.233.1145538532.squirrel@www.brianrosen.net> In-Reply-To: <67048CBE51B1644D89DDD3B7C9F2D19EE0F777@ecamlmw720.eamcs.ericsson.se> References: <67048CBE51B1644D89DDD3B7C9F2D19EE0F777@ecamlmw720.eamcs.ericsson.se> Date: Thu, 20 Apr 2006 08:08:52 -0500 (CDT) Subject: Re: [Ecrit] Getting location behind NAT From: br@brianrosen.net To: "Eric Turcotte \(QC/EMC\)" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32037 500] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/3rdparty/squirrelmail/src/compose.php X-Source-Dir: :/base/3rdparty/squirrelmail/src X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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: , Errors-To: ecrit-bounces@ietf.org Lets walk through this, because I think you will find it works pretty well with one exception: A device, say a hard SIP Phone sits behind a NAT. It has an internal address. The device makes a DHCP query to a DHCP server that sits beyond the NAT. The DHCP request is relayed by the NAT. It changes the from IP address to its external address. The DHCP server gets the request, and processes it. It returns the location associated with the subscriber/user, whether it uses the MAC address, the IP address, or a DHCP relay circuit ID to the external address (which is the NAT). The NAT gets the DHCP reply, changes the To address and relays the response to the SIP Phone. So, as long as its correct that all devices behind the NAT are at the same location, it works. The thing that doesn't work is if the NAT is not just a NAT, but a router, which supplies DHCP service for all the clients behind the NAT. Then, the DHCP server that the phone is querying is not the extenal DHCP server, its the one in the router. It would have to know to ask for location from its DHCP server (the external one) and relay that option to its internal clients. Brian > Hi, > I was wondering how a UAC gets its location from a DHCP Server behind a > NAT. Is this addressed in the current GEO RFC or CIVIC drafts? > http://tools.ietf.org/html?rfc=&draft=draft-ietf-geopriv-dhcp-civil-09&s > ubmit=Submit > http://tools.ietf.org/html/rfc3825 > Thanks, > Eric. > _______________________________________________ > 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 Thu Apr 20 09:34:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWZIx-0002SZ-3o; Thu, 20 Apr 2006 09:34:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWZIw-0002SU-5i for ecrit@ietf.org; Thu, 20 Apr 2006 09:34:42 -0400 Received: from [209.108.197.38] (helo=fwc-3a.sccx.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWZIv-0008Mj-QL for ecrit@ietf.org; Thu, 20 Apr 2006 09:34: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] Rechartering Discussion Date: Thu, 20 Apr 2006 08:34:38 -0500 Message-ID: <422D410BD61FC04185076AD99AA7207A0183A36B@inilmx01.lgmt.trdo> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Rechartering Discussion Thread-Index: AcZjHoDHs0ywPyz2ToyZkOt5wehbuwAmhpYQAAImwPAAL1+Y4A== From: "McCalmont, Patti" To: "Tschofenig, Hannes" , X-OriginalArrivalTime: 20 Apr 2006 13:34:39.0892 (UTC) FILETIME=[2C9F9D40:01C6647F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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: , Errors-To: ecrit-bounces@ietf.org Then perhaps the charter task should be - ECRIT protocol Interaction and Consideration document. IMO, architecture means a lot more. Patti -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: Thursday, April 20, 2006 2:54 AM To: McCalmont, Patti; Hannes Tschofenig; ecrit@ietf.org Subject: AW: [Ecrit] Rechartering Discussion Hi Patti, the document that is going to be produced by the design team should provide information about the interation between the different protocols/extensions we are developing and reusing (e.g., Geopriv and SIP stuff). =20 For example, draft-polk-newton-ecrit-arch-considerations-02.txt already describes the different steps that might need to be executed. We essentially describe these steps in more detail. Another example can be found in the protocol interactions we discussed at the ECRIT session at IETF#65 as part of Henning's presentation: (slide 3 - slide 5) http://www3.ietf.org/proceedings/06mar/slides/ecrit-3/sld1.htm A document with such a content is, in my view, an 'architecture' document. We could also call it 'framework' if this is a less overloaded term.=20 Although the details of the document are for further study we are basically going to capture what we discussed during the last year (plus a number of new things that will come up with the ongoing work). There is currently no document that describes the big picture. Several working group members repeately asked for such a document and hence we are going to work on it. I think it is a very reasonable to capture these discussions and we have support from our AD todo it.=20 Ciao Hannes PS: The design team might also want to take a look at the work done by the 3GPP and other organizations, for example.=20 > Hi Hannes, >=20 > On the item listed below, how do you think this will relate to work > going in other organizations such as 3GPP(already have a=20 > draft started), > ESIF, PTSC and others? Is it really an architecture document since > IETF's focus is on defining protocols? Should this really be an item > addressed here? The other SDOs are looking at using protocols defined > within ECRIT but working out the architectures of how they fit into > their own networks. >=20 > Guess I'm wondering if this item should really be part of=20 > this charter. >=20 > Patti >=20 >=20 > >TBD TBD An Informational document describing the ECRIT=20 > >Architecture >=20 > >(Example documents are=20 > draft-schulzrinne-sipping-emergency-arch-02.txt=20 > >and draft-polk-newton-ecrit-arch-considerations-02.txt) >=20 >=20 >=20 > Please note that the milestone date is missing for the last 3=20 > items. I=20 > would like to solicit input from the group: When can we finish these=20 > documents? >=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 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 20 10:09:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWZqz-00059W-9I; Thu, 20 Apr 2006 10:09:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWZqy-00059R-2e for ecrit@ietf.org; Thu, 20 Apr 2006 10:09:52 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWZqx-0001Rf-Bh for ecrit@ietf.org; Thu, 20 Apr 2006 10:09:52 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5015C4F0002; Thu, 20 Apr 2006 16:09:47 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 16:09:47 +0200 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 16:09:46 +0200 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 09:09:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Getting location behind NAT Date: Thu, 20 Apr 2006 10:09:42 -0400 Message-ID: <67048CBE51B1644D89DDD3B7C9F2D19EE0F77A@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Getting location behind NAT Thread-Index: AcZkUsxPBiGLCjs4QUSQVQt3erJodgAMNqaw From: "Eric Turcotte \(QC/EMC\)" To: "Hannes Tschofenig" X-OriginalArrivalTime: 20 Apr 2006 14:09:42.0991 (UTC) FILETIME=[122B0DF0:01C66484] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: , Errors-To: ecrit-bounces@ietf.org Hi Hannes, Yes, it is for fixed access. I think the issue is similar, whether it is DSL or cable access. Regards, Eric. > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Thursday, April 20, 2006 4:16 AM > To: Eric Turcotte (QC/EMC) > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Getting location behind NAT >=20 > Hi Eric, >=20 > you raise an interesting question. Could you describe your=20 > deployment environment a little bit more. For example, are=20 > you talking about a DSL environment? >=20 > Ciao > Hannes >=20 > Eric Turcotte (QC/EMC) wrote: > > Hi, > > I was wondering how a UAC gets its location from a DHCP=20 > Server behind=20 > > a NAT. Is this addressed in the current GEO RFC or CIVIC drafts? > >=20 > >=20 > = _http://tools.ietf.org/html?rfc=3D&draft=3Ddraft-ietf-geopriv-dhcp-civil-= 0 > > 9&submit=3DSubmit_=20 > >=20 > = > 9&submit=3DSubmit> > >=20 > > _http://tools.ietf.org/html/rfc3825_ > > Thanks, > > Eric. > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 20 10:31:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWaCD-0001gz-07; Thu, 20 Apr 2006 10:31:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWaCC-0001gu-7s for ecrit@ietf.org; Thu, 20 Apr 2006 10:31:48 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWaCB-0002lK-Ol for ecrit@ietf.org; Thu, 20 Apr 2006 10:31:48 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k3KEVk7b025942; Thu, 20 Apr 2006 16:31:46 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k3KEVjdJ010038; Thu, 20 Apr 2006 16:31:45 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 16:31:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Rechartering Discussion Date: Thu, 20 Apr 2006 16:30:54 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Rechartering Discussion Thread-Index: AcZjHoDHs0ywPyz2ToyZkOt5wehbuwAmhpYQAAImwPAAL1+Y4AABsm3A From: "Tschofenig, Hannes" To: "McCalmont, Patti" , X-OriginalArrivalTime: 20 Apr 2006 14:31:45.0455 (UTC) FILETIME=[266B0BF0:01C66487] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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: , Errors-To: ecrit-bounces@ietf.org Hi Patti,=20 "ECRIT Framework" document sounds nicer than "ECRIT protocol Interaction = and Consideration" document Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: McCalmont, Patti [mailto:Patti.McCalmont@intrado.com]=20 > Gesendet: Donnerstag, 20. April 2006 15:35 > An: Tschofenig, Hannes; ecrit@ietf.org > Betreff: RE: [Ecrit] Rechartering Discussion >=20 > Then perhaps the charter task should be - ECRIT protocol=20 > Interaction and > Consideration document. IMO, architecture means a lot more. >=20 > Patti >=20 > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > Sent: Thursday, April 20, 2006 2:54 AM > To: McCalmont, Patti; Hannes Tschofenig; ecrit@ietf.org > Subject: AW: [Ecrit] Rechartering Discussion >=20 > Hi Patti, >=20 > the document that is going to be produced by the design team should > provide information about the interation between the different > protocols/extensions we are developing and reusing (e.g., Geopriv and > SIP stuff). =20 >=20 > For example,=20 > draft-polk-newton-ecrit-arch-considerations-02.txt already > describes the different steps that might need to be executed. We > essentially describe these steps in more detail. >=20 > Another example can be found in the protocol interactions we discussed > at the ECRIT session at IETF#65 as part of Henning's presentation: > (slide 3 - slide 5) > http://www3.ietf.org/proceedings/06mar/slides/ecrit-3/sld1.htm >=20 > A document with such a content is, in my view, an 'architecture' > document. We could also call it 'framework' if this is a less=20 > overloaded > term.=20 >=20 > Although the details of the document are for further study we are > basically going to capture what we discussed during the last=20 > year (plus > a number of new things that will come up with the ongoing work). There > is currently no document that describes the big picture. Several > working group members repeately asked for such a document and hence we > are going to work on it. I think it is a very reasonable to capture > these discussions and we have support from our AD todo it.=20 >=20 > Ciao > Hannes >=20 > PS: The design team might also want to take a look at the work done by > the 3GPP and other organizations, for example.=20 >=20 > > Hi Hannes, > >=20 > > On the item listed below, how do you think this will relate to work > > going in other organizations such as 3GPP(already have a=20 > > draft started), > > ESIF, PTSC and others? Is it really an architecture document since > > IETF's focus is on defining protocols? Should this really be an item > > addressed here? The other SDOs are looking at using=20 > protocols defined > > within ECRIT but working out the architectures of how they fit into > > their own networks. > >=20 > > Guess I'm wondering if this item should really be part of=20 > > this charter. > >=20 > > Patti > >=20 > >=20 > > >TBD TBD An Informational document describing the ECRIT=20 > > >Architecture > >=20 > > >(Example documents are=20 > > draft-schulzrinne-sipping-emergency-arch-02.txt=20 > > >and draft-polk-newton-ecrit-arch-considerations-02.txt) > >=20 > >=20 > >=20 > > Please note that the milestone date is missing for the last 3=20 > > items. I=20 > > would like to solicit input from the group: When can we=20 > finish these=20 > > documents? > >=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 > >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 20 10:42:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWaMg-0005tw-BD; Thu, 20 Apr 2006 10:42:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWaMe-0005to-Hz for ecrit@ietf.org; Thu, 20 Apr 2006 10:42:36 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWaMd-00038r-4x for ecrit@ietf.org; Thu, 20 Apr 2006 10:42:36 -0400 Received: (qmail invoked by alias); 20 Apr 2006 14:42:33 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp020) with SMTP; 20 Apr 2006 16:42:33 +0200 X-Authenticated: #29516787 Message-ID: <44479DD9.7010305@gmx.net> Date: Thu, 20 Apr 2006 16:42:33 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] SunRocket to support LoST/ECRIT References: <443FB9B0.4040906@sunrocket.com> In-Reply-To: <443FB9B0.4040906@sunrocket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: ecrit-bounces@ietf.org Hi Andy, thanks for this interesting information. It is always good to hear that the protocols we develop are going to be deployed. I think that this is very encouraging. Ciao Hannes Andrew Newton wrote: > All, > > This message is to inform all the people working hard within the ECRIT > working group that SunRocket, one of the fastest growing voice service > providers, recognizes the importance of the ECRIT work and the LoST > protocol. SunRocket intends to develop software, field services, and > work with the community to specify and refine LoST and other protocols > related to the vitally important field of Internet-based emergency > context resolution. > > If you have questions or comments, you may email me directly. > > -andy > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 20 11:03:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWahG-0005Tt-11; Thu, 20 Apr 2006 11:03:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWahE-0005To-OJ for ecrit@ietf.org; Thu, 20 Apr 2006 11:03:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWZxL-0001lR-Qw for ecrit@ietf.org; Thu, 20 Apr 2006 10:16:27 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FWZnF-0001iY-RQ for ecrit@ietf.org; Thu, 20 Apr 2006 10:06:04 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7019C4F0044; Thu, 20 Apr 2006 16:06:00 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 16:06:00 +0200 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 16:05:59 +0200 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 09:05:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Getting location behind NAT Date: Thu, 20 Apr 2006 10:05:39 -0400 Message-ID: <67048CBE51B1644D89DDD3B7C9F2D19EE0F779@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Getting location behind NAT Thread-Index: AcZke5wjWok7LQ5nTI+LoNtwsLw+hwABSJ2g From: "Eric Turcotte \(QC/EMC\)" To: X-OriginalArrivalTime: 20 Apr 2006 14:05:41.0056 (UTC) FILETIME=[81F6B400:01C66483] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.6 (--) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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: , Errors-To: ecrit-bounces@ietf.org Hi Brian, Some comments below. Regards, Eric.=20 > -----Original Message----- > From: br@brianrosen.net [mailto:br@brianrosen.net]=20 > Sent: Thursday, April 20, 2006 9:09 AM > To: Eric Turcotte (QC/EMC) > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Getting location behind NAT >=20 > Lets walk through this, because I think you will find it=20 > works pretty well with one exception: >=20 > A device, say a hard SIP Phone sits behind a NAT. It has an=20 > internal address. The device makes a DHCP query to a DHCP=20 > server that sits beyond the NAT. My assumption was that the SIP phone got its IP address from a "local" DHCP server, i.e. DHCP server not behind the NAT. However, we would like to get the UAC location from the DHCP server beyond the NAT. I think this bring the issue you point out below. >=20 > The DHCP request is relayed by the NAT. It changes the from=20 > IP address to its external address. >=20 > The DHCP server gets the request, and processes it. It=20 > returns the location associated with the subscriber/user,=20 > whether it uses the MAC address, the IP address, or a DHCP=20 > relay circuit ID to the external address (which is the NAT). >=20 > The NAT gets the DHCP reply, changes the To address and=20 > relays the response to the SIP Phone. >=20 > So, as long as its correct that all devices behind the NAT=20 > are at the same location, it works. I would assume this would cover the majority of cases (that the UACs are at the same location as the NAT. However, do we have cases where you may have a WLAN access and the UAC may move to different APs?=20 >=20 > The thing that doesn't work is if the NAT is not just a NAT,=20 > but a router, which supplies DHCP service for all the clients=20 > behind the NAT. Then, the DHCP server that the phone is=20 > querying is not the extenal DHCP server, its the one in the=20 > router. It would have to know to ask for location from its=20 > DHCP server (the external one) and relay that option to its=20 > internal clients. Yes, this is exacltely the issue I had. It would be nice that this would work without having the UAC to have prior knowledge of the external DHCP server.=20 >=20 > Brian >=20 > > Hi, > > I was wondering how a UAC gets its location from a DHCP=20 > Server behind=20 > > a NAT. Is this addressed in the current GEO RFC or CIVIC drafts? > >=20 > = http://tools.ietf.org/html?rfc=3D&draft=3Ddraft-ietf-geopriv-dhcp-civil-0= 9 > > &s > > ubmit=3DSubmit > > http://tools.ietf.org/html/rfc3825 > > Thanks, > > Eric. > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 20 11:15:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWasE-0001xe-Id; Thu, 20 Apr 2006 11:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWasD-0001xU-Dt for ecrit@ietf.org; Thu, 20 Apr 2006 11:15:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWaKb-00034P-Vt for ecrit@ietf.org; Thu, 20 Apr 2006 10:40:30 -0400 Received: from fwc-3a.sccx.com ([199.117.205.18]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FWaE1-0001zf-7S for ecrit@ietf.org; Thu, 20 Apr 2006 10:33:43 -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] Rechartering Discussion Date: Thu, 20 Apr 2006 09:33:35 -0500 Message-ID: <422D410BD61FC04185076AD99AA7207A0183A3A1@inilmx01.lgmt.trdo> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Rechartering Discussion Thread-Index: AcZjHoDHs0ywPyz2ToyZkOt5wehbuwAmhpYQAAImwPAAL1+Y4AABsm3AAABxqhA= From: "McCalmont, Patti" To: "Tschofenig, Hannes" , X-OriginalArrivalTime: 20 Apr 2006 14:33:36.0459 (UTC) FILETIME=[6894E9B0:01C66487] X-Spam-Score: -2.6 (--) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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: , Errors-To: ecrit-bounces@ietf.org You're right. Let's use framework. Thanks -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: Thursday, April 20, 2006 9:31 AM To: McCalmont, Patti; ecrit@ietf.org Subject: AW: [Ecrit] Rechartering Discussion Hi Patti,=20 "ECRIT Framework" document sounds nicer than "ECRIT protocol Interaction = and Consideration" document Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: McCalmont, Patti [mailto:Patti.McCalmont@intrado.com]=20 > Gesendet: Donnerstag, 20. April 2006 15:35 > An: Tschofenig, Hannes; ecrit@ietf.org > Betreff: RE: [Ecrit] Rechartering Discussion >=20 > Then perhaps the charter task should be - ECRIT protocol=20 > Interaction and > Consideration document. IMO, architecture means a lot more. >=20 > Patti >=20 > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > Sent: Thursday, April 20, 2006 2:54 AM > To: McCalmont, Patti; Hannes Tschofenig; ecrit@ietf.org > Subject: AW: [Ecrit] Rechartering Discussion >=20 > Hi Patti, >=20 > the document that is going to be produced by the design team should > provide information about the interation between the different > protocols/extensions we are developing and reusing (e.g., Geopriv and > SIP stuff). =20 >=20 > For example,=20 > draft-polk-newton-ecrit-arch-considerations-02.txt already > describes the different steps that might need to be executed. We > essentially describe these steps in more detail. >=20 > Another example can be found in the protocol interactions we discussed > at the ECRIT session at IETF#65 as part of Henning's presentation: > (slide 3 - slide 5) > http://www3.ietf.org/proceedings/06mar/slides/ecrit-3/sld1.htm >=20 > A document with such a content is, in my view, an 'architecture' > document. We could also call it 'framework' if this is a less=20 > overloaded > term.=20 >=20 > Although the details of the document are for further study we are > basically going to capture what we discussed during the last=20 > year (plus > a number of new things that will come up with the ongoing work). There > is currently no document that describes the big picture. Several > working group members repeately asked for such a document and hence we > are going to work on it. I think it is a very reasonable to capture > these discussions and we have support from our AD todo it.=20 >=20 > Ciao > Hannes >=20 > PS: The design team might also want to take a look at the work done by > the 3GPP and other organizations, for example.=20 >=20 > > Hi Hannes, > >=20 > > On the item listed below, how do you think this will relate to work > > going in other organizations such as 3GPP(already have a=20 > > draft started), > > ESIF, PTSC and others? Is it really an architecture document since > > IETF's focus is on defining protocols? Should this really be an item > > addressed here? The other SDOs are looking at using=20 > protocols defined > > within ECRIT but working out the architectures of how they fit into > > their own networks. > >=20 > > Guess I'm wondering if this item should really be part of=20 > > this charter. > >=20 > > Patti > >=20 > >=20 > > >TBD TBD An Informational document describing the ECRIT=20 > > >Architecture > >=20 > > >(Example documents are=20 > > draft-schulzrinne-sipping-emergency-arch-02.txt=20 > > >and draft-polk-newton-ecrit-arch-considerations-02.txt) > >=20 > >=20 > >=20 > > Please note that the milestone date is missing for the last 3=20 > > items. I=20 > > would like to solicit input from the group: When can we=20 > finish these=20 > > documents? > >=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 > >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 20 12:26:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbys-0002R1-1r; Thu, 20 Apr 2006 12:26:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbyq-0002Nh-Ru for ecrit@ietf.org; Thu, 20 Apr 2006 12:26:08 -0400 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWbyo-0000hp-EB for ecrit@ietf.org; Thu, 20 Apr 2006 12:26:08 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 20 Apr 2006 09:25:59 -0700 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: [Ecrit] New requirements draft available Date: Thu, 20 Apr 2006 09:25:59 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657504BBB9D3@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] New requirements draft available Thread-Index: AcZjHoDHs0ywPyz2ToyZkOt5wehbuwAmhpYQAAImwPAAL1+Y4AAESMAw From: "Roger Marshall" To: , "Tschofenig, Hannes" , "Marc Linsner" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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: , Errors-To: ecrit-bounces@ietf.org I have submitted a new edition of the ECRIT requirements draft to the I-D editor. Until it appears in the archives, you can find it at the following links: http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-07.txt http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-07.html In addition to several minor wording changes, most of the significant changes are based on either discussions at IETF65-Dallas, the ecrit mailing list, or the issues logged in the tracker (http://www.ietf-ecrit.org:8080/ecrit-req/index): A few of the open issues contain proposed text, some of which, has been included in this version of the draft. All issues will be monitored, and resolved based on discussion, (or lack thereof - if non-controversial). Generally, the changes in this draft are as follows:=20 - attempted to clean up all requirements with respect to RFC 2119 guidelines. - Id7. Reworded to point to the mapping protocol. Also, since this requirement originally focused on the end device, it has been changed to MUST, as the scope and intent has changed. This doesn't preclude the phone BCP including the original requirement. - removed the original (Id9.) requirement which stated, "Emergency identifier recognition: An=20 emergency identifier MUST be recognized by any network=20 element which supports the mapping protocol.", since it was covered by req. Id1. already. - reworded req. Ma5., "URI alternate contact", per M. Linsner's suggested text. - reworded req. Ma6., "URL properties", per M. Linsner's text. - added a new issue #53, based on what I thought was vague wording of req. titled "Split responsibility". - removed req. titled, "Ubiquitous triggering", since it seemed to be covered by separate requirements, (see) Ma11 & Ma12. - misc. reordering/renumbering. - Bob Natale caught a few more errors, some which I didn't get into this version, but will go into a subsequent version (ref. email 3/19, and thanks Bob). The questions around location validation are still being discussed on the list, and have not been altered significantly within the draft (other than consolidating into the Location section). I expect the discussion on the list will provide direction as to changes to the existing validation language or the possible addition of new requirements, etc. Comments welcomed. Roger Marshall. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 20 15:07:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWeUl-0006TT-ND; Thu, 20 Apr 2006 15:07:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWeUk-0006TO-MN for ecrit@ietf.org; Thu, 20 Apr 2006 15:07:14 -0400 Received: from test-iport-3.cisco.com ([171.71.176.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWeUi-0000Lc-AN for ecrit@ietf.org; Thu, 20 Apr 2006 15:07:14 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-3.cisco.com with ESMTP; 20 Apr 2006 12:07:11 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3KJ7Bh0019195; Thu, 20 Apr 2006 12:07:11 -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); Thu, 20 Apr 2006 12:07:08 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.16.94]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Apr 2006 12:07:07 -0700 Message-Id: <4.3.2.7.2.20060420135623.03c73b80@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Apr 2006 14:07:06 -0500 To: "McCalmont, Patti" From: "James M. Polk" Subject: RE: [Ecrit] Rechartering Discussion In-Reply-To: <422D410BD61FC04185076AD99AA7207A0183A36B@inilmx01.lgmt.trd o> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Apr 2006 19:07:07.0790 (UTC) FILETIME=[9E7F4AE0:01C664AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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: , Errors-To: ecrit-bounces@ietf.org Patti This ECRIT Architecture document is the IETF's take on how we developed the LoST protocol, Emergency Call Identification and the PhoneBCP - under what conditions, what we looked at, what we discounted and why, etc. That is not the job of NENA or ESIF or ETSI or PacketCable. Of course each of those SDOs can do their take on emergency calling too. But for anyone just looking at the IETF, to figure out what this WG was thinking, this concept needs to be captured in an overarching document. I prefer a doc title of "ECRIT Architecture" to what you have below. At 08:34 AM 4/20/2006 -0500, McCalmont, Patti wrote: >Then perhaps the charter task should be - ECRIT protocol Interaction and >Consideration document. IMO, architecture means a lot more. > >Patti > >-----Original Message----- >From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >Sent: Thursday, April 20, 2006 2:54 AM >To: McCalmont, Patti; Hannes Tschofenig; ecrit@ietf.org >Subject: AW: [Ecrit] Rechartering Discussion > >Hi Patti, > >the document that is going to be produced by the design team should >provide information about the interation between the different >protocols/extensions we are developing and reusing (e.g., Geopriv and >SIP stuff). > >For example, draft-polk-newton-ecrit-arch-considerations-02.txt already >describes the different steps that might need to be executed. We >essentially describe these steps in more detail. > >Another example can be found in the protocol interactions we discussed >at the ECRIT session at IETF#65 as part of Henning's presentation: >(slide 3 - slide 5) >http://www3.ietf.org/proceedings/06mar/slides/ecrit-3/sld1.htm > >A document with such a content is, in my view, an 'architecture' >document. We could also call it 'framework' if this is a less overloaded >term. > >Although the details of the document are for further study we are >basically going to capture what we discussed during the last year (plus >a number of new things that will come up with the ongoing work). There >is currently no document that describes the big picture. Several >working group members repeately asked for such a document and hence we >are going to work on it. I think it is a very reasonable to capture >these discussions and we have support from our AD todo it. > >Ciao >Hannes > >PS: The design team might also want to take a look at the work done by >the 3GPP and other organizations, for example. > > > Hi Hannes, > > > > On the item listed below, how do you think this will relate to work > > going in other organizations such as 3GPP(already have a > > draft started), > > ESIF, PTSC and others? Is it really an architecture document since > > IETF's focus is on defining protocols? Should this really be an item > > addressed here? The other SDOs are looking at using protocols defined > > within ECRIT but working out the architectures of how they fit into > > their own networks. > > > > Guess I'm wondering if this item should really be part of > > this charter. > > > > Patti > > > > > > >TBD TBD An Informational document describing the ECRIT > > >Architecture > > > > >(Example documents are > > draft-schulzrinne-sipping-emergency-arch-02.txt > > >and draft-polk-newton-ecrit-arch-considerations-02.txt) > > > > > > > > Please note that the milestone date is missing for the last 3 > > items. I > > would like to solicit input from the group: When can we finish these > > documents? > > > > 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 > > > >_______________________________________________ >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 Thu Apr 20 15:14:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWebv-0000Oa-1e; Thu, 20 Apr 2006 15:14:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWebt-0000OV-Fm for ecrit@ietf.org; Thu, 20 Apr 2006 15:14:37 -0400 Received: from [209.108.197.38] (helo=fwc-3a.sccx.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWebt-0000gL-1A for ecrit@ietf.org; Thu, 20 Apr 2006 15:14:37 -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] Rechartering Discussion Date: Thu, 20 Apr 2006 14:14:30 -0500 Message-ID: <422D410BD61FC04185076AD99AA7207A0183A480@inilmx01.lgmt.trdo> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Rechartering Discussion Thread-Index: AcZkrb74nkBrJenXTgKakQt3Iw+szwAAMChg From: "McCalmont, Patti" To: "James M. Polk" X-OriginalArrivalTime: 20 Apr 2006 19:14:32.0844 (UTC) FILETIME=[A7C524C0:01C664AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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: , Errors-To: ecrit-bounces@ietf.org Actually, I prefer what Hannes suggested - ECRIT Framework. Are you OK with that? Patti -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: Thursday, April 20, 2006 2:07 PM To: McCalmont, Patti Cc: Tschofenig, Hannes; ecrit@ietf.org Subject: RE: [Ecrit] Rechartering Discussion Patti This ECRIT Architecture document is the IETF's take on how we developed the=20 LoST protocol, Emergency Call Identification and the PhoneBCP - under what=20 conditions, what we looked at, what we discounted and why, etc. That is not the job of NENA or ESIF or ETSI or PacketCable. Of course each of=20 those SDOs can do their take on emergency calling too. But for anyone just=20 looking at the IETF, to figure out what this WG was thinking, this concept=20 needs to be captured in an overarching document. I prefer a doc title of "ECRIT Architecture" to what you have below. At 08:34 AM 4/20/2006 -0500, McCalmont, Patti wrote: >Then perhaps the charter task should be - ECRIT protocol Interaction and >Consideration document. IMO, architecture means a lot more. > >Patti > >-----Original Message----- >From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >Sent: Thursday, April 20, 2006 2:54 AM >To: McCalmont, Patti; Hannes Tschofenig; ecrit@ietf.org >Subject: AW: [Ecrit] Rechartering Discussion > >Hi Patti, > >the document that is going to be produced by the design team should >provide information about the interation between the different >protocols/extensions we are developing and reusing (e.g., Geopriv and >SIP stuff). > >For example, draft-polk-newton-ecrit-arch-considerations-02.txt already >describes the different steps that might need to be executed. We >essentially describe these steps in more detail. > >Another example can be found in the protocol interactions we discussed >at the ECRIT session at IETF#65 as part of Henning's presentation: >(slide 3 - slide 5) >http://www3.ietf.org/proceedings/06mar/slides/ecrit-3/sld1.htm > >A document with such a content is, in my view, an 'architecture' >document. We could also call it 'framework' if this is a less overloaded >term. > >Although the details of the document are for further study we are >basically going to capture what we discussed during the last year (plus >a number of new things that will come up with the ongoing work). There >is currently no document that describes the big picture. Several >working group members repeately asked for such a document and hence we >are going to work on it. I think it is a very reasonable to capture >these discussions and we have support from our AD todo it. > >Ciao >Hannes > >PS: The design team might also want to take a look at the work done by >the 3GPP and other organizations, for example. > > > Hi Hannes, > > > > On the item listed below, how do you think this will relate to work > > going in other organizations such as 3GPP(already have a > > draft started), > > ESIF, PTSC and others? Is it really an architecture document since > > IETF's focus is on defining protocols? Should this really be an item > > addressed here? The other SDOs are looking at using protocols defined > > within ECRIT but working out the architectures of how they fit into > > their own networks. > > > > Guess I'm wondering if this item should really be part of > > this charter. > > > > Patti > > > > > > >TBD TBD An Informational document describing the ECRIT > > >Architecture > > > > >(Example documents are > > draft-schulzrinne-sipping-emergency-arch-02.txt > > >and draft-polk-newton-ecrit-arch-considerations-02.txt) > > > > > > > > Please note that the milestone date is missing for the last 3 > > items. I > > would like to solicit input from the group: When can we finish these > > documents? > > > > 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 > > > >_______________________________________________ >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 Thu Apr 20 15:30:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWerB-0006oM-2a; Thu, 20 Apr 2006 15:30:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWerA-0006oH-8n for ecrit@ietf.org; Thu, 20 Apr 2006 15:30:24 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWer8-0001cg-TI for ecrit@ietf.org; Thu, 20 Apr 2006 15:30:24 -0400 Received: from az4315exch001u.wins.lucent.com (h130-131-166-103.lucent.com [130.131.166.103]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k3KJUH2A001744; Thu, 20 Apr 2006 14:30:17 -0500 (CDT) Received: by az4315exch001u.phx.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Apr 2006 12:30:17 -0700 Message-ID: <17D8724A2A8D9542B2B8AE546B9E5BBC065D48E9@az4315exch001u.phx.lucent.com> From: "GOLDMAN, STUART O (STUART)" To: "McCalmont, Patti" , "James M. Polk" Subject: RE: [Ecrit] Rechartering Discussion Date: Thu, 20 Apr 2006 12:30:07 -0700 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: d2b46e3b2dfbff2088e0b72a54104985 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: , Errors-To: ecrit-bounces@ietf.org Folks, Since we are tasked to develop a high level view, perhaps framework might a bit better convey that task than architecture would. Stuart Goldman Lucent Technologies sgoldman@lucent.com 602 493 8438 -----Original Message----- From: McCalmont, Patti [mailto:Patti.McCalmont@intrado.com] Sent: Thursday, April 20, 2006 12:15 PM To: James M. Polk Cc: ecrit@ietf.org Subject: RE: [Ecrit] Rechartering Discussion Actually, I prefer what Hannes suggested - ECRIT Framework. Are you OK with that? Patti -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Thursday, April 20, 2006 2:07 PM To: McCalmont, Patti Cc: Tschofenig, Hannes; ecrit@ietf.org Subject: RE: [Ecrit] Rechartering Discussion Patti This ECRIT Architecture document is the IETF's take on how we developed the LoST protocol, Emergency Call Identification and the PhoneBCP - under what conditions, what we looked at, what we discounted and why, etc. That is not the job of NENA or ESIF or ETSI or PacketCable. Of course each of those SDOs can do their take on emergency calling too. But for anyone just looking at the IETF, to figure out what this WG was thinking, this concept needs to be captured in an overarching document. I prefer a doc title of "ECRIT Architecture" to what you have below. At 08:34 AM 4/20/2006 -0500, McCalmont, Patti wrote: >Then perhaps the charter task should be - ECRIT protocol Interaction and >Consideration document. IMO, architecture means a lot more. > >Patti > >-----Original Message----- >From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >Sent: Thursday, April 20, 2006 2:54 AM >To: McCalmont, Patti; Hannes Tschofenig; ecrit@ietf.org >Subject: AW: [Ecrit] Rechartering Discussion > >Hi Patti, > >the document that is going to be produced by the design team should >provide information about the interation between the different >protocols/extensions we are developing and reusing (e.g., Geopriv and >SIP stuff). > >For example, draft-polk-newton-ecrit-arch-considerations-02.txt already >describes the different steps that might need to be executed. We >essentially describe these steps in more detail. > >Another example can be found in the protocol interactions we discussed >at the ECRIT session at IETF#65 as part of Henning's presentation: >(slide 3 - slide 5) >http://www3.ietf.org/proceedings/06mar/slides/ecrit-3/sld1.htm > >A document with such a content is, in my view, an 'architecture' >document. We could also call it 'framework' if this is a less overloaded >term. > >Although the details of the document are for further study we are >basically going to capture what we discussed during the last year (plus >a number of new things that will come up with the ongoing work). There >is currently no document that describes the big picture. Several >working group members repeately asked for such a document and hence we >are going to work on it. I think it is a very reasonable to capture >these discussions and we have support from our AD todo it. > >Ciao >Hannes > >PS: The design team might also want to take a look at the work done by >the 3GPP and other organizations, for example. > > > Hi Hannes, > > > > On the item listed below, how do you think this will relate to work > > going in other organizations such as 3GPP(already have a > > draft started), > > ESIF, PTSC and others? Is it really an architecture document since > > IETF's focus is on defining protocols? Should this really be an item > > addressed here? The other SDOs are looking at using protocols defined > > within ECRIT but working out the architectures of how they fit into > > their own networks. > > > > Guess I'm wondering if this item should really be part of > > this charter. > > > > Patti > > > > > > >TBD TBD An Informational document describing the ECRIT > > >Architecture > > > > >(Example documents are > > draft-schulzrinne-sipping-emergency-arch-02.txt > > >and draft-polk-newton-ecrit-arch-considerations-02.txt) > > > > > > > > Please note that the milestone date is missing for the last 3 > > items. I > > would like to solicit input from the group: When can we finish these > > documents? > > > > 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 > > > >_______________________________________________ >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 Thu Apr 20 16:05:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWfOq-0006j8-PP; Thu, 20 Apr 2006 16:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWfOq-0006j3-00 for ecrit@ietf.org; Thu, 20 Apr 2006 16:05:12 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWfOn-0003Dx-SV for ecrit@ietf.org; Thu, 20 Apr 2006 16:05:11 -0400 Received: (qmail invoked by alias); 20 Apr 2006 20:05:06 -0000 Received: from p5498669D.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.102.157] by mail.gmx.net (mp036) with SMTP; 20 Apr 2006 22:05:06 +0200 X-Authenticated: #29516787 Message-ID: <4447E972.6080105@gmx.net> Date: Thu, 20 Apr 2006 22:05:06 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Ecrit] Issue 35: Location Validation References: <4446A7A6.5070908@gmx.net> <59517.209.173.53.233.1145484178.squirrel@www.brianrosen.net> In-Reply-To: <59517.209.173.53.233.1145484178.squirrel@www.brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 90fbdaf3c139ce803b358d56775b59ed 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: , Errors-To: ecrit-bounces@ietf.org Hi Brian, thanks for the detailed explanation. Let me focus on requirement specific to the mapping protocol: * Allow a mapping any time No problem. * Return an error when the location presented is not in the database (i.e., when the mapping from location to the URI is "Error - I have no mapping for that location" No problem. Now, things get tricky when we want to provide some clever "debugging" mechanisms when the mapping protocol cannot provide offer a full match. It might be possible to provide some useful error responses for civic information. For geospatial information I am not sure that this is particularly useful. Since we are already working on the mapping protocol I would like to see a detailed algorithmic description of the type of error responses people have in mind. Examples do not help. Ciao Hannes PS: I would really like to avoid the term 'validation' since it is soo confusing. We can compile requirements without using the term validation at all. br@brianrosen.net wrote: > In North America, validation is a well known, and required step in > processing a civic location. In the current system, there is no > validation of geo. > > In the end, validation in the current system means: > Do we know where this location is; can we send someone to help > by giving him this location? > > To do that, there is presently a database, called the Master Street > Address Guide, which contains a list of all the "known" street addresses. > Validation, today, means that before a location is put into the database > that is actually used to determine address when an emergency call is made > (the "ALI" database), the location is looked up in the MSAG. If there is > a match, the update to the ALI is permitted. If there is no match, the > update is not allowed and the carrier attempting to update the ALI has to > go figure out what happened. > > The MSAG database sometimes also is aligned with the database used to > dispatch responders. A location submitted to the responder Computer Aided > Dispatch system must be "MSAG Valid". > > The emergency call system in North America is heavily dependent on > validation; many attempts at coming up with a location don't yield > something unique enough to use for locating where someone is unambiguously > so that help can be dispatched correctly to where they are when they can't > answer questions. This is a firm requirement for us, and we really, > really need to have it. > > The current MSAG would be the natural beginning source of the mapping > database envisioned by ecrit. There are a whole host of formatting and > correlation issues. > > It is essential that validation happen BEFORE an emergency call. Ideally, > it would happen when it happens now; when a location is put into the > database that stores location (the Location Server). > > Given the current design of the ecrit mechanisms, and accepted > requirements, the minimal way to do validation is to allow a mapping any > time (like when the location is put into the Location Server), and return > some kind of error when the location presented is not in the database. So > validation means "I have no mapping for that location". > > A better answer would be to have a mechanism in LoST specifically for > validation that could return more information than just "I have no > mapping". For example, it would be helpful to return possible alternative > valid mappings. A typical example is you query for "100 Main St" and the > mapping server returns "I don't have a 100 Main St, but I have a 100 N > Main St or 100 S Main St". You could also return an indication of which > elements in the input location were valid (Country, State, and City was > valid, but Street Name was not). It would also be useful to return > information not included in the original request (for example, you query > with the postal community name, but leave off county and jurisdictional > community name, if a unique mapping was found, the missing data was > supplied). > > It would also be good to have a form of validation for geo, which amounts > to "there are no URIs for the service you requested with the > location you provided". If you ask for police while you are in the middle > of the Atlantic Ocean, you might get that response. > > > Brian > >>Hi all, >> >>we need to close issue#35 about location validation. The issue can be >>found at: http://www.ietf-ecrit.org:8080/ecrit-req/issue35. >> >>Note that I provide a summary at the end of my mail. >> >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-06.txt >>says: >> >>" >> Location validation: A caller location is considered valid if the >> civic or geographic location is recognizable within an acceptable >> location reference systems (e.g., USPS, WGS-84, etc.), and can be >> mapped to one or more PSAPs. While it is desirable to determine >> that a location exists, validation may not ensure that such a >> location exists. Location validation ensures that a location is >> able to be referenced for mapping, but makes no assumption about >> the association between the caller and the caller's location. >>" >> >>We had a discussion about this subject during the interim meeting: >>http://www.ietf-ecrit.org/Interim2006/Jabber-Log_2006-02-01.html >> >>---------------- >> >>[07:53:24] roger: issue 15 re validation of civic >>[07:53:39] andy: I thought the list left the issue not about >>not doing it, but how. >>[07:53:46] roger: need to know about the language in the draft >>[07:54:08] brian: something about a way to do it >>[07:54:24] jon: related to other req. such as querying it >>anywhere. >>[07:54:37] james p.: we are no validating >>[07:54:56] ted: text in the issue tracker is not the meaning >>of validation in NENA, etc... >>[07:55:12] ted: this is a valuable piece of protocol machinery. >>[07:55:39] james: that makes sense, but the text doesn't say >>that >>[07:56:03] brian: if validation is defined as succesful >>mapping to the PSAP, then that is what we want. >>[07:56:11] james: need other word than "valid" >>[07:56:28] brian: what we have can be used for NENA view of >>the world >>[07:57:01] james: anything out of this building to the proper >>PSAP, but not floor by floor >>[07:57:16] brian: the requirement is to know that you can send >>a responder. >>[07:57:32] marc: not sure that is the NENA view, re ESN >>[07:58:04] brian: the location is knowing we can send a >>responder >>[07:58:09] nadine: agree >>[07:58:52] brian: definition of valdiation to be successful >>mapping to occur for the location >>[07:59:10] ted: this requirement needs the point brian is making >>[07:59:49] james: concerned with people thinking we mean >>something much more precise >>[08:00:12] hannes: the definition does not match the requirmenet >>[08:00:26] roger: let's examine the definition first >>[08:01:09] nadine & brian: this is a good defintion >>[08:01:15] james: no, that is cumbersome >>[08:03:04] henning: problem is that this is trying to define >>validation for both civic and geo. first test is syntactic validity. the >>description is not clear if the actual address exists. >>[08:03:49] henning: second test, is there a valid mapping, >>third, is there a street address that can be routed to. >>[08:04:14] brian: clarifying this is a good idea. >>[08:04:21] nadine: agree with 1 and 2, but not 3 >>[08:04:27] roger: we cannot achieve 3 >>[08:04:38] henning: then we need to be clear about it >>[08:05:36] roger: "but not equivicate to an address" ? >>[08:05:58] brian: add new sentence to clarify it. "while >>desirable to have the address exist, not guarnateed." >>[08:06:46] ted: wandering from the protocol requirement. an >>address could be invalid for other purposes but could get mapped to a >>PSAP. >>[08:07:46] ted: could I give you a PSAP based on the location >>given, if answer is yes then that is the one thing we care about >>[08:08:01] henning: just need a qualification of what it does >>not mean >>[08:08:42] brian: agree, see my previous wording >>[08:09:17] marc: mentions some use case in Texas. >>[08:09:25] brian: but that is not how it will work >>[08:09:40] marc: but if the address does not exist, no PSAP >>[08:09:46] brian: that is making an assumption >>[08:10:35] brian: current MSAG does address ranges, but we >>should have ability in future to work on single addresses >>[08:11:07] marc: do you believe it shouldn't return an answer? >>[08:11:10] brian: ? >>[08:11:41] ted: in some administrations, the answer will be >>"here is your PSAP, and btw the address you gave is foobar" >>[08:13:18] nadine: be able to distinguish if it is the "right" >>PSAP vs "default" PSAP? >>[08:13:47] ted: for validation it would be "right". >>[08:14:33] henning: this has implication on protocol design >>choices. >>[08:15:57] henning: difference in use case in validation and >>non-validation (emergency case) and the bits on the wire in the protocol >>[08:16:00] If the case is that the address is 125 main >>street, and 124 and 126 exist but 125 does not, would validation >>indicate that the address is syntactically valid, the psap returned >>would be for 124 and/or 126? >>[08:17:19] are you asking a question for the room? >>[08:17:36] yes, but we've moved on abit >>[08:18:06] I was trying to clarify comments from several >>people >>[08:19:21] brian: answering randy's q: "I can map it, but it >>isn't really valid. But in an emergency, it would send you to the >>closest PSAP." >>[08:19:32] Thanks, sounds reasonable to me >>[08:19:46] marc: result should be saying there is a problem in >>XML >>[08:19:51] brian: yes >>[08:20:12] brian: it is desirable to say you can get a >>mapping, but there is a problem with the address. >>[08:21:20] henning: even in a real emergency query, this is >>nothing wrong with indicating that the address is foobar as long as the >>PSAP is returned >>[08:22:11] ted: in a real emergency only look at the one thing >>they map on. validation may be a different task. >>[08:22:47] brian: but that work for you >>[08:22:56] ted: that is why this is desirable. >>[08:23:04] nadine: ? >>[08:23:17] nadine: if you only know that it is a known range >>[08:24:34] andy: just need to make sure that implementers >>don't let the error show up in the emergency case >>[08:24:58] roger: do we agree that in addition to the URL that >>it is desirable to have a result code? >>[08:25:10] henning: generally, yup/ >>[08:25:27] is the audio being recorded? >>[08:26:10] henning: it is more than a status code >>[08:26:16] roger: additional information? >>[08:27:13] hannes: Validation Resolution: it MAY be possible >>to return additional information which can be used to determine the >>preceision or resolution of the returned sip uri, for example >> >>---------------- >> >>The meeting minutes of the interim meeting indicate: >>http://www.ietf-ecrit.org/Interim2006/MeetingMinutes.html >> >>---------------- >> >>Issue 15 >> >>Validation of civil location has been hanging around for a while. Should >>it stay in the 02 draft? Andrew thought the issue was how we would do >>validation, not whether. Brian wants to leave the language in, but would >>like to know if people think it's adequate (we're using motivations text >>to describe what validation means). "A successful mapping will work". >> >>We actually do have other requirements that talk about this (doing >>queries at any time), but we don't describe it anywhere else. >> >>Are we actually validating? We don't mean NEMA validation, only asking >>whether it's enough to get back a PSAP mapping. Passing back "here's the >>PSAP" would be sufficient. Can we use another word? "Validation" has >>lots of baggage. Brian wants to make sure that we can get to NEMA >>validation - "a location that a responder knows how to get to". "A >>location that can be sucessfully mapped to one or more PSAPs". >> >>We're trying to encompass both civil location and geolocation in one >>sentence - this is one reason why it's cumbersome. If all of the city of >>Washington goes to one PSAP but the location isn't valid, we still have >>a problem. MSAG values have the same problem, because they carry street >>number ranges and a "valid" street number may not exactly exist - and >>the best MSAG validators today can't guarantee that the address exists. >> >>An address can be "valid enough" to get to the right PSAP, even if it's >>not valid to respond to. Texas has one PSAP entry - so anything would >>work as long as it's in Texas? No, the current MSAG works on address >>ranges - but the street exists. Brian would like for this to work on >>individual addresses, not ranges. >> >>Brian thinks that local PSAPs should be determining what happens for >>various values of "invalid", since calls are going to go somewhere! >> >>Ted thinks that there's a lot of variation in what administrations do >>now and will do in the future. >> >>Will the protocol allow us to tell that we got to the right PSAP, or >>just got a PSAP? >> >>Henning - just returning a SIP URI to let someone ask "where the heck >>are you?" isn't sufficient when we're actually routing an emergency call. >> >>We always get a SIP URI, we're trying to figure out what getting a SIP >>URI actually means for an operational system. >> >>"I got a match on all the XML tags except this one" would be an >>acceptable response, and this would be desirable. This could happen at >>validation time or at emergency call routing time. >> >>Validation may mean "I like the only tags that I care about, and didn't >>look at the ones I don't care about". >> >>Do we agree that we need a result code, in addition to a URI? Partial >>validation may be the common case (public verifiers won't know suite >>numbers/room numbers, for example). >> >>Is this MUST/SHOULD/MAY? The protocol MUST have the mechanism (whether >>it gets used or not is up to the administration). >> >>And we need to be consistent in our RFC 2119 usage (which is always >>problematic for requirements documents anyway, since the meaning is a >>protocol-mechanism meaning, not a protocol-usage meaning). We're making >>a lot of these requirements MUSTs, and that may make the resulting >>protocols clumsy. If we use 2119, we should be using MUST, MAY and >>SHOULD, not just MUST. >> >>Tom pointed out that some mechanisms may be provided by extensions, but >>are not required in the base protocol. >> >>Henning says we're not writing a BCP, so we should consider NOT using >>2119 language. >> >>Randy suggested that we actually spell out "must support", etc. and not >>rely on 2119. Henning - then we should have consistent terminology, >>whether it's upper case or lower case. Randy will audit the existing >>document, but needs input from others. >> >>What about returning an indicator of the resolution of the mapping that >>is returned? >> >>Brian suggested text for a mechanism to indicate that a location or part >>of location does not exist, even if it can be mapped. Should this point >>out the invalid pieces? Aren't these administration-specific? Tags are >>roughly self-describing, but we can't pick one hierarchy - what gets >>returned needs to be free-form. >> >>James - doesn't the text say "location should be sent even if it's >>considered unreliable?" Is this OK? >> >>We will leave L01 language as is, change "location validation" in >>terminology, and we are adding two new requirements to this section. >> >>---------------- >> >>The discussions regarding Issue#15 caused us to change the following >>requirement into two requirements: >>http://www.ietf-ecrit.org:8080/ecrit-req/issue15 >> >>" >> > Lo1. Validation of Civic Location: It MUST be possible to >> >validate a >> > civic location prior to its use in an actual emergency call. >> > >> > Motivation: Location validation provides an opportunity to help >> > assure ahead of time, whether successful mapping to the >> > appropriate PSAP will likely occur when it is required. >> > Validation may also help to avoid delays during emergency call >> > setup due to invalid locations. >> >>" >> >>to: >> >>" >>Lo1X. Validation Resolution: The mapping protocol >>MUST support the return of additional information which can be used >>to determine the precision or resolution of the data elements used to >>determine a PSAP URI, for example. >> >>Lo1XX. Indication of non-existent location: The >>protocol MUST support a mechanism to indicate that a location or a >>part of a location is known to not exist, even if a valid location-to-PSAP >>uri mapping can be provided. >>" >> >>The term validation appears only in the following sections. >> >>Section 1 (Introduction): >> >>" >> As used in this document, validation of location does not require to >> ascertain whether the location actually exists. For example, >> validation might only check that the house number in a civic address >> falls within the assigned range, not whether that building exists at >> that spot. However, such higher precision validation is desirable. >>" >> >>Section 2 (Terminology): >>" >> Location validation: A caller location is considered valid if the >> civic or geographic location is recognizable within an acceptable >> location reference systems (e.g., USPS, WGS-84, etc.), and can be >> mapped to one or more PSAPs. While it is desirable to determine >> that a location exists, validation may not ensure that such a >> location exists. Location validation ensures that a location is >> able to be referenced for mapping, but makes no assumption about >> the association between the caller and the caller's location. >>" >> >>Section 7 (Mapping Protocol): >> >>" >> Ma22. Validation of civic location: The mapping protocol MUST >> implement a method via a mapping request, that makes it possible >> for a mapping server to validate a civic location prior to that >> location's use in an actual emergency call. >> >> Motivation: Location validation provides an opportunity to help >> assure ahead of time, whether successful mapping to the >> appropriate PSAP will likely occur when it is required. >> Validation may also help to avoid delays during emergency call >> setup due to invalid locations. >> >> Ma23. Validation resolution: The mapping protocol MUST support >> (i.e., required to implement, but not required for use) the return >> of additional information which can be used to determine the >> precision or resolution of the data elements used to determine a >> PSAP URI. >> >> Motivation: The mapping server may not use all the data elements >> in the provided location information to determine a match, or may >> be able to find a match based on all of the information except for >> some specific data elements. The uniqueness of this information >> set may be used to differentiate among emergency jurisdictions. >> Precision or resolution in the context of this requirement might >> mean, for example, explicit identification of the data elements >> that were used successfully in the mapping. >> >> Ma25. Limits to validation: Successful validation of a civic >> location MUST NOT be required to place an emergency call. >> >> Motivation: In some cases, a civic location may not be considered >> valid. This fact should not result in the call being dropped or >> rejected by any entity along the signaling path to the PSAP. >>" >> >>I think we need to differentiate civic and geospatial location >>information. >> >>Geospatial location information: >> >> * Can the request be mapped to one or more PSAPs? >> >> This is normal mapping protocol operation. Nothing special here. >> >> * Does the address exist? >> >> There is no question that this address exists >> if the coordinate reference system was understood. >> >> >>Civic location information: >> >> * Can the request be mapped to one or more PSAPs? >> >> The text from Ma23 is applicable here: >> >> Motivation: The mapping server may not use all the data elements >> in the provided location information to determine a match, or may >> be able to find a match based on all of the information except for >> some specific data elements. The uniqueness of this information >> set may be used to differentiate among emergency jurisdictions. >> Precision or resolution in the context of this requirement might >> mean, for example, explicit identification of the data elements >> that were used successfully in the mapping. >> >> * Does the address exist? >> >> It is possible that a given civic address does not exist. >> An additional database, which contains the list of existing >> addresses, needs to be available. >> >> >>What we can do is to be more specific about the type of behavior we want >>from the mapping protocol. >>Do we want the client to be able to express that the mapping server >>should check the civic address for existence? >>Do we want the mapping server to be able to indicate that the civic >>address was checked against the database? >>I don't think anything needs to be done with regard to geospatial >>location info. >> >>Do we need something else? >> >>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 Thu Apr 20 16:18:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWfbZ-0003pE-78; Thu, 20 Apr 2006 16:18:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWfbY-0003p8-Gw for ecrit@ietf.org; Thu, 20 Apr 2006 16:18:20 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWfbX-0003zx-7Q for ecrit@ietf.org; Thu, 20 Apr 2006 16:18:20 -0400 Received: (qmail invoked by alias); 20 Apr 2006 20:18:16 -0000 Received: from p5498669D.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.102.157] by mail.gmx.net (mp029) with SMTP; 20 Apr 2006 22:18:16 +0200 X-Authenticated: #29516787 Message-ID: <4447EC87.70409@gmx.net> Date: Thu, 20 Apr 2006 22:18:15 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] Issue 35: Location Validation References: <8C837214C95C864C9F34F3635C2A657504BBB7FA@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657504BBB7FA@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ad34ef4f81ffc6635f3eb8320caa45a 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: , Errors-To: ecrit-bounces@ietf.org Hi Roger, Roger Marshall wrote: > I think Brian answered most of these, but since I didn't see them > captured individually, here's my take: > > [from Hannes, (ref. re-pasted from summary at end)] > > What we can do is to be more specific about the type of behavior we want > from the mapping protocol. > > Do we want the client to be able to express that the mapping server > should check the civic address for existence? > > [RM] - Yes, I think so. I propose the following new requirements: > > LoX'. The mapping protocol MUST support a mechanism which provides an > indication as to whether a specific civic location exists. Fine. Easy. > > LoX''. The mapping protocol MUST support a mechanism which provides an > indication that specific civic location does not exist exactly, but does > fall within a acceptable range of (address) values. Fine, but complex. > > LoX'''. The mapping protocol MUST support a mechanism which provides > alternate location choices, based on matching criteria (e.g., if 123 > Main St. DNE, might return "'123 S. Main St.' or '123 N. Main St.' > alternates exist"). From a requirement point of view it looks easy but I would like to see concrete proposals how to accomplish this goal. I don't want to turn the mapping protocol into a "SELECT * FROM ...." database retrieval system. > > LoX''''. The mapping protocol MUST support a mechanism which provides > an indication of which data elements of a civic location were, and were > not found in the database (e.g., "'123 Main St. Mytown' not found, but > 'Main St. Mytown' was found". One could theoretically indicate which attributes matched and which attributes didn't (e.g., A1, A2, .... A5 matched but BLD didn't). > > > Do we want the mapping server to be able to indicate that the civic > address was checked against the database? > > [RM] - Yes, and precisely which database. Here's my suggested > requirement: > > LoY. The mapping protocol MUST support a mechanism which provides an > indication as to a specific "type" of location database used for either > civic or geographic location matching (e.g., USPS, MSAG, GDT, etc.). Fine; Wouldn't we want to carry this information into a PIDF-LO itself to indicate the quality of the returned location information. As such, we would have to tackle it in Geopriv. > > > I don't think anything needs to be done with regard to geospatial > location info. > > [RM] - I agree that for the requirements draft, geo is probably covered > well enough, but as James pointed out, a subsequent geo-specific draft > would be useful. Maybe. Not sure. I am concerned about the complexity of all these sophisticated error handling mechanisms. I wonder what a client is really going todo about them. Ciao Hannes > > Roger Marshall. > > >>-----Original Message----- >>From: James M. Polk [mailto:jmpolk@cisco.com] >>Sent: Wednesday, April 19, 2006 3:23 PM >>To: br@brianrosen.net; Hannes Tschofenig >>Cc: ecrit@ietf.org >>Subject: Re: [Ecrit] Issue 35: Location Validation >> >>I agree with almost everything Brian says (surprise!), >>especially about how to work out additional info if a match isn't made. >> >>I'm weary about how to pull this off for geo though, due to >>the rigidity of what doesn't constitute a match. Given that >>GPS accuracy is roughly within >>15 ft after a few minutes and within a few feet after a bit >>longer (you get the idea of increasing accuracry with time), >>with some reports where they are might fall *just* outside of >>a valid location match, and return an error. This might just >>occur for someone in the middle of the street, say at a car >>accident or a hurt child next to their bike, and no one wants >>this not getting through to a PSAP. >> >>Geo almost should have a match to some PSAP if the caller is >>within a jurisdiction (say a country or state or province or >>county), and not only when they are at a street address that's >>nice and neat like civic addresses, but this is an interesting >>problem we haven't really gotten into to solve for yet, have we. >> >>How does the Phase-II cellular world solve this validation >>question when presented with GPS coordinates to a wreck down a >>canyon road that has no >>(housing) lot addresses? >> >>If this isn't solved for in an agreed upon way, this almost >>begs for a "Geo Considerations" ID to have a specific discussion about. >> >>At 05:02 PM 4/19/2006 -0500, br@brianrosen.net wrote: >> >>>In North America, validation is a well known, and required step in >>>processing a civic location. In the current system, there is no >>>validation of geo. >>> >>>In the end, validation in the current system means: >>> Do we know where this location is; can we send someone to help >>> by giving him this location? >>> >>>To do that, there is presently a database, called the Master Street >>>Address Guide, which contains a list of all the "known" >> >>street addresses. >> >>>Validation, today, means that before a location is put into the >>>database that is actually used to determine address when an emergency >>>call is made (the "ALI" database), the location is looked up in the >>>MSAG. If there is a match, the update to the ALI is permitted. If >>>there is no match, the update is not allowed and the carrier >> >>attempting >> >>>to update the ALI has to go figure out what happened. >>> >>>The MSAG database sometimes also is aligned with the database used to >>>dispatch responders. A location submitted to the responder Computer >>>Aided Dispatch system must be "MSAG Valid". >>> >>>The emergency call system in North America is heavily dependent on >>>validation; many attempts at coming up with a location don't yield >>>something unique enough to use for locating where someone is >>>unambiguously so that help can be dispatched correctly to where they >>>are when they can't answer questions. This is a firm requirement for >>>us, and we really, really need to have it. >>> >>>The current MSAG would be the natural beginning source of the mapping >>>database envisioned by ecrit. There are a whole host of >> >>formatting and >> >>>correlation issues. >>> >>>It is essential that validation happen BEFORE an emergency call. >>>Ideally, it would happen when it happens now; when a location is put >>>into the database that stores location (the Location Server). >>> >>>Given the current design of the ecrit mechanisms, and accepted >>>requirements, the minimal way to do validation is to allow a mapping >>>any time (like when the location is put into the Location >> >>Server), and >> >>>return some kind of error when the location presented is not in the >>>database. So validation means "I have no mapping for that location". >>> >>>A better answer would be to have a mechanism in LoST specifically for >>>validation that could return more information than just "I have no >>>mapping". For example, it would be helpful to return possible >>>alternative valid mappings. A typical example is you query for "100 >>>Main St" and the mapping server returns "I don't have a 100 Main St, >>>but I have a 100 N Main St or 100 S Main St". You could also >> >>return an >> >>>indication of which elements in the input location were valid >> >>(Country, >> >>>State, and City was valid, but Street Name was not). It >> >>would also be >> >>>useful to return information not included in the original >> >>request (for >> >>>example, you query with the postal community name, but leave >> >>off county >> >>>and jurisdictional community name, if a unique mapping was found, the >>>missing data was supplied). >>> >>>It would also be good to have a form of validation for geo, which >>>amounts to "there are no URIs for the service you requested with the >>> location you provided". If you ask for police while you are in >>>the middle of the Atlantic Ocean, you might get that response. >>> >>> >>>Brian >>> >>>>Hi all, >>>> >>>>we need to close issue#35 about location validation. The issue can >>>>be found at: http://www.ietf-ecrit.org:8080/ecrit-req/issue35. >>>> >>>>Note that I provide a summary at the end of my mail. >>>> >>>> >> >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-06 >> >>>>.txt >>>>says: >>>> >>>>" >>>> Location validation: A caller location is considered >> >>valid if the >> >>>> civic or geographic location is recognizable within >> >>an acceptable >> >>>> location reference systems (e.g., USPS, WGS-84, >> >>etc.), and can be >> >>>> mapped to one or more PSAPs. While it is desirable >> >>to determine >> >>>> that a location exists, validation may not ensure >> >>that such a >> >>>> location exists. Location validation ensures that >> >>a location is >> >>>> able to be referenced for mapping, but makes no >> >>assumption about >> >>>> the association between the caller and the caller's >> >>location. >> >>>>" >>>> >>>>We had a discussion about this subject during the interim meeting: >>>>http://www.ietf-ecrit.org/Interim2006/Jabber-Log_2006-02-01.html >>>> >>>>---------------- >>>> >>>>[07:53:24] roger: issue 15 re validation of civic >>>>[07:53:39] andy: I thought the list left the issue not >>>>about not doing it, but how. >>>>[07:53:46] roger: need to know about the language in the >>>>draft [07:54:08] brian: something about a way to do it >>>>[07:54:24] jon: related to other req. such as >> >>querying it >> >>>>anywhere. >>>>[07:54:37] james p.: we are no validating [07:54:56] >>>> ted: text in the issue tracker is not the meaning of >>>>validation in NENA, etc... >>>>[07:55:12] ted: this is a valuable piece of >> >>protocol machinery. >> >>>>[07:55:39] james: that makes sense, but the text doesn't >>>>say that [07:56:03] brian: if validation is defined as >>>>succesful mapping to the PSAP, then that is what we want. >>>>[07:56:11] james: need other word than "valid" >>>>[07:56:28] brian: what we have can be used for NENA view >>>>of the world [07:57:01] james: anything out of this >>>>building to the proper PSAP, but not floor by floor [07:57:16] >>>> brian: the requirement is to know that you can send a >>>>responder. >>>>[07:57:32] marc: not sure that is the NENA view, re ESN >>>>[07:58:04] brian: the location is knowing we can send a >>>>responder [07:58:09] nadine: agree [07:58:52] >>>>brian: definition of valdiation to be successful mapping to occur >>>>for the location [07:59:10] ted: this requirement needs >>>>the point brian is making [07:59:49] james: >> >>concerned with >> >>>>people thinking we mean something much more precise [08:00:12] >>>> hannes: the definition does not match the requirmenet >>>>[08:00:26] roger: let's examine the definition first >>>>[08:01:09] nadine & brian: this is a good defintion >>>>[08:01:15] james: no, that is cumbersome [08:03:04] >>>> henning: problem is that this is trying to define >>>>validation for both civic and geo. first test is syntactic >> >>validity. >> >>>>the description is not clear if the actual address exists. >>>>[08:03:49] henning: second test, is there a >> >>valid mapping, >> >>>>third, is there a street address that can be routed to. >>>>[08:04:14] brian: clarifying this is a good idea. >>>>[08:04:21] nadine: agree with 1 and 2, but not 3 >>>>[08:04:27] roger: we cannot achieve 3 [08:04:38] >> >> >> >>>>henning: then we need to be clear about it [08:05:36] >>>>roger: "but not equivicate to an address" ? >>>>[08:05:58] brian: add new sentence to clarify it. "while >>>>desirable to have the address exist, not guarnateed." >>>>[08:06:46] ted: wandering from the protocol requirement. >>>>an address could be invalid for other purposes but could >> >>get mapped >> >>>>to a PSAP. >>>>[08:07:46] ted: could I give you a PSAP based on the >>>>location given, if answer is yes then that is the one >> >>thing we care >> >>>>about [08:08:01] henning: just need a qualification of >>>>what it does not mean [08:08:42] brian: agree, see my >>>>previous wording [08:09:17] marc: mentions some use case >>>>in Texas. >>>>[08:09:25] brian: but that is not how it will work >>>>[08:09:40] marc: but if the address does not exist, no >>>>PSAP [08:09:46] brian: that is making an assumption >>>>[08:10:35] brian: current MSAG does address >> >>ranges, but we >> >>>>should have ability in future to work on single addresses >> >>[08:11:07] >> >>>> marc: do you believe it shouldn't return an answer? >>>>[08:11:10] brian: ? >>>>[08:11:41] ted: in some administrations, the answer will >>>>be "here is your PSAP, and btw the address you gave is foobar" >>>>[08:13:18] nadine: be able to distinguish if it >> >>is the "right" >> >>>>PSAP vs "default" PSAP? >>>>[08:13:47] ted: for validation it would be "right". >>>>[08:14:33] henning: this has implication on protocol >>>>design choices. >>>>[08:15:57] henning: difference in use case in validation >>>>and non-validation (emergency case) and the bits on the >> >>wire in the >> >>>>protocol [08:16:00] If the case is that the address is >>>>125 main street, and 124 and 126 exist but 125 does not, would >>>>validation indicate that the address is syntactically valid, the >>>>psap returned would be for 124 and/or 126? >>>>[08:17:19] are you asking a question for the room? >>>>[08:17:36] yes, but we've moved on abit [08:18:06] >>>> I was trying to clarify comments from several people >>>>[08:19:21] brian: answering randy's q: "I can >> >>map it, but >> >>>>it isn't really valid. But in an emergency, it would send >> >>you to the >> >>>>closest PSAP." >>>>[08:19:32] Thanks, sounds reasonable to me [08:19:46] >>>> marc: result should be saying there is a problem in XML >>>>[08:19:51] brian: yes [08:20:12] brian: it is >>>>desirable to say you can get a mapping, but there is a >> >>problem with >> >>>>the address. >>>>[08:21:20] henning: even in a real emergency query, this >>>>is nothing wrong with indicating that the address is >> >>foobar as long >> >>>>as the PSAP is returned [08:22:11] ted: in a real >>>>emergency only look at the one thing they map on. >> >>validation may be >> >>>>a different task. >>>>[08:22:47] brian: but that work for you [08:22:56] >>>> ted: that is why this is desirable. >>>>[08:23:04] nadine: ? >>>>[08:23:17] nadine: if you only know that it is a known >>>>range [08:24:34] andy: just need to make sure that >>>>implementers don't let the error show up in the emergency case >>>>[08:24:58] roger: do we agree that in addition >> >>to the URL >> >>>>that it is desirable to have a result code? >>>>[08:25:10] henning: generally, yup/ [08:25:27] >>>>is the audio being recorded? >>>>[08:26:10] henning: it is more than a status code >>>>[08:26:16] roger: additional information? >>>>[08:27:13] hannes: Validation Resolution: it MAY be >>>>possible to return additional information which can be used to >>>>determine the preceision or resolution of the returned sip >> >>uri, for >> >>>>example >>>> >>>>---------------- >>>> >>>>The meeting minutes of the interim meeting indicate: >>>>http://www.ietf-ecrit.org/Interim2006/MeetingMinutes.html >>>> >>>>---------------- >>>> >>>>Issue 15 >>>> >>>>Validation of civil location has been hanging around for a while. >>>>Should it stay in the 02 draft? Andrew thought the issue >> >>was how we >> >>>>would do validation, not whether. Brian wants to leave the >> >>language >> >>>>in, but would like to know if people think it's adequate (we're >>>>using motivations text to describe what validation means). >> >>"A successful mapping will work". >> >>>>We actually do have other requirements that talk about this (doing >>>>queries at any time), but we don't describe it anywhere else. >>>> >>>>Are we actually validating? We don't mean NEMA validation, only >>>>asking whether it's enough to get back a PSAP mapping. >> >>Passing back >> >>>>"here's the PSAP" would be sufficient. Can we use another word? >>>>"Validation" has lots of baggage. Brian wants to make sure that we >>>>can get to NEMA validation - "a location that a responder >> >>knows how >> >>>>to get to". "A location that can be sucessfully mapped to >> >>one or more PSAPs". >> >>>>We're trying to encompass both civil location and >> >>geolocation in one >> >>>>sentence - this is one reason why it's cumbersome. If all of the >>>>city of Washington goes to one PSAP but the location isn't >> >>valid, we >> >>>>still have a problem. MSAG values have the same problem, because >>>>they carry street number ranges and a "valid" street >> >>number may not >> >>>>exactly exist - and the best MSAG validators today can't >> >>guarantee that the address exists. >> >>>>An address can be "valid enough" to get to the right PSAP, even if >>>>it's not valid to respond to. Texas has one PSAP entry - >> >>so anything >> >>>>would work as long as it's in Texas? No, the current MSAG works on >>>>address ranges - but the street exists. Brian would like >> >>for this to >> >>>>work on individual addresses, not ranges. >>>> >>>>Brian thinks that local PSAPs should be determining what >> >>happens for >> >>>>various values of "invalid", since calls are going to go somewhere! >>>> >>>>Ted thinks that there's a lot of variation in what administrations >>>>do now and will do in the future. >>>> >>>>Will the protocol allow us to tell that we got to the >> >>right PSAP, or >> >>>>just got a PSAP? >>>> >>>>Henning - just returning a SIP URI to let someone ask "where the >>>>heck are you?" isn't sufficient when we're actually >> >>routing an emergency call. >> >>>>We always get a SIP URI, we're trying to figure out what getting a >>>>SIP URI actually means for an operational system. >>>> >>>>"I got a match on all the XML tags except this one" would be an >>>>acceptable response, and this would be desirable. This >> >>could happen >> >>>>at validation time or at emergency call routing time. >>>> >>>>Validation may mean "I like the only tags that I care about, and >>>>didn't look at the ones I don't care about". >>>> >>>>Do we agree that we need a result code, in addition to a URI? >>>>Partial validation may be the common case (public verifiers won't >>>>know suite numbers/room numbers, for example). >>>> >>>>Is this MUST/SHOULD/MAY? The protocol MUST have the mechanism >>>>(whether it gets used or not is up to the administration). >>>> >>>>And we need to be consistent in our RFC 2119 usage (which >> >>is always >> >>>>problematic for requirements documents anyway, since the >> >>meaning is >> >>>>a protocol-mechanism meaning, not a protocol-usage meaning). We're >>>>making a lot of these requirements MUSTs, and that may make the >>>>resulting protocols clumsy. If we use 2119, we should be >> >>using MUST, >> >>>>MAY and SHOULD, not just MUST. >>>> >>>>Tom pointed out that some mechanisms may be provided by >> >>extensions, >> >>>>but are not required in the base protocol. >>>> >>>>Henning says we're not writing a BCP, so we should consider NOT >>>>using >>>>2119 language. >>>> >>>>Randy suggested that we actually spell out "must support", >> >>etc. and >> >>>>not rely on 2119. Henning - then we should have consistent >>>>terminology, whether it's upper case or lower case. Randy >> >>will audit >> >>>>the existing document, but needs input from others. >>>> >>>>What about returning an indicator of the resolution of the mapping >>>>that is returned? >>>> >>>>Brian suggested text for a mechanism to indicate that a >> >>location or >> >>>>part of location does not exist, even if it can be mapped. Should >>>>this point out the invalid pieces? Aren't these >>>>administration-specific? Tags are roughly self-describing, but we >>>>can't pick one hierarchy - what gets returned needs to be >> >>free-form. >> >>>>James - doesn't the text say "location should be sent even if it's >>>>considered unreliable?" Is this OK? >>>> >>>>We will leave L01 language as is, change "location validation" in >>>>terminology, and we are adding two new requirements to >> >>this section. >> >>>>---------------- >>>> >>>>The discussions regarding Issue#15 caused us to change the >> >>following >> >>>>requirement into two requirements: >>>>http://www.ietf-ecrit.org:8080/ecrit-req/issue15 >>>> >>>>" >>>> > Lo1. Validation of Civic Location: It MUST be possible to >>>> >validate a >>>> > civic location prior to its use in an actual >> >>emergency call. >> >>>> > >>>> > Motivation: Location validation provides an >> >>opportunity to help >> >>>> > assure ahead of time, whether successful mapping to the >>>> > appropriate PSAP will likely occur when it is required. >>>> > Validation may also help to avoid delays during >> >>emergency call >> >>>> > setup due to invalid locations. >>>> >>>>" >>>> >>>>to: >>>> >>>>" >>>>Lo1X. Validation Resolution: The mapping protocol MUST >> >>support the >> >>>>return of additional information which can be used to >> >>determine the >> >>>>precision or resolution of the data elements used to determine a >>>>PSAP URI, for example. >>>> >>>>Lo1XX. Indication of non-existent location: The protocol MUST >>>>support a mechanism to indicate that a location or a part of a >>>>location is known to not exist, even if a valid >> >>location-to-PSAP uri >> >>>>mapping can be provided. >>>>" >>>> >>>>The term validation appears only in the following sections. >>>> >>>>Section 1 (Introduction): >>>> >>>>" >>>> As used in this document, validation of location does >> >>not require to >> >>>> ascertain whether the location actually exists. For example, >>>> validation might only check that the house number in a >> >>civic address >> >>>> falls within the assigned range, not whether that >> >>building exists at >> >>>> that spot. However, such higher precision validation >> >>is desirable. >> >>>>" >>>> >>>>Section 2 (Terminology): >>>>" >>>> Location validation: A caller location is considered >> >>valid if the >> >>>> civic or geographic location is recognizable within >> >>an acceptable >> >>>> location reference systems (e.g., USPS, WGS-84, >> >>etc.), and can be >> >>>> mapped to one or more PSAPs. While it is desirable >> >>to determine >> >>>> that a location exists, validation may not ensure >> >>that such a >> >>>> location exists. Location validation ensures that >> >>a location is >> >>>> able to be referenced for mapping, but makes no >> >>assumption about >> >>>> the association between the caller and the caller's >> >>location. >> >>>>" >>>> >>>>Section 7 (Mapping Protocol): >>>> >>>>" >>>> Ma22. Validation of civic location: The mapping protocol MUST >>>> implement a method via a mapping request, that >> >>makes it possible >> >>>> for a mapping server to validate a civic location >> >>prior to that >> >>>> location's use in an actual emergency call. >>>> >>>> Motivation: Location validation provides an >> >>opportunity to help >> >>>> assure ahead of time, whether successful mapping to the >>>> appropriate PSAP will likely occur when it is required. >>>> Validation may also help to avoid delays during >> >>emergency call >> >>>> setup due to invalid locations. >>>> >>>> Ma23. Validation resolution: The mapping protocol MUST support >>>> (i.e., required to implement, but not required for >> >>use) the return >> >>>> of additional information which can be used to determine the >>>> precision or resolution of the data elements used >> >>to determine a >> >>>> PSAP URI. >>>> >>>> Motivation: The mapping server may not use all the >> >>data elements >> >>>> in the provided location information to determine a >> >>match, or may >> >>>> be able to find a match based on all of the >> >>information except for >> >>>> some specific data elements. The uniqueness of >> >>this information >> >>>> set may be used to differentiate among emergency >> >>jurisdictions. >> >>>> Precision or resolution in the context of this >> >>requirement might >> >>>> mean, for example, explicit identification of the >> >>data elements >> >>>> that were used successfully in the mapping. >>>> >>>> Ma25. Limits to validation: Successful validation of a civic >>>> location MUST NOT be required to place an emergency call. >>>> >>>> Motivation: In some cases, a civic location may not >> >>be considered >> >>>> valid. This fact should not result in the call >> >>being dropped or >> >>>> rejected by any entity along the signaling path to the PSAP. >>>>" >>>> >>>>I think we need to differentiate civic and geospatial location >>>>information. >>>> >>>>Geospatial location information: >>>> >>>> * Can the request be mapped to one or more PSAPs? >>>> >>>> This is normal mapping protocol operation. Nothing >> >>special here. >> >>>> * Does the address exist? >>>> >>>> There is no question that this address exists >>>> if the coordinate reference system was understood. >>>> >>>> >>>>Civic location information: >>>> >>>> * Can the request be mapped to one or more PSAPs? >>>> >>>> The text from Ma23 is applicable here: >>>> >>>> Motivation: The mapping server may not use all the >> >>data elements >> >>>> in the provided location information to determine a >> >>match, or may >> >>>> be able to find a match based on all of the >> >>information except for >> >>>> some specific data elements. The uniqueness of >> >>this information >> >>>> set may be used to differentiate among emergency >> >>jurisdictions. >> >>>> Precision or resolution in the context of this >> >>requirement might >> >>>> mean, for example, explicit identification of the >> >>data elements >> >>>> that were used successfully in the mapping. >>>> >>>> * Does the address exist? >>>> >>>> It is possible that a given civic address does not exist. >>>> An additional database, which contains the list of existing >>>> addresses, needs to be available. >>>> >>>> >>>>What we can do is to be more specific about the type of >> >>behavior we >> >>>>want from the mapping protocol. >>>>Do we want the client to be able to express that the >> >>mapping server >> >>>>should check the civic address for existence? >>>>Do we want the mapping server to be able to indicate that >> >>the civic >> >>>>address was checked against the database? >>>>I don't think anything needs to be done with regard to geospatial >>>>location info. >>>> >>>>Do we need something else? >>>> >>>>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 >> >>_______________________________________________ >>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 Thu Apr 20 16:20:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWfdl-0004Q0-Fa; Thu, 20 Apr 2006 16:20:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWfdj-0004Pp-IC for ecrit@ietf.org; Thu, 20 Apr 2006 16:20:35 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWfdj-00048c-1y for ecrit@ietf.org; Thu, 20 Apr 2006 16:20:35 -0400 Received: from ([90.152.52.44]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.130376036; Thu, 20 Apr 2006 16:20:14 -0400 Importance: normal Priority: normal Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01AL10015010117.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Apr 2006 15:20:14 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 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] Getting location behind NAT Date: Thu, 20 Apr 2006 15:20:13 -0500 Message-ID: <9888E1AA13C3A1459D122996A58C0E1107CA3549@bre2k61p-55> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Getting location behind NAT Thread-Index: AcZke5wjWok7LQ5nTI+LoNtwsLw+hwABSJ2gAA0KajA= From: "Stark, Barbara" To: "Eric Turcotte \(QC/EMC\)" , X-OriginalArrivalTime: 20 Apr 2006 20:20:14.0164 (UTC) FILETIME=[D4FAD940:01C664B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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: , Errors-To: ecrit-bounces@ietf.org The problem is the legacy NAT + DHCP Server, that knows nothing about options for providing location. That's one of the reasons why a number of service providers have requested that there be an application layer solution for providing location, that easily traverses NAT. This would allow location determination mechanisms to work without upgrading or replacing home and small business routers. As for the device that moves from AP to AP, one way to handle this is for the device to request location everytime it established a new AP connection (assuming it is aware that it has moved to a new AP). Barbara > -----Original Message----- > From: Eric Turcotte (QC/EMC) [mailto:eric.turcotte@ericsson.com] > Sent: Thursday, April 20, 2006 10:06 AM > To: br@brianrosen.net > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Getting location behind NAT >=20 >=20 > Hi Brian, > Some comments below. > Regards, > Eric.=20 >=20 > > -----Original Message----- > > From: br@brianrosen.net [mailto:br@brianrosen.net]=20 > > Sent: Thursday, April 20, 2006 9:09 AM > > To: Eric Turcotte (QC/EMC) > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Getting location behind NAT > >=20 > > Lets walk through this, because I think you will find it=20 > > works pretty well with one exception: > >=20 > > A device, say a hard SIP Phone sits behind a NAT. It has an=20 > > internal address. The device makes a DHCP query to a DHCP=20 > > server that sits beyond the NAT. >=20 > My assumption was that the SIP phone got its IP address from a "local" > DHCP server, i.e. DHCP server not behind the NAT. However, we=20 > would like > to get the UAC location from the DHCP server beyond the NAT. I think > this bring the issue you point out below. >=20 > >=20 > > The DHCP request is relayed by the NAT. It changes the from=20 > > IP address to its external address. > >=20 > > The DHCP server gets the request, and processes it. It=20 > > returns the location associated with the subscriber/user,=20 > > whether it uses the MAC address, the IP address, or a DHCP=20 > > relay circuit ID to the external address (which is the NAT). > >=20 > > The NAT gets the DHCP reply, changes the To address and=20 > > relays the response to the SIP Phone. > >=20 > > So, as long as its correct that all devices behind the NAT=20 > > are at the same location, it works. >=20 > I would assume this would cover the majority of cases (that=20 > the UACs are > at the same location as the NAT. However, do we have cases=20 > where you may > have a WLAN access and the UAC may move to different APs?=20 >=20 > >=20 > > The thing that doesn't work is if the NAT is not just a NAT,=20 > > but a router, which supplies DHCP service for all the clients=20 > > behind the NAT. Then, the DHCP server that the phone is=20 > > querying is not the extenal DHCP server, its the one in the=20 > > router. It would have to know to ask for location from its=20 > > DHCP server (the external one) and relay that option to its=20 > > internal clients. >=20 > Yes, this is exacltely the issue I had. It would be nice that=20 > this would > work without having the UAC to have prior knowledge of the=20 > external DHCP > server.=20 >=20 > >=20 > > Brian > >=20 > > > Hi, > > > I was wondering how a UAC gets its location from a DHCP=20 > > Server behind=20 > > > a NAT. Is this addressed in the current GEO RFC or CIVIC drafts? > > >=20 > >=20 > = http://tools.ietf.org/html?rfc=3D&draft=3Ddraft-ietf-geopriv-dhcp-civil-0= 9 > > > &s > > > ubmit=3DSubmit > > > http://tools.ietf.org/html/rfc3825 > > > Thanks, > > > Eric. > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > >=20 > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 117 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 20 20:11:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWjEX-0007ib-RC; Thu, 20 Apr 2006 20:10:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWjEW-0007iW-2N for ecrit@ietf.org; Thu, 20 Apr 2006 20:10:48 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWjEV-0001hI-2I for ecrit@ietf.org; Thu, 20 Apr 2006 20:10:48 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 14A354CD; Fri, 21 Apr 2006 02:10:46 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 02:10:45 +0200 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 02:10:45 +0200 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 19:10:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Getting location behind NAT Date: Thu, 20 Apr 2006 20:10:41 -0400 Message-ID: <67048CBE51B1644D89DDD3B7C9F2D19EE0F782@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Getting location behind NAT Thread-Index: AcZke5wjWok7LQ5nTI+LoNtwsLw+hwABSJ2gAA0KajAAB2hKEA== From: "Eric Turcotte \(QC/EMC\)" To: "Stark, Barbara" X-OriginalArrivalTime: 21 Apr 2006 00:10:43.0005 (UTC) FILETIME=[079C86D0:01C664D8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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: , Errors-To: ecrit-bounces@ietf.org Hi Barbara, Thanks for your reply. Some comments inline. Regards, Eric. > -----Original Message----- > From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]=20 > Sent: Thursday, April 20, 2006 4:20 PM > To: Eric Turcotte (QC/EMC); br@brianrosen.net > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Getting location behind NAT >=20 > The problem is the legacy NAT + DHCP Server, that knows=20 > nothing about options for providing location. That's one of=20 > the reasons why a number of service providers have requested=20 > that there be an application layer solution for providing=20 > location, that easily traverses NAT. This would allow=20 > location determination mechanisms to work without upgrading=20 > or replacing home and small business routers. Yes, I agree that this would be an issue as well. I was not there yet. I was assuming NAT and DHCP Server that would understand the new options, and still having the issue. Is there more info available about the application layer solution? >=20 > As for the device that moves from AP to AP, one way to handle=20 > this is for the device to request location everytime it=20 > established a new AP connection (assuming it is aware that it=20 > has moved to a new AP). Yes, that would work I think, given that the primary issue of NAT is resolved. > Barbara >=20 > > -----Original Message----- > > From: Eric Turcotte (QC/EMC) [mailto:eric.turcotte@ericsson.com] > > Sent: Thursday, April 20, 2006 10:06 AM > > To: br@brianrosen.net > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Getting location behind NAT > >=20 > >=20 > > Hi Brian, > > Some comments below. > > Regards, > > Eric.=20 > >=20 > > > -----Original Message----- > > > From: br@brianrosen.net [mailto:br@brianrosen.net] > > > Sent: Thursday, April 20, 2006 9:09 AM > > > To: Eric Turcotte (QC/EMC) > > > Cc: ecrit@ietf.org > > > Subject: Re: [Ecrit] Getting location behind NAT > > >=20 > > > Lets walk through this, because I think you will find it works=20 > > > pretty well with one exception: > > >=20 > > > A device, say a hard SIP Phone sits behind a NAT. It has an=20 > > > internal address. The device makes a DHCP query to a DHCP server=20 > > > that sits beyond the NAT. > >=20 > > My assumption was that the SIP phone got its IP address=20 > from a "local" > > DHCP server, i.e. DHCP server not behind the NAT. However, we would=20 > > like to get the UAC location from the DHCP server beyond the NAT. I=20 > > think this bring the issue you point out below. > >=20 > > >=20 > > > The DHCP request is relayed by the NAT. It changes the from IP=20 > > > address to its external address. > > >=20 > > > The DHCP server gets the request, and processes it. It=20 > returns the=20 > > > location associated with the subscriber/user, whether it uses the=20 > > > MAC address, the IP address, or a DHCP relay circuit ID to the=20 > > > external address (which is the NAT). > > >=20 > > > The NAT gets the DHCP reply, changes the To address and=20 > relays the=20 > > > response to the SIP Phone. > > >=20 > > > So, as long as its correct that all devices behind the NAT are at=20 > > > the same location, it works. > >=20 > > I would assume this would cover the majority of cases (that=20 > the UACs=20 > > are at the same location as the NAT. However, do we have=20 > cases where=20 > > you may have a WLAN access and the UAC may move to different APs? > >=20 > > >=20 > > > The thing that doesn't work is if the NAT is not just a NAT,=20 > > > but a router, which supplies DHCP service for all the clients=20 > > > behind the NAT. Then, the DHCP server that the phone is=20 > > > querying is not the extenal DHCP server, its the one in the=20 > > > router. It would have to know to ask for location from its=20 > > > DHCP server (the external one) and relay that option to its=20 > > > internal clients. > >=20 > > Yes, this is exacltely the issue I had. It would be nice that=20 > > this would > > work without having the UAC to have prior knowledge of the=20 > > external DHCP > > server.=20 > >=20 > > >=20 > > > Brian > > >=20 > > > > Hi, > > > > I was wondering how a UAC gets its location from a DHCP=20 > > > Server behind=20 > > > > a NAT. Is this addressed in the current GEO RFC or=20 > CIVIC drafts? > > > >=20 > > >=20 > >=20 > = http://tools.ietf.org/html?rfc=3D&draft=3Ddraft-ietf-geopriv-dhcp-civil-0= 9 > > > > &s > > > > ubmit=3DSubmit > > > > http://tools.ietf.org/html/rfc3825 > > > > Thanks, > > > > Eric. > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 >=20 > ***** >=20 > The information transmitted is intended only for the person=20 > or entity to which it is addressed and may contain=20 > confidential, proprietary, and/or privileged material. Any=20 > review, retransmission, dissemination or other use of, or=20 > taking of any action in reliance upon this information by=20 > persons or entities other than the intended recipient is=20 > prohibited. If you received this in error, please contact the=20 > sender and delete the material from all computers. 117 >=20 >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 21 08:10:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWuSW-0000lF-Dh; Fri, 21 Apr 2006 08:10:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVz1G-00017M-QP; Tue, 18 Apr 2006 18:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVz1G-0002ci-A6; Tue, 18 Apr 2006 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k3IMo10e023132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Apr 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FVz1F-0005VC-O6; Tue, 18 Apr 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 18 Apr 2006 18:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-Mailman-Approved-At: Fri, 21 Apr 2006 08:09:59 -0400 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-security-threats-01.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: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Security Threats and Requirements for Emergency Call Marking and Mapping Author(s) : T. Taylor, et al. Filename : draft-ietf-ecrit-security-threats-01.txt Pages : 18 Date : 2006-4-18 This document reviews the security threats associated with the two current work items of the ECRIT Working Group. The first is the marking of signalling messages to indicate that they are related to an emergency. The second is the process of mapping from locations to Universal Resource Identifiers (URIs) pointing to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network. Based on the threats, this document establishes a set of security requirements for the the mapping protocol and for the handling of emergency-marked calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-security-threats-01.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-ietf-ecrit-security-threats-01.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-ietf-ecrit-security-threats-01.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-18150538.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-security-threats-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-security-threats-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-18150538.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From ecrit-bounces@ietf.org Fri Apr 21 08:10:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWuSW-0000lK-Ic; Fri, 21 Apr 2006 08:10:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWhyN-0003vp-QI; Thu, 20 Apr 2006 18:50:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWhyN-0003JB-OD; Thu, 20 Apr 2006 18:50:03 -0400 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FWhyM-0007Hj-CZ; Thu, 20 Apr 2006 18:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k3KMo2vP011171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Apr 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FWhyM-0003uF-1I; Thu, 20 Apr 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 20 Apr 2006 18:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-Mailman-Approved-At: Fri, 21 Apr 2006 08:09:59 -0400 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-requirements-07.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: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Requirements for Emergency Context Resolution with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-07.txt Pages : 30 Date : 2006-4-20 This document enumerates requirements for the context resolution of 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-ietf-ecrit-requirements-07.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-ietf-ecrit-requirements-07.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-ietf-ecrit-requirements-07.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-20160435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-requirements-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-requirements-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-20160435.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From ecrit-bounces@ietf.org Mon Apr 24 13:20:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY4j8-0007lg-IC; Mon, 24 Apr 2006 13:19:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY4j8-0007lX-AH for ecrit@ietf.org; Mon, 24 Apr 2006 13:19:58 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FY4il-0006g9-6Y for ecrit@ietf.org; Mon, 24 Apr 2006 13:19:37 -0400 Received: (qmail invoked by alias); 24 Apr 2006 17:19:21 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp040) with SMTP; 24 Apr 2006 19:19:21 +0200 X-Authenticated: #29516787 Message-ID: <444D0895.6090705@gmx.net> Date: Mon, 24 Apr 2006 19:19:17 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ecrit@ietf.org Subject: Re: [Ecrit] WGLC for "Security Threats and Requirements for Emergency Call Marking and Mapping" References: <4443A5BE.3000004@gmx.net> <4443BDA3.4000107@gmx.net> In-Reply-To: <4443BDA3.4000107@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: ecrit-bounces@ietf.org Reminder: Please review the document! Hannes Tschofenig wrote: > Hi all, > > we are now starting the Working Group Last Call on > the "Security Threats and Requirements for Emergency Call Marking and > Mapping" document. Here is the URL: > > http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-security-threats-01.txt > (The draft should appear in the archive very soon.) > > The WGLC will end on April 28th, 2006. Please review > this document and post your review results to the list (even if > you found no complaints). > > Ciao > Hannes & Marc > > _______________________________________________ > 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 Apr 24 14:37:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5wL-0001lP-DM; Mon, 24 Apr 2006 14:37:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5wK-0001lK-Ai for ecrit@ietf.org; Mon, 24 Apr 2006 14:37:40 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FY5wH-0002Yn-R8 for ecrit@ietf.org; Mon, 24 Apr 2006 14:37:40 -0400 Received: (qmail invoked by alias); 24 Apr 2006 18:37:36 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp043) with SMTP; 24 Apr 2006 20:37:36 +0200 X-Authenticated: #29516787 Message-ID: <444D1AED.2070306@gmx.net> Date: Mon, 24 Apr 2006 20:37:33 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ecrit@ietf.org Subject: Re: [Ecrit] WGLC for "Security Threats and Requirements for Emergency Call Marking and Mapping" References: <4443A5BE.3000004@gmx.net> <4443BDA3.4000107@gmx.net> In-Reply-To: <4443BDA3.4000107@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: ecrit-bounces@ietf.org Reminder: Please review the document! Hannes Tschofenig wrote: > Hi all, > > we are now starting the Working Group Last Call on > the "Security Threats and Requirements for Emergency Call Marking and > Mapping" document. Here is the URL: > > http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-security-threats-01.txt > (The draft should appear in the archive very soon.) > > The WGLC will end on April 28th, 2006. Please review > this document and post your review results to the list (even if > you found no complaints). > > Ciao > Hannes & Marc > > _______________________________________________ > 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 Apr 28 10:38:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZU6u-00074n-Vf; Fri, 28 Apr 2006 10:38:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZU6t-00074i-Mm for ecrit@ietf.org; Fri, 28 Apr 2006 10:38:19 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZU6t-0005oz-Ew for ecrit@ietf.org; Fri, 28 Apr 2006 10:38:19 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k3SEcHLt010294 for ; Fri, 28 Apr 2006 09:38:18 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 28 Apr 2006 15:38:17 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB012B60E42@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: ecrit@ietf.org Date: Fri, 28 Apr 2006 15:38:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Ecrit] Comments on draft-ietf-ecrit-service-urn-02 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: , Errors-To: ecrit-bounces@ietf.org I have been rereading draft-ietf-ecrit-service-urn-02 and have at least one major comment: Section 4.3 describes the "sos" service type as: The 'sos' service type describes emergency services and services related to public safety and health, typically offered by various branches of the government or other public institutions. Additional sub-services can be added after expert review and should be of general public interest. The general dictionary definition of "SOS" is the the international call of distress in morse and carries with it therefore requirements for immediate assistance rather than information provision. In the case of emergency calls, the UK government currently spends large sums of money in trying to educate the public that the "999" service is for emergencies only, and I think we are adding to that confusion by using "sos" to apparently cover both immediate response and non-immediate response services. This is made worse because presumably when a subtype is not supported in a particular locality, I assume the call would be routed to the general "sos" answer point, which certainly in the UK would be the current "999" service. I can assure you that any non-urgent request to such services in the UK ends up with a minimum of a verbal warning. Therefore in section 4.3 I consider that we should clearly state that "sos" is only for emergency or immediate response services, and all the subtype definitions should be rewritten where they do not clearly state that intent. Further the "sos" type implies some level of priority in treatment of the call, and it appears to me inappropriate that such priority should be given to a non-urgent request. Thus the current definition of: urn:service:sos.animal-control Animal control is defined as control of dogs, cats, and domesticated or undomesticated animals. needs to reflect something more dangerous or life threatening that stray cats or dogs, or general problems with wasp nests. Similarly: urn:service:sos.mental-health The 'mental-health' service refers to the "Diagnostic, treatment, and preventive care that helps improve how persons with mental illness feel both physically and emotionally as well as how they interact with other persons." (U.S. Department of Health and Human Services) again needs to reflect some need for immediate assistance with a psychological disorder, rather than just a long term counselling service. Further the allocation of further values needs to reflect more criteria for the allocation of values. Presumably new values end up being allocated by expert review (allocation of the IANA request to one of a set of designated experts), rather than by reference back to the WG. I consider "of general public interest" an insufficient definition to conduct that review. I would suggest it - needs to include a review of impact of world wide usage in different cultures, - whether such services are generally provided worldwide in a similar fashion (because these urns are meant to support roaming users who expect the same degree of support when they roam). - the type of response required to the request. In general public information services and other public advice lines probably need to be given a separate type and subtypes, assuming we need well known international identifiers for these at all. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 28 10:56:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZUOr-0004ui-7V; Fri, 28 Apr 2006 10:56:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZUOq-0004ud-O1 for ecrit@ietf.org; Fri, 28 Apr 2006 10:56:52 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZUOo-0006mT-CN for ecrit@ietf.org; Fri, 28 Apr 2006 10:56:52 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTPœ id k3SEum1X010977Fri, 28 Apr 2006 14:56:48 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1FZUOm-000J5s-00; Fri, 28 Apr 2006 15:56:48 +0100 Date: Fri, 28 Apr 2006 15:56:48 +0100 From: "Clive D.W. Feather" To: "Drage, Keith (Keith)" Subject: Re: [Ecrit] Comments on draft-ietf-ecrit-service-urn-02 Message-ID: <20060428145647.GD68462@finch-staff-1.thus.net> References: <475FF955A05DD411980D00508B6D5FB012B60E42@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475FF955A05DD411980D00508B6D5FB012B60E42@en0033exch001u.uk.lucent.com> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: ecrit-bounces@ietf.org Drage, Keith (Keith) said: > In the case of emergency calls, the UK government currently spends large sums of money in trying to educate the public that the "999" service is for emergencies only, and I think we are adding to that confusion by using "sos" to apparently cover both immediate response and non-immediate response services. The UK is about to introduce a new number 101 for *NON*-emergency situations. > urn:service:sos.animal-control Animal control is defined as control > of dogs, cats, and domesticated or undomesticated animals. > > urn:service:sos.mental-health The 'mental-health' service refers to > the "Diagnostic, treatment, and preventive care that helps improve > how persons with mental illness feel both physically and > emotionally as well as how they interact with other persons." Would both be reasons to call 101, as would reporting graffiti in a public place. I would not expect any of these to be treated as an emergency (and the interconnect arrangements for 101 reflect this; there is no special handling of the call). -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 28 11:10:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZUbb-0005Ti-D2; Fri, 28 Apr 2006 11:10:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZUbZ-0005TT-Bj for ecrit@ietf.org; Fri, 28 Apr 2006 11:10:01 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZUbZ-0007Vs-0a for ecrit@ietf.org; Fri, 28 Apr 2006 11:10:01 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Apr 2006 11:10:00 -0400 X-IronPort-AV: i="4.04,164,1144036800"; d="scan'208"; a="87446986:sNHT1031437420" 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 k3SF9xTN027008; Fri, 28 Apr 2006 11:09:59 -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, 28 Apr 2006 11:09:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Comments on draft-ietf-ecrit-service-urn-02 Date: Fri, 28 Apr 2006 11:09:58 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301642076@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on draft-ietf-ecrit-service-urn-02 Thread-Index: AcZq0Xnt2zl6TQ1XQ3CipMJFm9KRRAAA2pxg From: "Michael Hammer \(mhammer\)" To: "Drage, Keith \(Keith\)" , X-OriginalArrivalTime: 28 Apr 2006 15:09:59.0825 (UTC) FILETIME=[D1462010:01C66AD5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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: , Errors-To: ecrit-bounces@ietf.org Keith, Real examples from the US: Coyotes have been sited in major urban areas. See the recent Washington Post article (Sunday edition) for more details on that. Black bears have also been found in residential neighborhoods. Also, I know from living in Europe that dogs tend to be rather tame and well-heeled, but in the U.S. there are issues with people who train dogs for fighting (google on pit bulls, a much maligned breed) and the number of maulings. Perhaps you hadn't heard of those cases where people had been killed by such. As for mental health, it may be a question of whether someone is suicidal and plans to jump off a building. But, there I don't know whether you call the fire dept. and leave the therapy to the couch afterwards. Mike > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 > Sent: Friday, April 28, 2006 10:38 AM > To: ecrit@ietf.org > Subject: [Ecrit] Comments on draft-ietf-ecrit-service-urn-02 >=20 > I have been rereading draft-ietf-ecrit-service-urn-02 and=20 > have at least one major comment: >=20 > Section 4.3 describes the "sos" service type as: >=20 > The 'sos' service type describes emergency services and services > related to public safety and health, typically offered by various > branches of the government or other public institutions. =20 > Additional > sub-services can be added after expert review and should be of > general public interest. >=20 > The general dictionary definition of "SOS" is the the=20 > international call of distress in morse and carries with it=20 > therefore requirements for immediate assistance rather than=20 > information provision.=20 >=20 > In the case of emergency calls, the UK government currently=20 > spends large sums of money in trying to educate the public=20 > that the "999" service is for emergencies only, and I think=20 > we are adding to that confusion by using "sos" to apparently=20 > cover both immediate response and non-immediate response services. >=20 > This is made worse because presumably when a subtype is not=20 > supported in a particular locality, I assume the call would=20 > be routed to the general "sos" answer point, which certainly=20 > in the UK would be the current "999" service. I can assure=20 > you that any non-urgent request to such services in the UK=20 > ends up with a minimum of a verbal warning. >=20 > Therefore in section 4.3 I consider that we should clearly=20 > state that "sos" is only for emergency or immediate response=20 > services, and all the subtype definitions should be rewritten=20 > where they do not clearly state that intent. >=20 > Further the "sos" type implies some level of priority in=20 > treatment of the call, and it appears to me inappropriate=20 > that such priority should be given to a non-urgent request. >=20 > Thus the current definition of:=20 >=20 > urn:service:sos.animal-control Animal control is defined as control > of dogs, cats, and domesticated or undomesticated animals. >=20 > needs to reflect something more dangerous or life threatening=20 > that stray cats or dogs, or general problems with wasp nests. >=20 > Similarly: >=20 > urn:service:sos.mental-health The 'mental-health' service refers to > the "Diagnostic, treatment, and preventive care that=20 > helps improve > how persons with mental illness feel both physically and > emotionally as well as how they interact with other persons." > (U.S. Department of Health and Human Services) >=20 > again needs to reflect some need for immediate assistance=20 > with a psychological disorder, rather than just a long term=20 > counselling service. >=20 > Further the allocation of further values needs to reflect=20 > more criteria for the allocation of values. Presumably new=20 > values end up being allocated by expert review (allocation of=20 > the IANA request to one of a set of designated experts),=20 > rather than by reference back to the WG. I consider "of=20 > general public interest" an insufficient definition to=20 > conduct that review. I would suggest it=20 >=20 > - needs to include a review of impact of world wide usage=20 > in different cultures,=20 >=20 > - whether such services are generally provided worldwide=20 > in a similar fashion (because these urns are meant to support=20 > roaming users who expect the same degree of support when they roam). >=20 > - the type of response required to the request.=20 >=20 > In general public information services and other public=20 > advice lines probably need to be given a separate type and=20 > subtypes, assuming we need well known international=20 > identifiers for these at all. >=20 > regards >=20 > Keith=20 >=20 > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 >=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 Apr 28 11:14:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZUfX-0007a1-9Z; Fri, 28 Apr 2006 11:14:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZUfW-0007Zw-P9 for ecrit@ietf.org; Fri, 28 Apr 2006 11:14:06 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZUfV-0007nh-Da for ecrit@ietf.org; Fri, 28 Apr 2006 11:14:06 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTPœ id k3SFE27k019678Fri, 28 Apr 2006 15:14:03 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1FZUfS-000JQa-00; Fri, 28 Apr 2006 16:14:02 +0100 Date: Fri, 28 Apr 2006 16:14:02 +0100 From: "Clive D.W. Feather" To: "Michael Hammer (mhammer)" Subject: Re: [Ecrit] Comments on draft-ietf-ecrit-service-urn-02 Message-ID: <20060428151402.GH68462@finch-staff-1.thus.net> References: <072C5B76F7CEAB488172C6F64B30B5E301642076@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301642076@xmb-rtp-20b.amer.cisco.com> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: , Errors-To: ecrit-bounces@ietf.org Michael Hammer (mhammer) said: > Real examples from the US: > > Coyotes have been sited in major urban areas. See the recent Washington > Post article (Sunday edition) for more details on that. > > Black bears have also been found in residential neighborhoods. If they're a public danger, that's a 999 call. Otherwise it's Environmental Health (local government, will be reachable via 101). > Also, I know from living in Europe that dogs tend to be rather tame and > well-heeled, but in the U.S. there are issues with people who train dogs > for fighting (google on pit bulls, a much maligned breed) and the number > of maulings. Perhaps you hadn't heard of those cases where people had > been killed by such. They have happened here as well. But Keith's comment: >> urn:service:sos.animal-control Animal control is defined as control >> of dogs, cats, and domesticated or undomesticated animals. >> >> needs to reflect something more dangerous or life threatening >> that stray cats or dogs, or general problems with wasp nests. remains completely true. "sos.violent-animal" might be a reasonable name, but "animal-control" suggests a cat stuck up a tree. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 28 11:56:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVKh-0002N8-N7; Fri, 28 Apr 2006 11:56:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVKg-0002N3-Nb for ecrit@ietf.org; Fri, 28 Apr 2006 11:56:38 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZVKf-0001R5-Fj for ecrit@ietf.org; Fri, 28 Apr 2006 11:56:38 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Apr 2006 11:56:37 -0400 X-IronPort-AV: i="4.04,164,1144036800"; d="scan'208"; a="87450912:sNHT33198048" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3SFubTL005825; Fri, 28 Apr 2006 11:56:37 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Apr 2006 11:56:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Comments on draft-ietf-ecrit-service-urn-02 Date: Fri, 28 Apr 2006 11:56:35 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3016420AC@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on draft-ietf-ecrit-service-urn-02 Thread-Index: AcZq1mtOZUpd9BYURNu8ceWZfSLHvwABYpEA From: "Michael Hammer \(mhammer\)" To: "Clive D.W. Feather" X-OriginalArrivalTime: 28 Apr 2006 15:56:36.0974 (UTC) FILETIME=[548130E0:01C66ADC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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: , Errors-To: ecrit-bounces@ietf.org Clive, Agree, as written doesn't justify. But, it is a judgment call. =20 Depends on how hungry you think the bear is. Also, if the cat happens to be a cougar (example from San Diego) again your call. Mike =20 > -----Original Message----- > From: Clive D.W. Feather [mailto:clive@demon.net]=20 > Sent: Friday, April 28, 2006 11:14 AM > To: Michael Hammer (mhammer) > Cc: Drage, Keith (Keith); ecrit@ietf.org > Subject: Re: [Ecrit] Comments on draft-ietf-ecrit-service-urn-02 >=20 > Michael Hammer (mhammer) said: > > Real examples from the US: > >=20 > > Coyotes have been sited in major urban areas. See the recent=20 > > Washington Post article (Sunday edition) for more details on that. > >=20 > > Black bears have also been found in residential neighborhoods. >=20 > If they're a public danger, that's a 999 call. Otherwise it's=20 > Environmental Health (local government, will be reachable via 101). >=20 > > Also, I know from living in Europe that dogs tend to be rather tame=20 > > and well-heeled, but in the U.S. there are issues with people who=20 > > train dogs for fighting (google on pit bulls, a much=20 > maligned breed)=20 > > and the number of maulings. Perhaps you hadn't heard of=20 > those cases=20 > > where people had been killed by such. >=20 > They have happened here as well. But Keith's comment: >=20 > >> urn:service:sos.animal-control Animal control is=20 > defined as control > >> of dogs, cats, and domesticated or undomesticated animals. > >>=20 > >> needs to reflect something more dangerous or life threatening that=20 > >> stray cats or dogs, or general problems with wasp nests. >=20 > remains completely true. "sos.violent-animal" might be a=20 > reasonable name, but "animal-control" suggests a cat stuck up a tree. >=20 > --=20 > Clive D.W. Feather | Work: | Tel: =20 > +44 20 8495 6138 > Internet Expert | Home: | Fax: =20 > +44 870 051 9937 > Demon Internet | WWW: http://www.davros.org | Mobile:=20 > +44 7973 377646 > THUS plc | | >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 28 12:33:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVuI-0005XG-TC; Fri, 28 Apr 2006 12:33:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVuH-0005VR-8f for ecrit@ietf.org; Fri, 28 Apr 2006 12:33:25 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZVuE-0004Kp-TV for ecrit@ietf.org; Fri, 28 Apr 2006 12:33:25 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FZVu7-0008Ua-Ry; Fri, 28 Apr 2006 11:33:16 -0500 From: "Brian Rosen" To: "'Drage, Keith \(Keith\)'" , Subject: RE: [Ecrit] Comments on draft-ietf-ecrit-service-urn-02 Date: Fri, 28 Apr 2006 12:33:17 -0400 Message-ID: <0a8301c66ae1$761f5ab0$6901a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <475FF955A05DD411980D00508B6D5FB012B60E42@en0033exch001u.uk.lucent.com> Thread-Index: AcZq0W08pX3qmmxYR/uS4IAxkcZOuAAD7KDw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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: , Errors-To: ecrit-bounces@ietf.org In the U.S., we are now deploying "3-1-1" for local government non-emergency services and "2-1-1" for human services (both government and non-government). I'd support changes as proposed. I'd even like to see a "non-emergency-help" service type with at least "local-government" and "human-services" as subtypes, but we could wait on that. Brian -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Friday, April 28, 2006 10:38 AM To: ecrit@ietf.org Subject: [Ecrit] Comments on draft-ietf-ecrit-service-urn-02 I have been rereading draft-ietf-ecrit-service-urn-02 and have at least one major comment: Section 4.3 describes the "sos" service type as: The 'sos' service type describes emergency services and services related to public safety and health, typically offered by various branches of the government or other public institutions. Additional sub-services can be added after expert review and should be of general public interest. The general dictionary definition of "SOS" is the the international call of distress in morse and carries with it therefore requirements for immediate assistance rather than information provision. In the case of emergency calls, the UK government currently spends large sums of money in trying to educate the public that the "999" service is for emergencies only, and I think we are adding to that confusion by using "sos" to apparently cover both immediate response and non-immediate response services. This is made worse because presumably when a subtype is not supported in a particular locality, I assume the call would be routed to the general "sos" answer point, which certainly in the UK would be the current "999" service. I can assure you that any non-urgent request to such services in the UK ends up with a minimum of a verbal warning. Therefore in section 4.3 I consider that we should clearly state that "sos" is only for emergency or immediate response services, and all the subtype definitions should be rewritten where they do not clearly state that intent. Further the "sos" type implies some level of priority in treatment of the call, and it appears to me inappropriate that such priority should be given to a non-urgent request. Thus the current definition of: urn:service:sos.animal-control Animal control is defined as control of dogs, cats, and domesticated or undomesticated animals. needs to reflect something more dangerous or life threatening that stray cats or dogs, or general problems with wasp nests. Similarly: urn:service:sos.mental-health The 'mental-health' service refers to the "Diagnostic, treatment, and preventive care that helps improve how persons with mental illness feel both physically and emotionally as well as how they interact with other persons." (U.S. Department of Health and Human Services) again needs to reflect some need for immediate assistance with a psychological disorder, rather than just a long term counselling service. Further the allocation of further values needs to reflect more criteria for the allocation of values. Presumably new values end up being allocated by expert review (allocation of the IANA request to one of a set of designated experts), rather than by reference back to the WG. I consider "of general public interest" an insufficient definition to conduct that review. I would suggest it - needs to include a review of impact of world wide usage in different cultures, - whether such services are generally provided worldwide in a similar fashion (because these urns are meant to support roaming users who expect the same degree of support when they roam). - the type of response required to the request. In general public information services and other public advice lines probably need to be given a separate type and subtypes, assuming we need well known international identifiers for these at all. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ 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 Apr 28 14:08:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXNm-0003s2-1r; Fri, 28 Apr 2006 14:07:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXNk-0003rw-QH for ecrit@ietf.org; Fri, 28 Apr 2006 14:07:56 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZXNj-0000wH-Fh for ecrit@ietf.org; Fri, 28 Apr 2006 14:07:56 -0400 Received: from lion.cs.columbia.edu (IDENT:2++F9sPBhNOa2M8zfQ5jubq3JVKj2aaF@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k3SI7KcL005300 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 28 Apr 2006 14:07:52 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k3SI7KjN012707 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 28 Apr 2006 14:07:20 -0400 Message-ID: <445259D3.9050307@cs.columbia.edu> Date: Fri, 28 Apr 2006 14:07:15 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Ecrit] Comments on draft-ietf-ecrit-service-urn-02 References: <475FF955A05DD411980D00508B6D5FB012B60E42@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB012B60E42@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P2 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_REPLY 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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: , Errors-To: ecrit-bounces@ietf.org I generally agree with your comments. The inclusion of animal control, in particular, was motivated by the usage in an American PSAP I visited, which has 'animal control' as one of their transfer destinations. I'm less certain about mental health; I suspect a suicide prevention hotline is the closest we could get to an emergency service and maybe it should be labeled as such. In general, almost all emergency services are used for less-urgent services as well. For example, the fire department often extracts cats from trees and the police department writes parking tickets or investigates shop lifting. Neither requires flashing blue lights and sirens. As to the term animal control, it appears to be, at least in the US, the established term for services that deal with both emergency, threat-of-life ("bear", "crocodile") and nuisance ("skunk") animal issues. See http://www.nacanet.org/ for the official association, as far as I can tell. Suggestions for naming the "211" and "311" services are welcome. urn:service:information is a bit too generic, but maybe urn:service:government and urn:service:social would be close enough. Henning Drage, Keith (Keith) wrote: > I have been rereading draft-ietf-ecrit-service-urn-02 and have at least one major comment: > > Section 4.3 describes the "sos" service type as: > > The 'sos' service type describes emergency services and services > related to public safety and health, typically offered by various > branches of the government or other public institutions. Additional > sub-services can be added after expert review and should be of > general public interest. > > The general dictionary definition of "SOS" is the the international call of distress in morse and carries with it therefore requirements for immediate assistance rather than information provision. > > In the case of emergency calls, the UK government currently spends large sums of money in trying to educate the public that the "999" service is for emergencies only, and I think we are adding to that confusion by using "sos" to apparently cover both immediate response and non-immediate response services. > > This is made worse because presumably when a subtype is not supported in a particular locality, I assume the call would be routed to the general "sos" answer point, which certainly in the UK would be the current "999" service. I can assure you that any non-urgent request to such services in the UK ends up with a minimum of a verbal warning. > > Therefore in section 4.3 I consider that we should clearly state that "sos" is only for emergency or immediate response services, and all the subtype definitions should be rewritten where they do not clearly state that intent. > > Further the "sos" type implies some level of priority in treatment of the call, and it appears to me inappropriate that such priority should be given to a non-urgent request. > > Thus the current definition of: > > urn:service:sos.animal-control Animal control is defined as control > of dogs, cats, and domesticated or undomesticated animals. > > needs to reflect something more dangerous or life threatening that stray cats or dogs, or general problems with wasp nests. > > Similarly: > > urn:service:sos.mental-health The 'mental-health' service refers to > the "Diagnostic, treatment, and preventive care that helps improve > how persons with mental illness feel both physically and > emotionally as well as how they interact with other persons." > (U.S. Department of Health and Human Services) > > again needs to reflect some need for immediate assistance with a psychological disorder, rather than just a long term counselling service. > > Further the allocation of further values needs to reflect more criteria for the allocation of values. Presumably new values end up being allocated by expert review (allocation of the IANA request to one of a set of designated experts), rather than by reference back to the WG. I consider "of general public interest" an insufficient definition to conduct that review. I would suggest it > > - needs to include a review of impact of world wide usage in different cultures, > > - whether such services are generally provided worldwide in a similar fashion (because these urns are meant to support roaming users who expect the same degree of support when they roam). > > - the type of response required to the request. > > In general public information services and other public advice lines probably need to be given a separate type and subtypes, assuming we need well known international identifiers for these at all. > > regards > > Keith > > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 > > _______________________________________________ > 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 Apr 29 20:15:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZzaV-0008QJ-5I; Sat, 29 Apr 2006 20:14:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZzaU-0008QE-DX for ecrit@ietf.org; Sat, 29 Apr 2006 20:14:58 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZzaT-0001n0-0o for ecrit@ietf.org; Sat, 29 Apr 2006 20:14:58 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k3U0Eko0009575; Sat, 29 Apr 2006 19:14:46 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 30 Apr 2006 01:14:46 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB012B60F02@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Henning Schulzrinne'" , "'Drage, Keith (Keith)'" Subject: RE: [Ecrit] Comments on draft-ietf-ecrit-service-urn-02 Date: Sun, 30 Apr 2006 01:14:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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: , Errors-To: ecrit-bounces@ietf.org See inline below: And one further question. I have assumed that for the emergency type "sos" in the absence of the subtype, it would still be routed to a PSAP even when subtypes are generally in use. Similarly if an unknown subtype is used, it should still get routed to a PSAP. Which draft is going to include the requirement to do this? regards Keith > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 28 April 2006 19:07 > To: Drage, Keith (Keith) > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Comments on draft-ietf-ecrit-service-urn-02 > > > I generally agree with your comments. The inclusion of animal > control, > in particular, was motivated by the usage in an American PSAP > I visited, > which has 'animal control' as one of their transfer destinations. > > I'm less certain about mental health; I suspect a suicide prevention > hotline is the closest we could get to an emergency service > and maybe it > should be labeled as such. > We already have the suicide prevention listed as a separate subtype: " urn:service:sos.suicide The 'suicide' service refers to the suicide prevention hotline." > In general, almost all emergency services are used for less-urgent > services as well. For example, the fire department often > extracts cats > from trees and the police department writes parking tickets or > investigates shop lifting. Neither requires flashing blue > lights and sirens. > > As to the term animal control, it appears to be, at least in > the US, the > established term for services that deal with both emergency, > threat-of-life ("bear", "crocodile") and nuisance ("skunk") animal > issues. See http://www.nacanet.org/ for the official > association, as far > as I can tell. > > Suggestions for naming the "211" and "311" services are welcome. > urn:service:information is a bit too generic, but maybe > urn:service:government and urn:service:social would be close enough. > I cannot make up my mind as to whether these should go in this draft, or in a later draft: - the pro for putting them in this draft is that it will help to contrast the distinction between the emergency type "sos" and the other public service type. - the con is that we need to identify a scope for the public service type, and the perceived scope in different countries is going to vary much more drastically than that for emergency services, and therefore possibly take significant time to resolve. In some countries "pest control" may be a commercial service, and in others a service provided by local government. Counselling services may be provided by registered charities or by national government. Do we exclude those services that may be provided for commercial gain? What happens if the subtype is missing; does it get routed to a default information centre? In the USA, we seem to have two types, the UK is proposing only one; what are other countries round the world planning? > Henning > > Drage, Keith (Keith) wrote: > > I have been rereading draft-ietf-ecrit-service-urn-02 and > have at least one major comment: > > > > Section 4.3 describes the "sos" service type as: > > > > The 'sos' service type describes emergency services and services > > related to public safety and health, typically offered by various > > branches of the government or other public institutions. > Additional > > sub-services can be added after expert review and should be of > > general public interest. > > > > The general dictionary definition of "SOS" is the the > international call of distress in morse and carries with it > therefore requirements for immediate assistance rather than > information provision. > > > > In the case of emergency calls, the UK government currently > spends large sums of money in trying to educate the public > that the "999" service is for emergencies only, and I think > we are adding to that confusion by using "sos" to apparently > cover both immediate response and non-immediate response services. > > > > This is made worse because presumably when a subtype is not > supported in a particular locality, I assume the call would > be routed to the general "sos" answer point, which certainly > in the UK would be the current "999" service. I can assure > you that any non-urgent request to such services in the UK > ends up with a minimum of a verbal warning. > > > > Therefore in section 4.3 I consider that we should clearly > state that "sos" is only for emergency or immediate response > services, and all the subtype definitions should be rewritten > where they do not clearly state that intent. > > > > Further the "sos" type implies some level of priority in > treatment of the call, and it appears to me inappropriate > that such priority should be given to a non-urgent request. > > > > Thus the current definition of: > > > > urn:service:sos.animal-control Animal control is defined > as control > > of dogs, cats, and domesticated or undomesticated animals. > > > > needs to reflect something more dangerous or life > threatening that stray cats or dogs, or general problems with > wasp nests. > > > > Similarly: > > > > urn:service:sos.mental-health The 'mental-health' > service refers to > > the "Diagnostic, treatment, and preventive care that > helps improve > > how persons with mental illness feel both physically and > > emotionally as well as how they interact with other persons." > > (U.S. Department of Health and Human Services) > > > > again needs to reflect some need for immediate assistance > with a psychological disorder, rather than just a long term > counselling service. > > > > Further the allocation of further values needs to reflect > more criteria for the allocation of values. Presumably new > values end up being allocated by expert review (allocation of > the IANA request to one of a set of designated experts), > rather than by reference back to the WG. I consider "of > general public interest" an insufficient definition to > conduct that review. I would suggest it > > > > - needs to include a review of impact of world wide usage > in different cultures, > > > > - whether such services are generally provided worldwide > in a similar fashion (because these urns are meant to support > roaming users who expect the same degree of support when they roam). > > > > - the type of response required to the request. > > > > In general public information services and other public > advice lines probably need to be given a separate type and > subtypes, assuming we need well known international > identifiers for these at all. > > > > regards > > > > Keith > > > > Keith Drage > > Lucent Technologies > > drage@lucent.com > > tel: +44 1793 776249 > > > > _______________________________________________ > > 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 Apr 29 21:02:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fa0K9-0007CK-Rx; Sat, 29 Apr 2006 21:02:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fa0K8-0007C0-OM for ecrit@ietf.org; Sat, 29 Apr 2006 21:02:08 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fa0K8-0003a2-Gz for ecrit@ietf.org; Sat, 29 Apr 2006 21:02:08 -0400 Received: from [192.168.0.41] (pool-138-89-20-236.mad.east.verizon.net [138.89.20.236]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3U127hm017431 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 29 Apr 2006 21:02:07 -0400 (EDT) In-Reply-To: <475FF955A05DD411980D00508B6D5FB012B60F02@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB012B60F02@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <91D3BFDE-53AD-4D37-A9A6-02029CBD3C90@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Comments on draft-ietf-ecrit-service-urn-02 Date: Sat, 29 Apr 2006 21:02:06 -0400 To: "Drage, Keith (Keith)" X-Mailer: Apple Mail (2.749.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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: , Errors-To: ecrit-bounces@ietf.org On Apr 29, 2006, at 8:14 PM, Drage, Keith (Keith) wrote: > See inline below: > > And one further question. I have assumed that for the emergency > type "sos" in the absence of the subtype, it would still be routed > to a PSAP even when subtypes are generally in use. Similarly if an > unknown subtype is used, it should still get routed to a PSAP. > Which draft is going to include the requirement to do this? > This would be handled by the matching algorithm in LoST, but it probably doesn't hurt to describe this in general terms. The general notion is probably that a mapping protocol SHOULD always provide the non-subtyped service, which would be used for the two cases you mention. >> >> Suggestions for naming the "211" and "311" services are welcome. >> urn:service:information is a bit too generic, but maybe >> urn:service:government and urn:service:social would be close enough. >> > I cannot make up my mind as to whether these should go in this > draft, or in a later draft: > > - the pro for putting them in this draft is that it will help to > contrast the distinction between the emergency type "sos" and the > other public service type. > > - the con is that we need to identify a scope for the public > service type, and the perceived scope in different countries is > going to vary much more drastically than that for emergency > services, and therefore possibly take significant time to resolve. > In some countries "pest control" may be a commercial service, and > in others a service provided by local government. Counselling > services may be provided by registered charities or by national > government. Do we exclude those services that may be provided for > commercial gain? What happens if the subtype is missing; does it > get routed to a default information centre? In the USA, we seem to > have two types, the UK is proposing only one; what are other > countries round the world planning? > I think it is pretty hopeless to try to work with sub-services for these two, given the almost endless list of government services offered by developed countries. The "blue pages" in many US phone books list government services at a very high level and still can be dozens of pages long. The whole point of 211 and 311 is to have a human or other context-aware entity determine what service the caller actually needs. The issues that make sub-services necessary in 911 seem to be absent in those new services. As I mentioned in the discussion on various police functions, I don't think the service URN is a substitute for a directory service, be it a human, an "A-Z" listing, a FAQ or query-based. Thus, my suggestion would be to simply define two top-level services, 'government' and 'social', and leave it at that for the time being. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 29 21:25:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fa0gZ-0006aO-La; Sat, 29 Apr 2006 21:25:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fa0gY-0006aJ-Se for ecrit@ietf.org; Sat, 29 Apr 2006 21:25:18 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fa0gX-0004eF-Gw for ecrit@ietf.org; Sat, 29 Apr 2006 21:25:18 -0400 Received: from [192.168.0.41] (pool-138-89-20-236.mad.east.verizon.net [138.89.20.236]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3U1PFFn005988 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 29 Apr 2006 21:25:16 -0400 (EDT) In-Reply-To: <475FF955A05DD411980D00508B6D5FB012B60E42@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB012B60E42@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Comments on draft-ietf-ecrit-service-urn-02 Date: Sat, 29 Apr 2006 21:25:16 -0400 To: "Drage, Keith (Keith)" X-Mailer: Apple Mail (2.749.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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: , Errors-To: ecrit-bounces@ietf.org I've updated some of the draft text in my working draft at http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service- urn-03.html Let me know if that addresses your concerns. On Apr 28, 2006, at 10:38 AM, Drage, Keith (Keith) wrote: > I have been rereading draft-ietf-ecrit-service-urn-02 and have at > least one major comment: > > Section 4.3 describes the "sos" service type as: > > The 'sos' service type describes emergency services and services > related to public safety and health, typically offered by various > branches of the government or other public institutions. > Additional > sub-services can be added after expert review and should be of > general public interest. > > The general dictionary definition of "SOS" is the the international > call of distress in morse and carries with it therefore > requirements for immediate assistance rather than information > provision. > > In the case of emergency calls, the UK government currently spends > large sums of money in trying to educate the public that the "999" > service is for emergencies only, and I think we are adding to that > confusion by using "sos" to apparently cover both immediate > response and non-immediate response services. > > This is made worse because presumably when a subtype is not > supported in a particular locality, I assume the call would be > routed to the general "sos" answer point, which certainly in the UK > would be the current "999" service. I can assure you that any non- > urgent request to such services in the UK ends up with a minimum of > a verbal warning. > > Therefore in section 4.3 I consider that we should clearly state > that "sos" is only for emergency or immediate response services, > and all the subtype definitions should be rewritten where they do > not clearly state that intent. > > Further the "sos" type implies some level of priority in treatment > of the call, and it appears to me inappropriate that such priority > should be given to a non-urgent request. > > Thus the current definition of: > > urn:service:sos.animal-control Animal control is defined as control > of dogs, cats, and domesticated or undomesticated animals. > > needs to reflect something more dangerous or life threatening that > stray cats or dogs, or general problems with wasp nests. > > Similarly: > > urn:service:sos.mental-health The 'mental-health' service refers to > the "Diagnostic, treatment, and preventive care that helps > improve > how persons with mental illness feel both physically and > emotionally as well as how they interact with other persons." > (U.S. Department of Health and Human Services) > > again needs to reflect some need for immediate assistance with a > psychological disorder, rather than just a long term counselling > service. > > Further the allocation of further values needs to reflect more > criteria for the allocation of values. Presumably new values end up > being allocated by expert review (allocation of the IANA request to > one of a set of designated experts), rather than by reference back > to the WG. I consider "of general public interest" an insufficient > definition to conduct that review. I would suggest it > > - needs to include a review of impact of world wide usage in > different cultures, > > - whether such services are generally provided worldwide in a > similar fashion (because these urns are meant to support roaming > users who expect the same degree of support when they roam). > > - the type of response required to the request. > > In general public information services and other public advice > lines probably need to be given a separate type and subtypes, > assuming we need well known international identifiers for these at > all. > > regards > > Keith > > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 > > _______________________________________________ > 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