From ecrit-bounces@ietf.org Tue Nov 01 11:58:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWzSn-0005Y4-IZ; Tue, 01 Nov 2005 11:58:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWzSn-0005Xi-27 for ecrit@megatron.ietf.org; Tue, 01 Nov 2005 11:58:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01977 for ; Tue, 1 Nov 2005 11:58:00 -0500 (EST) Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWzhC-0006yo-7j for ecrit@ietf.org; Tue, 01 Nov 2005 12:13:15 -0500 Received: from [10.0.1.103] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 01 Nov 2005 11:57:54 -0500 id 01588030.43679E92.000031A7 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Andrew Newton Date: Tue, 1 Nov 2005 11:57:59 -0500 X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: [Ecrit] comments on draft-schulzrinne-ecrit-mapping-arch-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Having read draft-schulzrinne-ecrit-mapping-arch-00, here are my comments: 1) Overall, this draft does a good job laying out a very specific mapping data distribution architecture. I think it is worth noting this architecture as some may find it useful. However, I can see how some people will view it as too many moving parts and may want something simpler. 2) I think the reference to DNS in the abstract should be stricken as the architecture described sounds like a lot more than DNS. 3) I really like the definition of "seeker". So much so, that something similar ought to be added to the ECRIT requirements document. It is basically a term that says, "there are multiple types of nodes that may initiate these queries, and we call all such nodes conducting this function a 'seeker'". 4) Section 3.1 says that LCMS services requires distributed services. I disagree with that. It could certainly be done in a centralized manner, and I suspect that some parts of the world will adopt a centralized system. 5) It is probably worth mentioning that the protocol between the seeker and the resolver may not be the same as the protocol between the forest guides and the other architecture elements, as it would make no sense to impose upon the seeker the mesh semantics. 6) There is no discussion about how geospatial coordinates are used in this hierarchical system, or rather how they are mapped into the system. 7) Section 8 seems to be on an entirely different subject. Perhaps it should be broken out into its own draft. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 03 16:47:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXmvE-0004d9-26; Thu, 03 Nov 2005 16:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXmvC-0004d1-Q0 for ecrit@megatron.ietf.org; Thu, 03 Nov 2005 16:46:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28590 for ; Thu, 3 Nov 2005 16:46:35 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXnA4-0005Q8-Pt for ecrit@ietf.org; Thu, 03 Nov 2005 17:02:21 -0500 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jA3LkaWk029012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Nov 2005 16:46:52 -0500 (EST) Message-ID: <436A84F3.70206@cs.columbia.edu> Date: Thu, 03 Nov 2005 16:45:23 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] comments on draft-schulzrinne-ecrit-mapping-arch-00 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: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7bit Cc: 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andrew Newton wrote: > Having read draft-schulzrinne-ecrit-mapping-arch-00, here are my comments: Andrew, thanks for taking the time to read the draft. Many of your points deserve a fuller response, but I wanted to get the discussion started. > > 1) Overall, this draft does a good job laying out a very specific > mapping data distribution architecture. I think it is worth noting > this architecture as some may find it useful. However, I can see how > some people will view it as too many moving parts and may want > something simpler. I'm all for simplicity, but I believe we need to deal with the real-world issue that information about mappings is naturally distributed and owned by a variety of parties that don't necessarily know about or trust each other. In some circumstances, you can simplify the system by combining the roles of resolvers and forest guides, for example. I'm certainly interested in simpler architectures, but I'm very wary of assuming, say, a single hierarchy or a single logical root. I'd rather deal with some technical complexity than inventing another ICANN or public ENUM. I'm also hoping that the implementation complexity is modest. I think you essentially need two or three message types between the various components. > > 2) I think the reference to DNS in the abstract should be stricken as > the architecture described sounds like a lot more than DNS. It's the closest analogy I could think of. No analogy is perfect, but there are clear similarities: - hierarchical, with distributed ownership of data - caching resolvers at the edge - notions of forwarding queries Besides the basic difference of not mapping name labels DNS-style, I think the major architectural difference is the absence of a small root. We don't have the technical limitations that force a small root server population (ignoring the current anycast approach). But maybe you could explain the "a lot more" part so that I can better understand your point. > > 3) I really like the definition of "seeker". So much so, that > something similar ought to be added to the ECRIT requirements > document. It is basically a term that says, "there are multiple types > of nodes that may initiate these queries, and we call all such nodes > conducting this function a 'seeker'". > > 4) Section 3.1 says that LCMS services requires distributed services. > I disagree with that. It could certainly be done in a centralized > manner, and I suspect that some parts of the world will adopt a > centralized system. Maybe we have a very different picture of how this would work, but unless we have a single centralized system for the whole world, you'd still have to find the various "centralized" systems for each country, depending on where you are. Cast in the terminology of my draft, this would mean that each country would have a tree consisting of one tree node, so this is just a special case. You'd then need a way to find these (short) trees. In other contexts, DNS has been suggested for that. But then you have to know which country you are in based on your GPS coordinates, and you then essentially get to run Brian's DNS system as well as the some other system, increasing the overall complexity (and still having to deal with the global root issue). Maybe you can suggest a way to automatically, without manual configuration, bootstrap a centralized system, as I'm probably just not seeing the simple solution you have in mind. > > 5) It is probably worth mentioning that the protocol between the seeker > and the resolver may not be the same as the protocol between the forest > guides and the other architecture elements, as it would make no sense > to impose upon the seeker the mesh semantics. I think I mention protocol diversity somewhere, but I'll check. My general perception is that since this is an international system, keeping the number of diverse protocols small is beneficial for simplicity and interoperability. I suspect that, in practice, we'll see implementations that can fulfill multiple roles (such as resolver, authoritative server and forest guide), just like we have generic DNS servers (e.g., BIND or for LDAP) today, as well as more specialized ones. > > 6) There is no discussion about how geospatial coordinates are used in > this hierarchical system, or rather how they are mapped into the system. This probably needs clarification, but the intent was that there is no special mechanism. Regions can be polygons or civic regions. A query for a point in geospatial coordinates is handed to a server, which finds the appropriate region and sends the query down that tree branch. If you find a particular place where the discussion only applies to civic coordinates and needs special treatment for geo, please let me know. No, I'm not trying to start another civic-vs.-geo discussion with this draft, although we're well overdue for an encore performance... > > 7) Section 8 seems to be on an entirely different subject. Perhaps it > should be broken out into its own draft. While this appears separate, I actually believe that it is essentially the same problem: map location to a (set of) URLs. Thus, I think the overall system complexity can be greatly reduced by integrating this information. That way, end systems make one query and get back both their local emergency numbers and their emergency contact, with the minimal complexity of one additional XML element in the response. I would hate to have to build a whole new architecture just for this one piece of relatively trivial location-dependent configuration information. > > -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 Fri Nov 04 13:15:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY66C-0001Ex-F4; Fri, 04 Nov 2005 13:15:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY66B-0001Eg-P5 for ecrit@megatron.ietf.org; Fri, 04 Nov 2005 13:15:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05309 for ; Fri, 4 Nov 2005 13:15:13 -0500 (EST) Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY6LE-0006Mh-LZ for ecrit@ietf.org; Fri, 04 Nov 2005 13:31:08 -0500 Received: from [10.0.1.103] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 04 Nov 2005 13:15:10 -0500 id 01588001.436BA52E.00002C9B In-Reply-To: <436A84F3.70206@cs.columbia.edu> References: <436A84F3.70206@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C73A92A-ED3D-4BC2-9B87-DD9EDF83C902@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] comments on draft-schulzrinne-ecrit-mapping-arch-00 Date: Fri, 4 Nov 2005 13:15:13 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Nov 3, 2005, at 4:45 PM, Henning Schulzrinne wrote: > I'm certainly interested in simpler architectures, but I'm very > wary of assuming, say, a single hierarchy or a single logical root. > I'd rather deal with some technical complexity than inventing > another ICANN or public ENUM. I agree completely with this. So I suspect that you and I are miscommunicating. >> 2) I think the reference to DNS in the abstract should be stricken >> as the architecture described sounds like a lot more than DNS. >> > > It's the closest analogy I could think of. No analogy is perfect, > but there are clear similarities: I think LDAP is a better analogy. > Besides the basic difference of not mapping name labels DNS-style, > I think the major architectural difference is the absence of a > small root. We don't have the technical limitations that force a > small root server population (ignoring the current anycast approach). That, and the forest guides. >> 4) Section 3.1 says that LCMS services requires distributed >> services. I disagree with that. It could certainly be done in a >> centralized manner, and I suspect that some parts of the world >> will adopt a centralized system. >> > > Maybe we have a very different picture of how this would work, but > unless we have a single centralized system for the whole world, > you'd still have to find the various "centralized" systems for each > country, depending on where you are. Not for the whole world, but I can certainly imagine smaller countries adopting for a nationwide centralized system. The whole notion of a highly decentralized system is only really relevant to the US. > Cast in the terminology of my draft, this would mean that each > country would have a tree consisting of one tree node, so this is > just a special case. You'd then need a way to find these (short) > trees. In other contexts, DNS has been suggested for that. But then > you have to know which country you are in based on your GPS > coordinates, and you then essentially get to run Brian's DNS system > as well as the some other system, increasing the overall complexity > (and still having to deal with the global root issue). > > Maybe you can suggest a way to automatically, without manual > configuration, bootstrap a centralized system, as I'm probably just > not seeing the simple solution you have in mind. Then I do not understand what you are proposing with this architecture. How are you bootstrapping the knowledge of the resolvers and the forest guides? >> 6) There is no discussion about how geospatial coordinates are >> used in this hierarchical system, or rather how they are mapped >> into the system. >> > > This probably needs clarification, but the intent was that there is > no special mechanism. Regions can be polygons or civic regions. A > query for a point in geospatial coordinates is handed to a server, > which finds the appropriate region and sends the query down that > tree branch. > > If you find a particular place where the discussion only applies to > civic coordinates and needs special treatment for geo, please let > me know. I guess this goes to my question above. In the system you are proposing, how do I know which resolver or forest guide to send a query to when all I have is geo coordinates? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Nov 04 19:02:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYBVy-00013R-JR; Fri, 04 Nov 2005 19:02:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYBVx-00013J-Nw for ecrit@megatron.ietf.org; Fri, 04 Nov 2005 19:02:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23065 for ; Fri, 4 Nov 2005 19:02:11 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYBl2-0007NF-K2 for ecrit@ietf.org; Fri, 04 Nov 2005 19:18:09 -0500 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 jA502Mho029889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Nov 2005 19:02:23 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id jA502Lqn006994; Fri, 4 Nov 2005 19:02:22 -0500 Message-ID: <436BF69F.1040504@cs.columbia.edu> Date: Fri, 04 Nov 2005 19:02:39 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] comments on draft-schulzrinne-ecrit-mapping-arch-00 References: <436A84F3.70206@cs.columbia.edu> <3C73A92A-ED3D-4BC2-9B87-DD9EDF83C902@hxr.us> In-Reply-To: <3C73A92A-ED3D-4BC2-9B87-DD9EDF83C902@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: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >> It's the closest analogy I could think of. No analogy is perfect, but >> there are clear similarities: > > > I think LDAP is a better analogy. I agree that this is close, but my impression was that LDAP was rarely used in a hierarchical way, with referrals and redirections (or other intermediaries). I only see the traditional corporate address book server, i.e., a single server hosting the whole database. But that may not be the whole picture. > That, and the forest guides. They are essentially a distributed root, but I agree that this is the major big-picture difference. Maybe the lesson here is to avoid a simple analogy and highlight some similarities and differences. > > Not for the whole world, but I can certainly imagine smaller countries > adopting for a nationwide centralized system. The whole notion of a > highly decentralized system is only really relevant to the US. Let me be more precise: If the lookup is being performed by your VSP, e.g., in its outbound proxy, the VSP may be located in a completely different country than the caller. (My current VSP-of-choice happens to be located in Germany.) In that model, each VSP would have to keep track of every directory/tree in the world. I don't think that's a desirable model, as it implies too much manual configuration. Maybe this is a requirement discussion; I thought we had general agreement that the lookup function can be performed either by the end system or by an outbound proxy used by the caller, presumably operated by the VSP. > > Then I do not understand what you are proposing with this > architecture. How are you bootstrapping the knowledge of the resolvers > and the forest guides? I'm picturing using the standard ISP or VSP configuration mechanism. The VSP configuration (e.g., SIP config) or ISP configuration (e.g., DHCP) would point to a resolver. Since every resolver has access to the forest guides, it doesn't much matter if the seeker picks the ISP or the VSP resolver, except maybe in terms of network proximity. The resolver operator just has to find one suitable forest guide, just like they configure NTP servers, for example. > > I guess this goes to my question above. In the system you are > proposing, how do I know which resolver or forest guide to send a > query to when all I have is geo coordinates? The forest guides have a collection of polygons ("regions"), one for each tree. Thus, they know how to find the right tree(s). The resolver is pre-configured by the ISP or VSP with one or more forest guides. If we take the one-tree-per-country model, there'd be about 200 of those maps, which seems pretty manageable, particularly given that these don't tend to change on a day-by-day basis. Henning > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Nov 04 19:31:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYBxm-00078C-Vh; Fri, 04 Nov 2005 19:31:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYBxl-000787-Ai for ecrit@megatron.ietf.org; Fri, 04 Nov 2005 19:31:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24548 for ; Fri, 4 Nov 2005 19:30:54 -0500 (EST) Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYCCq-000897-HQ for ecrit@ietf.org; Fri, 04 Nov 2005 19:46:53 -0500 Received: from [10.0.1.103] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 04 Nov 2005 19:30:44 -0500 id 0158802C.436BFD34.0000689B In-Reply-To: <436BF69F.1040504@cs.columbia.edu> References: <436A84F3.70206@cs.columbia.edu> <3C73A92A-ED3D-4BC2-9B87-DD9EDF83C902@hxr.us> <436BF69F.1040504@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <22B8130B-0DE3-42D6-9AF1-BA387FF0EAFA@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] comments on draft-schulzrinne-ecrit-mapping-arch-00 Date: Fri, 4 Nov 2005 19:30:41 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Nov 4, 2005, at 7:02 PM, Henning Schulzrinne wrote: >> I think LDAP is a better analogy. > > I agree that this is close, but my impression was that LDAP was > rarely used in a hierarchical way, with referrals and redirections > (or other intermediaries). I only see the traditional corporate > address book server, i.e., a single server hosting the whole > database. But that may not be the whole picture. LDAP is hierarchical in its model. Its basic data structure is a tree. As for the corporate address book, it is possible to setup a separate branch for each department. I suspect that in corporations that allow multiple LDAP branches, they may also allow multiple DNS tertiary delegations. If you through in the concept of LDAP centroids, well it looks much more like what you are proposing. >> Then I do not understand what you are proposing with this >> architecture. How are you bootstrapping the knowledge of the >> resolvers and the forest guides? > > I'm picturing using the standard ISP or VSP configuration > mechanism. The VSP configuration (e.g., SIP config) or ISP > configuration (e.g., DHCP) would point to a resolver. Since every > resolver has access to the forest guides, it doesn't much matter if > the seeker picks the ISP or the VSP resolver, except maybe in terms > of network proximity. The resolver operator just has to find one > suitable forest guide, just like they configure NTP servers, for > example. While using the VSPs knowledge of the world is good fallback, the most desirable configuration is the ISPs. That way, the resolvers/ forest guides do not have to have a global view of where everything is. They just need to know about their area of the planet. >> I guess this goes to my question above. In the system you are >> proposing, how do I know which resolver or forest guide to send >> a query to when all I have is geo coordinates? > > The forest guides have a collection of polygons ("regions"), one > for each tree. Thus, they know how to find the right tree(s). The > resolver is pre-configured by the ISP or VSP with one or more > forest guides. If we take the one-tree-per-country model, there'd > be about 200 of those maps, which seems pretty manageable, > particularly given that these don't tend to change on a day-by-day > basis. Ok. So you are saying that there are one or more forest guides per country (load balanced via whatever mechanism, anycast, SRV, whatever). The operation of the forest guides is a governmental issue, and the configuration of which country cares about which other countries information is up to that operation (i.e. if the US doesn't want to interact with Iran's servers, oh well). Do I have this right? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Nov 04 19:53:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYCJ7-0002Sm-2E; Fri, 04 Nov 2005 19:53:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYCJ5-0002Se-4B for ecrit@megatron.ietf.org; Fri, 04 Nov 2005 19:53:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25310 for ; Fri, 4 Nov 2005 19:52:56 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYCYA-000090-Fy for ecrit@ietf.org; Fri, 04 Nov 2005 20:08:55 -0500 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 jA50rEho011823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Nov 2005 19:53:14 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id jA50rD8M008141; Fri, 4 Nov 2005 19:53:14 -0500 Message-ID: <436C028D.6070205@cs.columbia.edu> Date: Fri, 04 Nov 2005 19:53:33 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] comments on draft-schulzrinne-ecrit-mapping-arch-00 References: <436A84F3.70206@cs.columbia.edu> <3C73A92A-ED3D-4BC2-9B87-DD9EDF83C902@hxr.us> <436BF69F.1040504@cs.columbia.edu> <22B8130B-0DE3-42D6-9AF1-BA387FF0EAFA@hxr.us> In-Reply-To: <22B8130B-0DE3-42D6-9AF1-BA387FF0EAFA@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: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > LDAP is hierarchical in its model. Its basic data structure is a > tree. As for the corporate address book, it is possible to setup a > separate branch for each department. I suspect that in corporations > that allow multiple LDAP branches, they may also allow multiple DNS > tertiary delegations. If you through in the concept of LDAP centroids, > well it looks much more like what you are proposing. I'll mention this is my comparison. > While using the VSPs knowledge of the world is good fallback, the most > desirable configuration is the ISPs. That way, the resolvers/ forest > guides do not have to have a global view of where everything is. They > just need to know about their area of the planet. But that requires that every ISP has this information, even if they know nothing about VoIP services. This doesn't seem very likely. There's also the practical problem that I might get my DHCP information from a Linksys box, which doesn't know anything about this. Thus, while I agree that ISPs are a good source of this information, I don't think we can design a system that *requires* that all of them provide this information. > Ok. So you are saying that there are one or more forest guides per > country (load balanced via whatever mechanism, anycast, SRV, > whatever). The operation of the forest guides is a governmental issue, > and the configuration of which country cares about which other > countries information is up to that operation (i.e. if the US doesn't > want to interact with Iran's servers, oh well). Do I have this right? The forest guides don't have to be operated by a government. Imagine a company called OldMoon that wants to play in this space. It would work with national or regional trees to get their coverage regions and would interconnect with other providers that also have some of this knowledge, spreading it among the forest guides. The geographic location of this company wouldn't really matter much, just that trees were willing to connect to them and send them (very infrequent) region updates. Each tree could feed its region information to any (reasonable) number of forest guides. This might include not-for-profit organizations (say, NENA), commercial data brokers or maybe even large carriers (VSP or ISP). They just have to be willing to spread data. With the danger of introducing dubious analogies, think of Usenet, except that the data volume is orders of magnitude *less*. Henning > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Nov 05 11:13:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYQfq-0002Pl-RH; Sat, 05 Nov 2005 11:13:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYQfp-0002Pg-4h for ecrit@megatron.ietf.org; Sat, 05 Nov 2005 11:13:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07833 for ; Sat, 5 Nov 2005 11:13:20 -0500 (EST) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYQv2-0005QI-Kp for ecrit@ietf.org; Sat, 05 Nov 2005 11:29:29 -0500 Received: from [10.0.1.103] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Sat, 05 Nov 2005 11:13:16 -0500 id 0158801F.436CDA1C.00007421 In-Reply-To: <436C028D.6070205@cs.columbia.edu> References: <436A84F3.70206@cs.columbia.edu> <3C73A92A-ED3D-4BC2-9B87-DD9EDF83C902@hxr.us> <436BF69F.1040504@cs.columbia.edu> <22B8130B-0DE3-42D6-9AF1-BA387FF0EAFA@hxr.us> <436C028D.6070205@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] comments on draft-schulzrinne-ecrit-mapping-arch-00 Date: Sat, 5 Nov 2005 11:13:22 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Nov 4, 2005, at 7:53 PM, Henning Schulzrinne wrote: > But that requires that every ISP has this information, even if they > know nothing about VoIP services. Well, we certainly do have a conundrum here. Because much of the ECRIT system relies on the ISPs having location information and operating location delivery protocols. Beyond VoIP, I doubt there are many solid reasons for them to do so. Still, I agree that VSPs are important when ISPs can't do what we need. > The forest guides don't have to be operated by a government. > Imagine a company called OldMoon that wants to play in this space. > It would work with national or regional trees to get their coverage > regions and would interconnect with other providers that also have > some of this knowledge, spreading it among the forest guides. The > geographic location of this company wouldn't really matter much, > just that trees were willing to connect to them and send them (very > infrequent) region updates. > > Each tree could feed its region information to any (reasonable) > number of forest guides. This might include not-for-profit > organizations (say, NENA), commercial data brokers or maybe even > large carriers (VSP or ISP). They just have to be willing to spread > data. I didn't necessarily mean a government agency directly running it. But I get your point. Thanks. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Nov 05 11:27:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYQsw-00053i-PD; Sat, 05 Nov 2005 11:27:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYQsv-00053d-99 for ecrit@megatron.ietf.org; Sat, 05 Nov 2005 11:27:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08464 for ; Sat, 5 Nov 2005 11:26:52 -0500 (EST) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYR87-0005kZ-S5 for ecrit@ietf.org; Sat, 05 Nov 2005 11:43:02 -0500 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jA5GRAtW014755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 5 Nov 2005 11:27:11 -0500 (EST) Message-ID: <436CDD69.2080305@cs.columbia.edu> Date: Sat, 05 Nov 2005 11:27:21 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] comments on draft-schulzrinne-ecrit-mapping-arch-00 References: <436A84F3.70206@cs.columbia.edu> <3C73A92A-ED3D-4BC2-9B87-DD9EDF83C902@hxr.us> <436BF69F.1040504@cs.columbia.edu> <22B8130B-0DE3-42D6-9AF1-BA387FF0EAFA@hxr.us> <436C028D.6070205@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andrew Newton wrote: > > On Nov 4, 2005, at 7:53 PM, Henning Schulzrinne wrote: > >> But that requires that every ISP has this information, even if they >> know nothing about VoIP services. > > > Well, we certainly do have a conundrum here. Because much of the ECRIT > system relies on the ISPs having location information and operating > location delivery protocols. Beyond VoIP, I doubt there are many solid > reasons for them to do so. Clearly, things work much better if the ISP plays along. I just don't think we can design a system that *requires* that it does so. As you know, the current I2 system relies on user-entered location information for residential users, for example, not requiring any ISP involvement. This is far from ideal, but seems likely to be with us for quite a while. This is a separate discussion, but I'm starting to believe that we need to think beyond the traditional top-down approach of location determination. There is evidence that cooperative location determination, such as beta.plazes.com or PlaceLab (http://www.placelab.org/) might be able to provide first-order approximations in cases where nothing better is available. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Nov 05 22:08:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYate-00054q-AI; Sat, 05 Nov 2005 22:08:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYatc-00054k-Lr for ecrit@megatron.ietf.org; Sat, 05 Nov 2005 22:08:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05199 for ; Sat, 5 Nov 2005 22:08:13 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYb8t-0002q4-AN for ecrit@ietf.org; Sat, 05 Nov 2005 22:24:28 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 5 Nov 2005 21:08:18 -0600 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sat, 05 Nov 2005 21:08:17 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 5 Nov 2005 21:08:17 -0600 Message-ID: From: "Winterbottom, James" To: "Henning Schulzrinne" , "Andrew Newton" Date: Sat, 5 Nov 2005 21:08:15 -0600 Subject: RE: [Ecrit] comments on draft-schulzrinne-ecrit-mapping-arch-00 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-OriginalArrivalTime: 06 Nov 2005 03:08:17.0270 (UTC) FILETIME=[5579D960:01C5E27F] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] comments on draft-schulzrinne-ecrit-mapping-arch-00 Thread-Index: AcXiJjSg9ZeYqkv6QDGK/4FVyGwH/QAWMDJg X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Actually that is not true NENA I2. NENA I2 requires validated data provided by a LIS. The FCC has introduced an interim order that says user entered location is okay for now until ISPs and VSPs can provide it. But time is running out as a second order is expected soon that will more than likely mandate this functionality. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Henning Schulzrinne > Sent: Sunday, 6 November 2005 3:27 AM > To: Andrew Newton > Cc: ECRIT > Subject: Re: [Ecrit] comments on draft-schulzrinne-ecrit-mapping-arch-00 >=20 > Andrew Newton wrote: > > > > On Nov 4, 2005, at 7:53 PM, Henning Schulzrinne wrote: > > > >> But that requires that every ISP has this information, even if they > >> know nothing about VoIP services. > > > > > > Well, we certainly do have a conundrum here. Because much of the ECRIT > > system relies on the ISPs having location information and operating > > location delivery protocols. Beyond VoIP, I doubt there are many solid > > reasons for them to do so. >=20 > Clearly, things work much better if the ISP plays along. I just don't > think we can design a system that *requires* that it does so. As you > know, the current I2 system relies on user-entered location information > for residential users, for example, not requiring any ISP involvement. > This is far from ideal, but seems likely to be with us for quite a while. >=20 > This is a separate discussion, but I'm starting to believe that we need > to think beyond the traditional top-down approach of location > determination. There is evidence that cooperative location > determination, such as beta.plazes.com or PlaceLab > (http://www.placelab.org/) might be able to provide first-order > approximations in cases where nothing better is available. >=20 > Henning >=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 Sat Nov 05 22:21:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYb5w-0007Hp-RD; Sat, 05 Nov 2005 22:21:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYb5v-0007Hf-6r for ecrit@megatron.ietf.org; Sat, 05 Nov 2005 22:21:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05624 for ; Sat, 5 Nov 2005 22:20:58 -0500 (EST) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYbLE-00035O-Hh for ecrit@ietf.org; Sat, 05 Nov 2005 22:37:13 -0500 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jA63LBpO027228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 5 Nov 2005 22:21:14 -0500 (EST) Message-ID: <436D7694.7030406@cs.columbia.edu> Date: Sat, 05 Nov 2005 22:20:52 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] comments on draft-schulzrinne-ecrit-mapping-arch-00 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Winterbottom, James wrote: > Actually that is not true NENA I2. > NENA I2 requires validated data provided by a LIS. > The FCC has introduced an interim order that says user entered location > is okay for now until ISPs and VSPs can provide it. But time is running > out as a second order is expected soon that will more than likely > mandate this functionality. I'm curious where this information will come from. Will the FCC mandate that ISPs provide this information? If not the ISP, where would the VSP get the information except by asking the user where they live? Just adding "LIS" doesn't magically make the information appear... Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Nov 05 23:05:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYbmq-0005x6-Nh; Sat, 05 Nov 2005 23:05:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYbmm-0005v2-Cx for ecrit@megatron.ietf.org; Sat, 05 Nov 2005 23:05:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06710 for ; Sat, 5 Nov 2005 23:05:15 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYc27-0003iy-25 for ecrit@ietf.org; Sat, 05 Nov 2005 23:21:31 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 5 Nov 2005 22:05:31 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sat, 05 Nov 2005 22:05:31 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 5 Nov 2005 22:05:30 -0600 Message-ID: From: "Winterbottom, James" To: "Henning Schulzrinne" Date: Sat, 5 Nov 2005 22:05:26 -0600 Subject: RE: [Ecrit] comments on draft-schulzrinne-ecrit-mapping-arch-00 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-OriginalArrivalTime: 06 Nov 2005 04:05:30.0833 (UTC) FILETIME=[5409FC10:01C5E287] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] comments on draft-schulzrinne-ecrit-mapping-arch-00 Thread-Index: AcXigSjZm1sgcXr8T3uP+cO3ctKB5AABel2A X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yup I agree it doesn't. My honest opinion is that it will come from the Infrastructure providers and will actually remain with them, which one of the reasons why I don't see DHCP working in that environment, by that is a different can of worms. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, 6 November 2005 2:21 PM > To: Winterbottom, James > Cc: Andrew Newton; ECRIT > Subject: Re: [Ecrit] comments on draft-schulzrinne-ecrit-mapping-arch-00 >=20 > Winterbottom, James wrote: > > Actually that is not true NENA I2. > > NENA I2 requires validated data provided by a LIS. > > The FCC has introduced an interim order that says user entered location > > is okay for now until ISPs and VSPs can provide it. But time is running > > out as a second order is expected soon that will more than likely > > mandate this functionality. >=20 > I'm curious where this information will come from. Will the FCC mandate > that ISPs provide this information? If not the ISP, where would the VSP > get the information except by asking the user where they live? >=20 > Just adding "LIS" doesn't magically make the information appear... >=20 > Henning ---------------------------------------------------------------------------= --------------------- 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 Nov 07 18:37:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZGY5-0001m6-CJ; Mon, 07 Nov 2005 18:37:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZGY3-0001m1-9e for ecrit@megatron.ietf.org; Mon, 07 Nov 2005 18:37:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17388 for ; Mon, 7 Nov 2005 18:36:45 -0500 (EST) Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZGnj-0004js-RQ for ecrit@ietf.org; Mon, 07 Nov 2005 18:53:25 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by willow.neustar.com (8.12.8/8.11.6) with ESMTP id jA7NarnM016116 for ; Mon, 7 Nov 2005 23:36:53 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Nov 2005 18:36:01 -0500 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, 7 Nov 2005 18:35:52 -0500 Message-ID: Thread-Topic: List Hum on service URN Thread-Index: AcXj8/3MxO9suNHdTZ+LBDclDyR1yw== From: "Rosen, Brian" To: X-OriginalArrivalTime: 07 Nov 2005 23:36:01.0331 (UTC) FILETIME=[03174830:01C5E3F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] List Hum on service URN X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org In the meeting today, Henning presented his draft on sos@ URI and the service: URN. There were some people who did not understand why we may need to implement both for a while, as Henning suggests. Could I ask if there is anyone who does not agree that the service URN is a good permanent solution, requiring a number of elements to change in order to completely deploy? If we have agreement that the service URN is the long term target, we can start work on that at least. There was a suggestion, for example, to more widely circulate the proposal outside of ecrit to gather comments. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 08 00:07:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZLhx-0002s6-5S; Tue, 08 Nov 2005 00:07:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZLhv-0002r3-88 for ecrit@megatron.ietf.org; Tue, 08 Nov 2005 00:07:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10763 for ; Tue, 8 Nov 2005 00:07:17 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZLxd-0007MK-VX for ecrit@ietf.org; Tue, 08 Nov 2005 00:23:59 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 23:07:24 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 07 Nov 2005 23:07:24 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 23:07:28 -0600 Message-ID: From: "Thomson, Martin" To: "Henning Schulzrinne" , Date: Mon, 7 Nov 2005 23:05:40 -0600 Subject: RE: [Ecrit] LUMP and mapping architecture documents MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 08 Nov 2005 05:07:28.0276 (UTC) FILETIME=[50A24540:01C5E422] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] LUMP and mapping architecture documents Thread-Index: AcXZzjqZdaKMIsmIRRaw1RvUybYHOQAABE6QApSKPEA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: , Content-Type: multipart/mixed; boundary="===============1377484949==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============1377484949== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message Content-Transfer-Encoding: base64 TXkgYXBvbG9naWVzIEhlbm5pbmcsIHRoYXQgbGFzdCBzdGF0ZW1lbnQgd2FzIGFuIG91dHJpZ2h0 IGZhbHNlaG9vZC4NCg0KVGhlcmUgd2FzIGEgbWlzbWF0Y2ggYmV0d2VlbiBteSBleHBlY3RhdGlv bnMgYW5kIHRoZSBhY3R1YWwgaW1wbGVtZW50YXRpb24uICAiZ21sOnBvc2l0aW9uIiBpc24ndCBw YXJ0IG9mIGFueSBzdWJzdGl0dXRpb24gZ3JvdXBzIC0gaXQgaXMgYSBHTUwgInByb3BlcnR5IiB3 aGljaCBtZWFucyB0aGF0IGl0IGlzIG5vdCBhICJHTUwgT2JqZWN0Ii4gIEkgd2FzIGRpc3RyYWN0 ZWQgYnkgdGhlIHJlZmVyZW5jZSB0byBmZWF0dXJlLnhzZCBpbiBQSURGLUxPIC0gR01MIGZlYXR1 cmVzIGFyZSAoY3VycmVudGx5KSBub3QgdXNlZCBhdCBhbGwuDQoNCkZvciB0aGF0IHJlYXNvbiwg aWYgeW91IHdhbnQgdG8gdXNlIEdNTCwgeW91IGFyZSBnaXZlbiB0d28gY2hvaWNlczoNCg0KICA8 eHM6YW55IG5hbWVzcGFjZT0iaHR0cDovL3d3dy5vcGVuZ2lzLm5ldC9nbWwiIHByb2Nlc3NDb250 ZW50cz0ibGF4fHN0cmljdCIvPg0KDQpPciBqdXN0IGJlIGV2ZW4gbW9yZSBsaWJlcmFsIGFueSBh bGxvdyBhbnkgY29udGVudDoNCg0KICA8eHM6YW55IG5hbWVzcGFjZT0iIyNhbnkiIHByb2Nlc3ND b250ZW50cz0ibGF4fHN0cmljdCIvPg0KDQpGb3IgdGhlIHRpbWUgYmVpbmcgZWl0aGVyIGlzIGdv b2QgZW5vdWdoLiAgRnVydGhlciBkaXNjdXNzaW9uIG9uIGdlb2RldGljIGxvY2F0aW9uIHJlcHJl c2VudGF0aW9uIG1pZ2h0IGhhdmUgdG8gY29udGludWUgb24gdGhlIEdFT1BSSVYgbGlzdC4NCg0K TWFydGluDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVGhvbXNvbiwg TWFydGluDQo+IFNlbnQ6IFdlZG5lc2RheSwgMjYgT2N0b2JlciAyMDA1IDExOjQyIEFNDQo+IFRv OiAnSGVubmluZyBTY2h1bHpyaW5uZSc7IFdpbnRlcmJvdHRvbSwgSmFtZXM7IGVjcml0QGlldGYu b3JnDQo+IFN1YmplY3Q6IFJFOiBbRWNyaXRdIExVTVAgYW5kIG1hcHBpbmcgYXJjaGl0ZWN0dXJl IGRvY3VtZW50cw0KPiANCj4gSSBjYW4gYW5zd2VyIHRoYXQgb25lLg0KPiANCj4gZ21sOl9GZWF0 dXJlIGlzIHRoZSBjb3JyZWN0IG9iamVjdCwgYmFzZWQgb24gdGhlIFBJREYtTE8gc3BlYy4gIFRo aXMNCj4gZWxlbWVudCBpcyB0aGUgYWJzdHJhY3QgaGVhZCBvZiBhIHN1YnN0aXR1dGlvbiBncm91 cCB0aGF0IGluY2x1ZGVzDQo+IGdtbDpwb3NpdGlvbi4NCj4gDQo+IENoZWVycywNCj4gTWFydGlu DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBlY3JpdC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ IEhlbm5pbmcgU2NodWx6cmlubmUNCj4gU2VudDogV2VkbmVzZGF5LCAyNiBPY3RvYmVyIDIwMDUg MTE6MzggQU0NCj4gVG86IFdpbnRlcmJvdHRvbSwgSmFtZXM7IGVjcml0QGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbRWNyaXRdIExVTVAgYW5kIG1hcHBpbmcgYXJjaGl0ZWN0dXJlIGRvY3VtZW50 cw0KPiANCj4gVGhhbmtzIC0geWVzLCB0aGUgZGFuZ2VycyBvZiByZWx5aW5nIHRvbyBtdWNoIG9u IFhNTHNweSByYXRoZXIgdGhhbg0KPiB2YWxpZGF0aW9uIGJ5IGh1bWFuIGluc3BlY3Rpb24gOi0p DQo+IA0KPiBNb3JlIHNlcmlvdXNseTogV2hhdCB3b3VsZCBiZSB0aGUgYXBwcm9wcmlhdGUgWE1M IG9iamVjdCBmb3IgZ2VvIG9ubHk/DQo+IGdtbDpwb3NpdGlvbj8NCj4gDQo+IFRoYW5rcy4NCj4g DQo+IEhlbm5pbmcNCj4gDQo+IFdpbnRlcmJvdHRvbSwgSmFtZXMgd3JvdGU6DQo+ID4gSGkgSGVu bmluZywNCj4gPg0KPiA+IEkgd2lsbCBoYXZlIG1vcmUgY29tbWVudHMgb24gdGhpcyBkcmFmdCBs YXRlci4NCj4gPiBCdXQgZm9yIG5vdyB0aGVyZSBpcyBhIGNsZWFyIG1pc3Rha2UgaW4gdGhlIFhN TCBpbiB0aGF0IHlvdXIgZ2VvIG9wdGlvbg0KPiA+IGlzIHVzaW5nIGEgdHlwZSBvZiAiY2E6Y2l2 aWNBZGRyZXNzIg0KPiA+DQo+ID4gKjgpDQo+ID4NCj4gPiBDaGVlcnMNCj4gPiBKYW1lcw0KPiA+ DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lw aWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90 aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRl IHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHBy b2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============1377484949== 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 --===============1377484949==-- From ecrit-bounces@ietf.org Tue Nov 08 01:01:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZMY2-0007cG-JD; Tue, 08 Nov 2005 01:01:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZMY1-0007c7-9z for ecrit@megatron.ietf.org; Tue, 08 Nov 2005 01:01:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12748 for ; Tue, 8 Nov 2005 01:01:07 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZMnj-0008Sb-0L for ecrit@ietf.org; Tue, 08 Nov 2005 01:17:50 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id jA861KJG021443 for ; Tue, 8 Nov 2005 07:01:20 +0100 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 jA861Jel030135 for ; Tue, 8 Nov 2005 07:01:20 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Nov 2005 07:01:19 +0100 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, 8 Nov 2005 07:01:17 +0100 Message-ID: Thread-Topic: presentation slides Thread-Index: AcXj8WuMogSh2eoVRZCd0WlduKU22w== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 08 Nov 2005 06:01:19.0101 (UTC) FILETIME=[D65B0AD0:01C5E429] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] presentation slides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org please send me your most recent presentation slides. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 08 11:21:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZWE3-0005SP-P9; Tue, 08 Nov 2005 11:21:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZWE2-0005SK-Gw for ecrit@megatron.ietf.org; Tue, 08 Nov 2005 11:21:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15021 for ; Tue, 8 Nov 2005 11:21:08 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZWTq-0008Pv-Pk for ecrit@ietf.org; Tue, 08 Nov 2005 11:37:57 -0500 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 jA8GLPho011612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Nov 2005 11:21:26 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id jA8GLPBl015144; Tue, 8 Nov 2005 11:21:25 -0500 Message-ID: <4370D086.2010805@cs.columbia.edu> Date: Tue, 08 Nov 2005 11:21:26 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Thomson, Martin" Subject: Re: [Ecrit] LUMP and mapping architecture documents References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thanks for checking up on this. Having a schema-recognizable geo representation for both points and polygons would be helpful, I think. Thomson, Martin wrote: > My apologies Henning, that last statement was an outright falsehood. > > There was a mismatch between my expectations and the actual implementation. "gml:position" isn't part of any substitution groups - it is a GML "property" which means that it is not a "GML Object". I was distracted by the reference to feature.xsd in PIDF-LO - GML features are (currently) not used at all. > > For that reason, if you want to use GML, you are given two choices: > > > > Or just be even more liberal any allow any content: > > > > For the time being either is good enough. Further discussion on geodetic location representation might have to continue on the GEOPRIV list. > > Martin > > >>-----Original Message----- >>From: Thomson, Martin >>Sent: Wednesday, 26 October 2005 11:42 AM >>To: 'Henning Schulzrinne'; Winterbottom, James; ecrit@ietf.org >>Subject: RE: [Ecrit] LUMP and mapping architecture documents >> >>I can answer that one. >> >>gml:_Feature is the correct object, based on the PIDF-LO spec. This >>element is the abstract head of a substitution group that includes >>gml:position. >> >>Cheers, >>Martin >> >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >>Henning Schulzrinne >>Sent: Wednesday, 26 October 2005 11:38 AM >>To: Winterbottom, James; ecrit@ietf.org >>Subject: Re: [Ecrit] LUMP and mapping architecture documents >> >>Thanks - yes, the dangers of relying too much on XMLspy rather than >>validation by human inspection :-) >> >>More seriously: What would be the appropriate XML object for geo only? >>gml:position? >> >>Thanks. >> >>Henning >> >>Winterbottom, James wrote: >> >>>Hi Henning, >>> >>>I will have more comments on this draft later. >>>But for now there is a clear mistake in the XML in that your geo option >>>is using a type of "ca:civicAddress" >>> >>>*8) >>> >>>Cheers >>>James >>> >> >>_______________________________________________ >>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 Tue Nov 08 14:08:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYpr-0001ri-OE; Tue, 08 Nov 2005 14:08:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYpq-0001ra-7H for ecrit@megatron.ietf.org; Tue, 08 Nov 2005 14:08:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26476 for ; Tue, 8 Nov 2005 14:08:19 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZZ5h-000592-Sv for ecrit@ietf.org; Tue, 08 Nov 2005 14:25:10 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Nov 2005 11:08:37 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,305,1125903600"; d="scan'208"; a="14746430:sNHT22938424" 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 jA8J8Sx6020041; Tue, 8 Nov 2005 14:08:34 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 14:08:25 -0500 Received: from [209.52.152.168] ([10.86.242.85]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 14:08:25 -0500 Message-ID: <4370F7A7.2050408@cisco.com> Date: Tue, 08 Nov 2005 14:08:23 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" Subject: Re: [Ecrit] List Hum on service URN References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2005 19:08:25.0500 (UTC) FILETIME=[CB7BA5C0:01C5E497] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Well, you asked if anyone DOESNT agree that the service URN is the right direction speak up. I think it is the right direction, but I'll speak up anyway ;) Architecturally speaking, I think the service URN is really the right thing here because the very problem we are trying to solve is how to identify a particular resource by its name, in a way quite distinct from its actual location. In that way, the various mapping protocols can be viewed as a name to address mapping service. Using the sos URI is actually an attempt to represent a name with an address by stealing a value out of the namespace for every single domain in existence, and declaring any address with that user part to actually represent a name. This introduces the practical problem Henning has pointed out, about entities outside of that domain needing to recognize the name anyway. The main drawback that has been raised on the URN is that it requires endpoint and proxy changes in order to be deployable. I'd argue that, for these environments, we already have a transition mechanism which are the localized emergency URI (i.e., sip:911@provider.net). It doesn't make sense to me to insert an intermediate solution rather than going right to the destination. Thus, I would propose we abandon the sos URI draft entirely. So, the logic would be that an endpoint would try to call the service URN, and if that fails, it would use a emergency URI of the form above. -Jonathan R. Rosen, Brian wrote: > In the meeting today, Henning presented his draft on sos@ URI and the > service: URN. There were some people who did not understand why we may > need to implement both for a while, as Henning suggests. > > Could I ask if there is anyone who does not agree that the service URN > is a good permanent solution, requiring a number of elements to change > in order to completely deploy? If we have agreement that the service > URN is the long term target, we can start work on that at least. There > was a suggestion, for example, to more widely circulate the proposal > outside of ecrit to gather comments. > > Brian > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 08 17:13:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbik-0001R6-64; Tue, 08 Nov 2005 17:13:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbii-0001QS-2k for ecrit@megatron.ietf.org; Tue, 08 Nov 2005 17:13:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09357 for ; Tue, 8 Nov 2005 17:13:08 -0500 (EST) 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 1EZbya-0002bg-Dl for ecrit@ietf.org; Tue, 08 Nov 2005 17:30:01 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 08 Nov 2005 14:13:25 -0800 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 jA8MDEZO004059 for ; Tue, 8 Nov 2005 14:13:24 -0800 (PST) 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); Tue, 8 Nov 2005 14:13:23 -0800 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 14:13:22 -0800 From: "Marc Linsner" To: Date: Tue, 8 Nov 2005 17:13:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXksZ6a60jha3NtSmapVcCmkcyISg== Message-ID: X-OriginalArrivalTime: 08 Nov 2005 22:13:23.0451 (UTC) FILETIME=[A26094B0:01C5E4B1] X-Spam-Score: 1.1 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [Ecrit] Location-by-value requirement X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org As agreed at IETF64 - LCMS queries MUST employ location-by- value only and void of user identity information. Location-by-reference requires RFC3693 adherance which would cause security/privacy issues that would not be obvious to the geopriv rulemaker, hence forcing a situation that the LCMS query would fail at the most unappropriate time. I added this to the issue tracker. -Marc- Marc Linsner Consulting Engineer - Corporate Development Cisco Systems, Inc. +1-239-272-2105 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 08 17:13:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbil-0001Sq-E8; Tue, 08 Nov 2005 17:13:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbij-0001Qq-Re for ecrit@megatron.ietf.org; Tue, 08 Nov 2005 17:13:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09360 for ; Tue, 8 Nov 2005 17:13:10 -0500 (EST) 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 1EZbyc-0002bg-6Y for ecrit@ietf.org; Tue, 08 Nov 2005 17:30:03 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 08 Nov 2005 14:13:30 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA8MCuZe003832 for ; Tue, 8 Nov 2005 14:13:29 -0800 (PST) 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, 8 Nov 2005 14:13:26 -0800 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 14:13:24 -0800 From: "Marc Linsner" To: Date: Tue, 8 Nov 2005 17:13:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXksUk2Ph4dHQ6KSdi1O8Mx6cFndw== Message-ID: X-OriginalArrivalTime: 08 Nov 2005 22:13:26.0185 (UTC) FILETIME=[A401C190:01C5E4B1] X-Spam-Score: 1.1 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Pre-Call Routing Requirement X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org As agreed at IETF64 -- Pre-Call routing - launching a LCMS query prior to making an emergency call, MUST be allowed. As a fallback mechanism, for use only if a LCMS query fails at emergency call time, it may be advantageous to have prior knowledge of the PSAP URI. This prior knowledge would be obtained by performing a LCMS query at any time prior to an emergency call. I added this to the issue tracker. -Marc- Marc Linsner Consulting Engineer - Corporate Development Cisco Systems, Inc. +1-239-272-2105 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 08 17:29:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZby4-0005Ie-5T; Tue, 08 Nov 2005 17:29:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZby3-0005IS-11 for ecrit@megatron.ietf.org; Tue, 08 Nov 2005 17:29:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10190 for ; Tue, 8 Nov 2005 17:28:59 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZcDw-0002zm-GU for ecrit@ietf.org; Tue, 08 Nov 2005 17:45:52 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 16:29:18 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 08 Nov 2005 16:29:18 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 16:29:17 -0600 Message-ID: From: "Winterbottom, James" To: "Marc Linsner" , Date: Tue, 8 Nov 2005 16:29:15 -0600 Subject: RE: [Ecrit] Location-by-value requirement 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-OriginalArrivalTime: 08 Nov 2005 22:29:17.0362 (UTC) FILETIME=[DAF3D920:01C5E4B3] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location-by-value requirement Thread-Index: AcXksZ6a60jha3NtSmapVcCmkcyISgAAcq0g X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Marc, I guess I see the basis of this requirement as being a little different to the way that you have stated if even the outcome is net the same. My wording would be closer to: "LCMS queries MUST NOT provide any means for the mapping service to associate location with user or host identity. To this end, only location by-value is to be used as this negates the requirement for the LCMS mapper to adhere to RFC-3693." Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Marc Linsner > Sent: Wednesday, 9 November 2005 9:13 AM > To: ecrit@ietf.org > Subject: [Ecrit] Location-by-value requirement >=20 > As agreed at IETF64 - LCMS queries MUST employ location-by- > value only and void of user identity information. Location-by-reference > requires RFC3693 adherance which would cause security/privacy issues that > would not be obvious to the geopriv rulemaker, hence forcing a situation > that > the LCMS query would fail at the most unappropriate time. >=20 > I added this to the issue tracker. >=20 > -Marc- >=20 > Marc Linsner > Consulting Engineer - Corporate Development > Cisco Systems, Inc. > +1-239-272-2105 >=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 Tue Nov 08 18:01:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZcT2-0000US-Mc; Tue, 08 Nov 2005 18:01:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZcT1-0000UN-57 for ecrit@megatron.ietf.org; Tue, 08 Nov 2005 18:01:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12114 for ; Tue, 8 Nov 2005 18:01:01 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZcis-0003ty-Rz for ecrit@ietf.org; Tue, 08 Nov 2005 18:17:53 -0500 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 jA8N1Fho012556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Nov 2005 18:01:15 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id jA8N1Agg016534; Tue, 8 Nov 2005 18:01:11 -0500 Message-ID: <43712E35.8@cs.columbia.edu> Date: Tue, 08 Nov 2005 18:01:09 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Ecrit] List Hum on service URN References: <4370F7A7.2050408@cisco.com> In-Reply-To: <4370F7A7.2050408@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On the transition issue, I agree that this is probably hard to get right for the cases that matter and it may not matter enough to try. There are probably three cases of interest: - corporate SIP hard phones: the sip:911@corporate.com;user=phone is likely to work well enough. The difficulty is then how the proxy would act on such requests; ideally, it would replace the To/Request-URI with urn:service:sos so that downstream entities can recognize the nature of the call independent of the location of the caller. Request-URI is obviously easy, but for the 'To' header, this goes back to the discussion taking place in today's SIP meeting. Refering a user to the urn:service wouldn't work. The problem is that there are lots of emergency identifiers and they should not leave the local environment. For example, both 9-911 and 911 (and local emergency numbers) work. - service-provider soft phones: presumably can be upgraded easily; - service-provider hard phones/ATAs: may be harder, but roughly similar to the first problem. I don't think there are enough cases of interest where the outbound proxy is operated by a party other than the service provider or enterprise to spend much effort on this. Thus, if we can solve the re-labeling problem, I'm happy to focus on the service URN. Henning Jonathan Rosenberg wrote: > Well, you asked if anyone DOESNT agree that the service URN is the right > direction speak up. I think it is the right direction, but I'll speak up > anyway ;) > > Architecturally speaking, I think the service URN is really the right > thing here because the very problem we are trying to solve is how to > identify a particular resource by its name, in a way quite distinct from > its actual location. In that way, the various mapping protocols can be > viewed as a name to address mapping service. Using the sos URI is > actually an attempt to represent a name with an address by stealing a > value out of the namespace for every single domain in existence, and > declaring any address with that user part to actually represent a name. > This introduces the practical problem Henning has pointed out, about > entities outside of that domain needing to recognize the name anyway. > > The main drawback that has been raised on the URN is that it requires > endpoint and proxy changes in order to be deployable. I'd argue that, > for these environments, we already have a transition mechanism which are > the localized emergency URI (i.e., sip:911@provider.net). It doesn't > make sense to me to insert an intermediate solution rather than going > right to the destination. Thus, I would propose we abandon the sos URI > draft entirely. > > So, the logic would be that an endpoint would try to call the service > URN, and if that fails, it would use a emergency URI of the form above. > > -Jonathan R. > > Rosen, Brian wrote: > >> In the meeting today, Henning presented his draft on sos@ URI and the >> service: URN. There were some people who did not understand why we may >> need to implement both for a while, as Henning suggests. >> >> Could I ask if there is anyone who does not agree that the service URN >> is a good permanent solution, requiring a number of elements to change >> in order to completely deploy? If we have agreement that the service >> URN is the long term target, we can start work on that at least. There >> was a suggestion, for example, to more widely circulate the proposal >> outside of ecrit to gather comments. >> >> Brian >> >> _______________________________________________ >> 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 Nov 08 18:43:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZd7K-00059l-Cy; Tue, 08 Nov 2005 18:43:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZd7I-00059Y-Ji for ecrit@megatron.ietf.org; Tue, 08 Nov 2005 18:43:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13931 for ; Tue, 8 Nov 2005 18:42:38 -0500 (EST) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZdNC-0004n1-Lp for ecrit@ietf.org; Tue, 08 Nov 2005 18:59:31 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA8Ngd3M012972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Nov 2005 15:42:39 -0800 Received: from [209.52.110.224] (vpn-10-50-0-51.qualcomm.com [10.50.0.51]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA8NgXvC009283; Tue, 8 Nov 2005 15:42:37 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43712E35.8@cs.columbia.edu> References: <4370F7A7.2050408@cisco.com> <43712E35.8@cs.columbia.edu> Date: Tue, 8 Nov 2005 15:42:31 -0800 To: Henning Schulzrinne , Jonathan Rosenberg From: Ted Hardie Subject: Re: [Ecrit] List Hum on service URN Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org By the way, there is already a service URI scheme, which is associated with RFC2165 (according to http://www.iana.org/assignments/uri-schemes). While it is up to the urn-nid list to decide whether having a urn:service NID and a service scheme is too confusing, we may wish to avoid the heartburn by picking a different NID. regards, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 08 18:52:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZdGX-0007fp-B6; Tue, 08 Nov 2005 18:52:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZdGV-0007fF-3a for ecrit@megatron.ietf.org; Tue, 08 Nov 2005 18:52:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14455 for ; Tue, 8 Nov 2005 18:52:08 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZdWO-00052l-BU for ecrit@ietf.org; Tue, 08 Nov 2005 19:09:01 -0500 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 jA8NqRho022563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Nov 2005 18:52:28 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id jA8NqQlh016701; Tue, 8 Nov 2005 18:52:27 -0500 Message-ID: <43713A3C.3080909@cs.columbia.edu> Date: Tue, 08 Nov 2005 18:52:28 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] List Hum on service URN References: <4370F7A7.2050408@cisco.com> <43712E35.8@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org 2165 seems to be rather rarely used these days, so I'm not convinced that we need to steer clear of this. Ted Hardie wrote: > By the way, there is already a service URI scheme, which is associated > with RFC2165 (according to http://www.iana.org/assignments/uri-schemes). > While it is up to the urn-nid list to decide whether having a urn:service > NID and a service scheme is too confusing, we may wish to avoid the > heartburn by picking a different NID. > regards, > Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 08 21:50:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZg2t-0003fA-GR; Tue, 08 Nov 2005 21:50:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZg2r-0003eu-Gf for ecrit@megatron.ietf.org; Tue, 08 Nov 2005 21:50:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06668 for ; Tue, 8 Nov 2005 21:50:14 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZgIn-0005G6-9Z for ecrit@ietf.org; Tue, 08 Nov 2005 22:07:09 -0500 Received: from pp107-180.bctel.ca ([209.52.107.180] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EZg2k-0002U2-9d; Tue, 08 Nov 2005 20:50:35 -0600 From: "Brian Rosen" To: "'Roger Marshall'" , Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Date: Tue, 8 Nov 2005 21:49:35 -0500 Message-ID: <01ee01c5e4d8$3d81e900$b46b34d1@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXUFeX8wpzsAP7sT7O87+dhkPMmoAADXQAgBC0wMeA= In-Reply-To: <8C837214C95C864C9F34F3635C2A6575035F60B2@SEA-EXCHVS-2.telecomsys.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable 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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Consider adding the following paragraph to the introductory text on = mapping: Ideally, the mapping protocol would yield a URI which would allow an emergency call to be completed on the Internet. However, not all PSAPs = may have IP based connectivity. Thus the URI scheme cannot be fixed, and in fact may end up being a tel uri to allow calls to be completed on the = PSTN. ________________________________________ From: Roger Marshall [mailto:RMarshall@telecomsys.com]=20 Sent: Tuesday, October 18, 2005 4:50 PM To: br@brianrosen.net; ecrit@ietf.org Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Brian: Please send proposed requirements=A0text which addresses=A0NENA's = concerns.=A0 It may also be helpful to provide examples of the different levels of = "default routing" and how this might be represented within the messaging (after = the mapping result is returned to the mapping client). =A0 Roger Marshall. ________________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Brian Rosen Sent: Tuesday, October 18, 2005 11:58 AM To: ecrit@ietf.org Subject: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes More comments from NENA: In our requirement 3.4-4, we said, Mechanisms must be provided to route emergency calls in areas not served by E9-1-1 to an appropriate PSTN telephone number.=A0 I31 is related to this, but doesn=92t cover it = adequately we feel.=A0 One way to improve it would be to use a tel uri with an = e.164 as an example.=20 The issue of =93default routing=94 must be covered in the = requirements.=A0 This occurs when less than complete information or inconsistent information = is provided (for example, good community name, but bad street name).=A0 In = these cases, some entity must determine a route.=A0 In general, there is a = =93default=94 route for levels of the address hierarchy when data below that level is missing or inaccurate.=A0 Generally, this is a =93longest prefix = match=94 problem.=A0 The mapping function could do this itself, or it could = accept a less than complete query (no data below city name for example), and = return a mapping, pushing the error resolution process back to the entity = requesting mapping.=A0 We would prefer that the mapping function return a valid = default mapping if partial data is provided or data is inconsistent.=A0 There = are similar mechanisms needed for geo routing.=A0 As a separate requirement, = it is important that somehow, the destination know that default routing was = used. =A0This implies that the mapping result includes some kind of flag that default routing was used, and that flag can be propagated downstream. Requirement I31b: The mapping protocol MUST be able to return a URI or contact method explicitly marked as an alternate contact does not = adequately address our requirement 3.6-19: Multiple types of failures may have different contingency routes. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 08 22:26:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZgbB-0008MB-W7; Tue, 08 Nov 2005 22:26:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZgbA-0008M1-GC for ecrit@megatron.ietf.org; Tue, 08 Nov 2005 22:26:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08086 for ; Tue, 8 Nov 2005 22:25:40 -0500 (EST) Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZgr5-0005xz-CB for ecrit@ietf.org; Tue, 08 Nov 2005 22:42:36 -0500 Received: from [209.52.106.141] ([::ffff:209.52.106.141]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 08 Nov 2005 22:25:39 -0500 id 01588020.43716C34.00006235 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <37E5220A-DD5C-4E83-83E1-07AC52EAC31D@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location-by-value requirement Date: Tue, 8 Nov 2005 22:25:46 -0500 To: "Winterbottom, James" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Nov 8, 2005, at 5:29 PM, Winterbottom, James wrote: > "LCMS queries MUST NOT provide any means for the mapping service to > associate location with user or host identity. To this end, only > location by-value is to be used as this negates the requirement for > the > LCMS mapper to adhere to RFC-3693." Host identity? Is the source IP address of the seeker not a host identity in this context? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 09 00:51:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZira-0002Uf-Vn; Wed, 09 Nov 2005 00:51:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZirY-0002UV-UY for ecrit@megatron.ietf.org; Wed, 09 Nov 2005 00:51:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14903 for ; Wed, 9 Nov 2005 00:50:44 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZj7T-0000s0-70 for ecrit@ietf.org; Wed, 09 Nov 2005 01:07:40 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 23:50:56 -0600 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 08 Nov 2005 23:50:55 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 23:50:54 -0600 Message-ID: From: "Winterbottom, James" To: "Andrew Newton" Date: Tue, 8 Nov 2005 23:50:54 -0600 Subject: RE: [Ecrit] Location-by-value requirement 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-OriginalArrivalTime: 09 Nov 2005 05:50:55.0101 (UTC) FILETIME=[8CD5F2D0:01C5E4F1] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Location-by-value requirement Thread-Index: AcXk3Uth50b5ZeF+Qca7RCDfhf5USgAFDR0g X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org To be clear, the identity or IP address of the thing at the location. > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Wednesday, 9 November 2005 2:26 PM > To: Winterbottom, James > Cc: Marc Linsner; ecrit@ietf.org > Subject: Re: [Ecrit] Location-by-value requirement >=20 >=20 > On Nov 8, 2005, at 5:29 PM, Winterbottom, James wrote: >=20 > > "LCMS queries MUST NOT provide any means for the mapping service to > > associate location with user or host identity. To this end, only > > location by-value is to be used as this negates the requirement for > > the > > LCMS mapper to adhere to RFC-3693." >=20 > Host identity? Is the source IP address of the seeker not a host > identity in this context? >=20 > -andy ---------------------------------------------------------------------------= --------------------- 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 Nov 09 09:25:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZqtR-00040h-Nm; Wed, 09 Nov 2005 09:25:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZqtP-00040F-V8 for ecrit@megatron.ietf.org; Wed, 09 Nov 2005 09:25:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12279 for ; Wed, 9 Nov 2005 09:25:12 -0500 (EST) 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 1EZr9Q-0005tT-LZ for ecrit@ietf.org; Wed, 09 Nov 2005 09:42:14 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 09 Nov 2005 06:25:29 -0800 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 jA9EPIZK023475; Wed, 9 Nov 2005 06:25:26 -0800 (PST) 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, 9 Nov 2005 06:25:25 -0800 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 06:25:25 -0800 From: "Marc Linsner" To: "'Winterbottom, James'" , "'Andrew Newton'" Subject: RE: [Ecrit] Location-by-value requirement Date: Wed, 9 Nov 2005 09:25:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXk3Uth50b5ZeF+Qca7RCDfhf5USgAFDR0gABGiapA= In-Reply-To: Message-ID: X-OriginalArrivalTime: 09 Nov 2005 14:25:25.0362 (UTC) FILETIME=[6CF1F520:01C5E539] X-Spam-Score: 1.1 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, It is implied that the source address of a LCMS query may (or may not) be the IP address of the target. I'm not sure this is avoidable. I do agree that the query itself should not have target IP address or user identity contained within it. Is this what you are wanting? -Marc- > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, November 09, 2005 12:51 AM > To: Andrew Newton > Cc: Marc Linsner; ecrit@ietf.org > Subject: RE: [Ecrit] Location-by-value requirement > > To be clear, the identity or IP address of the thing at the location. > > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Wednesday, 9 November 2005 2:26 PM > > To: Winterbottom, James > > Cc: Marc Linsner; ecrit@ietf.org > > Subject: Re: [Ecrit] Location-by-value requirement > > > > > > On Nov 8, 2005, at 5:29 PM, Winterbottom, James wrote: > > > > > "LCMS queries MUST NOT provide any means for the mapping > service to > > > associate location with user or host identity. To this end, only > > > location by-value is to be used as this negates the > requirement for > > > the LCMS mapper to adhere to RFC-3693." > > > > Host identity? Is the source IP address of the seeker not a host > > identity in this context? > > > > -andy > > -------------------------------------------------------------- > ---------------------------------- > 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 Nov 09 13:20:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZuZ9-0005WL-5I; Wed, 09 Nov 2005 13:20:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZuZ8-0005WF-5L for ecrit@megatron.ietf.org; Wed, 09 Nov 2005 13:20:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27582 for ; Wed, 9 Nov 2005 13:20:26 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZup3-0004hP-U0 for ecrit@ietf.org; Wed, 09 Nov 2005 13:37:29 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 9 Nov 2005 13:20:46 -0500 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] NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Date: Wed, 9 Nov 2005 10:20:53 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750388A22A@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes Thread-Index: AcXUFeX8wpzsAP7sT7O87+dhkPMmoAADXQAgBC0wMeAAIH0gEA== From: "Roger Marshall" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I've added this to the issue tracker as #28. = http://www.ietf-ecrit.org:8080/ecrit-req/ Roger Marshall=20 >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net]=20 >Sent: Tuesday, November 08, 2005 6:50 PM >To: Roger Marshall; ecrit@ietf.org >Subject: RE: [Ecrit] NENA Comments on=20 >draft-ietf-ecrit-requirements-00 -Alternate Routes > >Consider adding the following paragraph to the introductory=20 >text on mapping: > >Ideally, the mapping protocol would yield a URI which would=20 >allow an emergency call to be completed on the Internet. =20 >However, not all PSAPs may have IP based connectivity. Thus=20 >the URI scheme cannot be fixed, and in fact may end up being a=20 >tel uri to allow calls to be completed on the PSTN. > >________________________________________ >From: Roger Marshall [mailto:RMarshall@telecomsys.com] >Sent: Tuesday, October 18, 2005 4:50 PM >To: br@brianrosen.net; ecrit@ietf.org >Subject: RE: [Ecrit] NENA Comments on=20 >draft-ietf-ecrit-requirements-00 -Alternate Routes > >Brian: >Please send proposed requirements=A0text which addresses=A0NENA's=20 >concerns.=A0 It may also be helpful to provide examples of the=20 >different levels of "default routing" and how this might be=20 >represented within the messaging (after the mapping result is=20 >returned to the mapping client). >=A0 >Roger Marshall. > >________________________________________ >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Brian Rosen >Sent: Tuesday, October 18, 2005 11:58 AM >To: ecrit@ietf.org >Subject: [Ecrit] NENA Comments on=20 >draft-ietf-ecrit-requirements-00 -Alternate Routes More=20 >comments from NENA: > >In our requirement 3.4-4, we said, Mechanisms must be provided=20 >to route emergency calls in areas not served by E9-1-1 to an=20 >appropriate PSTN telephone number.=A0 I31 is related to this,=20 >but doesn't cover it adequately we feel.=A0 One way to improve=20 >it would be to use a tel uri with an e.164 as an example.=20 > >The issue of "default routing" must be covered in the=20 >requirements.=A0 This occurs when less than complete information=20 >or inconsistent information is provided (for example, good=20 >community name, but bad street name).=A0 In these cases, some=20 >entity must determine a route.=A0 In general, there is a "default" >route for levels of the address hierarchy when data below that=20 >level is missing or inaccurate.=A0 Generally, this is a "longest=20 >prefix match" >problem.=A0 The mapping function could do this itself, or it=20 >could accept a less than complete query (no data below city=20 >name for example), and return a mapping, pushing the error=20 >resolution process back to the entity requesting mapping.=A0 We=20 >would prefer that the mapping function return a valid default=20 >mapping if partial data is provided or data is inconsistent.=A0=20 >There are similar mechanisms needed for geo routing.=A0 As a=20 >separate requirement, it is important that somehow, the=20 >destination know that default routing was used. >=A0This implies that the mapping result includes some kind of=20 >flag that default routing was used, and that flag can be=20 >propagated downstream. > >Requirement I31b: The mapping protocol MUST be able to return=20 >a URI or contact method explicitly marked as an alternate=20 >contact does not adequately address our requirement 3.6-19:=20 >Multiple types of failures may have different contingency routes. > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 09 22:23:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea31n-000059-Ut; Wed, 09 Nov 2005 22:23:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea31m-000052-OL for ecrit@megatron.ietf.org; Wed, 09 Nov 2005 22:23:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01287 for ; Wed, 9 Nov 2005 22:22:38 -0500 (EST) Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ea3Hs-0003VL-0W for ecrit@ietf.org; Wed, 09 Nov 2005 22:39:47 -0500 Received: (qmail invoked by alias); 10 Nov 2005 03:22:52 -0000 Received: from pp106-245.bctel.ca (EHLO [209.52.106.245]) [209.52.106.245] by mail.gmx.net (mp021) with SMTP; 10 Nov 2005 04:22:52 +0100 X-Authenticated: #29516787 Message-ID: <4372BD0C.3010408@gmx.net> Date: Wed, 09 Nov 2005 19:22:52 -0800 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: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [Ecrit] presentation slides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all, you might have noticed that the ecrit meeting slides are already available at: https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64 ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Nov 13 06:41:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbGEX-0006ff-EK; Sun, 13 Nov 2005 06:41:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbGEV-0006fa-TL for ecrit@megatron.ietf.org; Sun, 13 Nov 2005 06:41:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28514 for ; Sun, 13 Nov 2005 06:40:45 -0500 (EST) Received: from smartmx-05.inode.at ([213.229.60.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbGVJ-000711-Hz for ecrit@ietf.org; Sun, 13 Nov 2005 06:58:38 -0500 Received: from [81.223.16.194] (port=2908 helo=mah9.eunet.at) by smartmx-05.inode.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EbGET-0005kX-BL for ecrit@ietf.org; Sun, 13 Nov 2005 12:41:13 +0100 Message-Id: <6.2.5.6.2.20051113124014.057ee778@eunet.at> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 13 Nov 2005 12:41:13 +0100 To: ecrit@ietf.org From: Michael Haberler Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-60F067ED X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ecrit] calling area object sizes - Austria X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org since I've told Hannes that I'd been playing around with PostGis and Austrian calling area objetcs, he asked me to do a check as to what sizes these are - to get a ballpark figure. Note these are calling areas, not service areas of emergency operators, but the order of the problem should be similiar. I will try to obtain more relevant shapefiles for communities and police service areas and repeat the stats on these. Austria has: - 1022 calling areas - about 2400 communities (smallest granularity of service area - fire brigade) - about 42 police service areas (largest granularity) these figures are only on the calling areas. avergae number of points: 271, ranging from 24..1941 points average GML object size: 9314 bytes, ranging from 938..65710 bytes average area covered: 98 km2, ranging from 8.5 to 618 km2 average number of points per km2: 3.3, ranging from 0.3..15 without having the real data yet, I'd say this isnt terribly significant yet, but I'd guess the objects for firebrigade service areas to be on the small end of these ranges, while the police calling areas could well be double the size on the high end. -Michael http://mah.priv.at/gis/43-callingarea-postgis.html _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 17 10:11:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EclQ5-00082H-C6; Thu, 17 Nov 2005 10:11:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EclQ3-000829-Lt for ecrit@megatron.ietf.org; Thu, 17 Nov 2005 10:11:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29306 for ; Thu, 17 Nov 2005 10:10:50 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eclhh-0005NK-O4 for ecrit@ietf.org; Thu, 17 Nov 2005 10:29:39 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAHFAxo11703 for ; Thu, 17 Nov 2005 10:10:59 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zcarhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 10:10:44 -0500 Received: from [127.0.0.1] ([47.130.16.223] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 10:10:43 -0500 Message-ID: <437C9D6F.9040504@nortel.com> Date: Thu, 17 Nov 2005 10:10:39 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) 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-OriginalArrivalTime: 17 Nov 2005 15:10:43.0891 (UTC) FILETIME=[149E9030:01C5EB89] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Subject: [Ecrit] E911 security issues X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org We talked ourselves to a standstill in the meeting when discussing security issues. The fundamental problem is this: -- the system has to accept all calls because they could be real emergencies; -- even without internet access, the system receives a high volume of false alarms. A newspaper article in the Ottawa Citizen today reflects an attempt by local authorities to educate people so they will treat their 911 service more seriously. People will be able to visit the PSAP on Nov. 29 to hear the crazy calls that come in. "Probably five to nine percent are legitimate police emergencies, or calls requiring police response. The rest of them are generally requests for information, or misdials." It seems to me we can respond by setting two kinds of requirement for the call routing system: (1) Ensure that it provides all the information that could possibly be useful in automated analysis of incoming calls, so that questionable calls can at least be flagged when they are presented to the call taker. (2) Build robustness into the call routing system. For example, ensure that components of the routing system can shed load intelligently (i.e. perform triage based on call data) when subjected to volumes of traffic beyond what they can handle. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 17 13:14:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcoH4-0004IN-W7; Thu, 17 Nov 2005 13:14:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcoH3-0004II-7e for ecrit@megatron.ietf.org; Thu, 17 Nov 2005 13:14:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11530 for ; Thu, 17 Nov 2005 13:13:42 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcoYh-0003Wb-VF for ecrit@ietf.org; Thu, 17 Nov 2005 13:32:34 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 17 Nov 2005 13:14:06 -0500 X-IronPort-AV: i="3.97,343,1125892800"; d="scan'208"; a="76005116:sNHT24486504" 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 jAHIDLmP017698; Thu, 17 Nov 2005 13:14:03 -0500 (EST) 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); Thu, 17 Nov 2005 13:13:54 -0500 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] E911 security issues Date: Thu, 17 Nov 2005 13:13:53 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3C70010@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] E911 security issues Thread-Index: AcXrijqpO0ekd9dATaG6VBYJnAjquwAF4ErQ From: "Michael Hammer \(mhammer\)" To: "Tom-PT Taylor" , X-OriginalArrivalTime: 17 Nov 2005 18:13:54.0217 (UTC) FILETIME=[AB5D3990:01C5EBA2] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tom, You could provide some means of assessing a penalty ($) to calls that do not rise to the level of what the responders would consider an emergency such that users would think twice the next time. But, that would also require some clear guidelines from authorities to make it stick. (For example, does a call to report a traffic light outage at a dangerous intersection with near-hits occurring count, or do you need to wait for an accident?) However, the criteria that the below text suggests is beyond the level of current technology. You need a human to do triage. Do you rate subsequent calls from a given location area as false alarms because of a cry wolf syndrome, or do you rate them as more likely true alarms because it is a high crime rate area. What is your measurement? Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Tom-PT Taylor > Sent: Thursday, November 17, 2005 10:11 AM > To: ecrit@ietf.org > Subject: [Ecrit] E911 security issues >=20 > We talked ourselves to a standstill in the meeting when=20 > discussing security issues. The fundamental problem is this: >=20 > -- the system has to accept all calls because they could=20 > be real emergencies; >=20 > -- even without internet access, the system receives a=20 > high volume of false alarms. A newspaper article in the=20 > Ottawa Citizen today reflects an attempt by local authorities=20 > to educate people so they will treat their 911 service more=20 > seriously. People will be able to visit the PSAP on Nov. 29=20 > to hear the crazy calls that come in. "Probably five to nine=20 > percent are legitimate police emergencies, or calls requiring=20 > police response. The rest of them are generally requests for=20 > information, or misdials." >=20 > It seems to me we can respond by setting two kinds of=20 > requirement for the call routing system: >=20 > (1) Ensure that it provides all the information that could=20 > possibly be useful in automated analysis of incoming calls,=20 > so that questionable calls can at least be flagged when they=20 > are presented to the call taker. >=20 > (2) Build robustness into the call routing system. For=20 > example, ensure that components of the routing system can=20 > shed load intelligently (i.e. perform triage based on call=20 > data) when subjected to volumes of traffic beyond what they=20 > can handle. >=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 Nov 17 13:32:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcoYM-0002Uf-TL; Thu, 17 Nov 2005 13:32:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcoYK-0002UU-VL for ecrit@megatron.ietf.org; Thu, 17 Nov 2005 13:32:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12525 for ; Thu, 17 Nov 2005 13:31:34 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecoq1-000498-NQ for ecrit@ietf.org; Thu, 17 Nov 2005 13:50:26 -0500 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jAHIVpWk024038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Nov 2005 13:31:52 -0500 (EST) Message-ID: <437CCC40.4060604@cs.columbia.edu> Date: Thu, 17 Nov 2005 13:30:24 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Ecrit] E911 security issues References: <072C5B76F7CEAB488172C6F64B30B5E3C70010@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3C70010@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_TINHORN 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: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org In some jurisdictions, you will get fined if your home alarm system causes too many false alarms. I think we're now well beyond protocol and systems issues into operational issues. I'm guessing that most PSAPs don't want to fine 6-year olds that accidentally dial 911. Michael Hammer (mhammer) wrote: > Tom, > > You could provide some means of assessing a penalty ($) to calls that do > not rise to the level of what the responders would consider an emergency > such that users would think twice the next time. But, that would also > require some clear guidelines from authorities to make it stick. (For > example, does a call to report a traffic light outage at a dangerous > intersection with near-hits occurring count, or do you need to wait for > an accident?) > > However, the criteria that the below text suggests is beyond the level > of current technology. You need a human to do triage. > > Do you rate subsequent calls from a given location area as false alarms > because of a cry wolf syndrome, or do you rate them as more likely true > alarms because it is a high crime rate area. What is your measurement? > > Mike > > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>On Behalf Of Tom-PT Taylor >>Sent: Thursday, November 17, 2005 10:11 AM >>To: ecrit@ietf.org >>Subject: [Ecrit] E911 security issues >> >>We talked ourselves to a standstill in the meeting when >>discussing security issues. The fundamental problem is this: >> >> -- the system has to accept all calls because they could >>be real emergencies; >> >> -- even without internet access, the system receives a >>high volume of false alarms. A newspaper article in the >>Ottawa Citizen today reflects an attempt by local authorities >>to educate people so they will treat their 911 service more >>seriously. People will be able to visit the PSAP on Nov. 29 >>to hear the crazy calls that come in. "Probably five to nine >>percent are legitimate police emergencies, or calls requiring >>police response. The rest of them are generally requests for >>information, or misdials." >> >>It seems to me we can respond by setting two kinds of >>requirement for the call routing system: >> >> (1) Ensure that it provides all the information that could >>possibly be useful in automated analysis of incoming calls, >>so that questionable calls can at least be flagged when they >>are presented to the call taker. >> >> (2) Build robustness into the call routing system. For >>example, ensure that components of the routing system can >>shed load intelligently (i.e. perform triage based on call >>data) when subjected to volumes of traffic beyond what they >>can handle. >> >> >>_______________________________________________ >>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 Nov 17 13:39:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcofP-00058F-8h; Thu, 17 Nov 2005 13:39:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcofO-000585-3e for ecrit@megatron.ietf.org; Thu, 17 Nov 2005 13:39:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12960 for ; Thu, 17 Nov 2005 13:38:51 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecox4-0004P8-0L for ecrit@ietf.org; Thu, 17 Nov 2005 13:57:43 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 17 Nov 2005 10:39:16 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,343,1125903600"; d="scan'208"; a="15471351:sNHT23703220" 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 jAHIcwm3022772; Thu, 17 Nov 2005 13:39:13 -0500 (EST) 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); Thu, 17 Nov 2005 13:39:07 -0500 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] E911 security issues Date: Thu, 17 Nov 2005 13:39:07 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3C70030@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] E911 security issues Thread-Index: AcXrpTrh9OgShai+Rq+xTW0jGJwCoAAAMb/w From: "Michael Hammer \(mhammer\)" To: "Henning Schulzrinne" X-OriginalArrivalTime: 17 Nov 2005 18:39:07.0758 (UTC) FILETIME=[318140E0:01C5EBA6] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Agree. I am in such an area. BTW, 6-year-olds don't pay fines, their parents do. Nor do puppies that set off motion detectors. Again, I know from experience. :) Mike=20 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Sent: Thursday, November 17, 2005 1:30 PM > To: Michael Hammer (mhammer) > Cc: Tom-PT Taylor; ecrit@ietf.org > Subject: Re: [Ecrit] E911 security issues >=20 > In some jurisdictions, you will get fined if your home alarm=20 > system causes too many false alarms. I think we're now well=20 > beyond protocol and systems issues into operational issues.=20 > I'm guessing that most PSAPs don't want to fine 6-year olds=20 > that accidentally dial 911. >=20 > Michael Hammer (mhammer) wrote: > > Tom, > >=20 > > You could provide some means of assessing a penalty ($) to=20 > calls that=20 > > do not rise to the level of what the responders would consider an=20 > > emergency such that users would think twice the next time. =20 > But, that=20 > > would also require some clear guidelines from authorities=20 > to make it=20 > > stick. (For example, does a call to report a traffic light=20 > outage at=20 > > a dangerous intersection with near-hits occurring count, or do you=20 > > need to wait for an accident?) > >=20 > > However, the criteria that the below text suggests is=20 > beyond the level=20 > > of current technology. You need a human to do triage. > >=20 > > Do you rate subsequent calls from a given location area as false=20 > > alarms because of a cry wolf syndrome, or do you rate them as more=20 > > likely true alarms because it is a high crime rate area. =20 > What is your measurement? > >=20 > > Mike > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > >>Of Tom-PT Taylor > >>Sent: Thursday, November 17, 2005 10:11 AM > >>To: ecrit@ietf.org > >>Subject: [Ecrit] E911 security issues > >> > >>We talked ourselves to a standstill in the meeting when discussing=20 > >>security issues. The fundamental problem is this: > >> > >> -- the system has to accept all calls because they could be real=20 > >>emergencies; > >> > >> -- even without internet access, the system receives a=20 > high volume=20 > >>of false alarms. A newspaper article in the Ottawa Citizen today=20 > >>reflects an attempt by local authorities to educate people so they=20 > >>will treat their 911 service more seriously. People will=20 > be able to=20 > >>visit the PSAP on Nov. 29 to hear the crazy calls that come in. =20 > >>"Probably five to nine percent are legitimate police=20 > emergencies, or=20 > >>calls requiring police response. The rest of them are generally=20 > >>requests for information, or misdials." > >> > >>It seems to me we can respond by setting two kinds of=20 > requirement for=20 > >>the call routing system: > >> > >> (1) Ensure that it provides all the information that=20 > could possibly=20 > >>be useful in automated analysis of incoming calls, so that=20 > >>questionable calls can at least be flagged when they are=20 > presented to=20 > >>the call taker. > >> > >> (2) Build robustness into the call routing system. For example,=20 > >>ensure that components of the routing system can shed load=20 > >>intelligently (i.e. perform triage based on call > >>data) when subjected to volumes of traffic beyond what they can=20 > >>handle. > >> > >> > >>_______________________________________________ > >>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 Mon Nov 21 07:34:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeAsK-00019S-T1; Mon, 21 Nov 2005 07:34:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeAsJ-00019N-6b for ecrit@megatron.ietf.org; Mon, 21 Nov 2005 07:34:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25621 for ; Mon, 21 Nov 2005 07:33:44 -0500 (EST) From: steve.norreys@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeBAi-000145-Nm for ecrit@ietf.org; Mon, 21 Nov 2005 07:53:27 -0500 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 12:34:00 +0000 Received: from i2km08-ukbr.domain1.systemhost.net ([193.113.197.82]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 21 Nov 2005 12:34:00 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] E911 security issues Date: Mon, 21 Nov 2005 12:33:59 -0000 Message-ID: <9D598A34672DF24F89FF4F851A416195153E2180@i2km08-ukbr.domain1.systemhost.net> Thread-Topic: [Ecrit] E911 security issues Thread-Index: AcXrpTrh9OgShai+Rq+xTW0jGJwCoAAAMb/wALpobmA= To: , , X-OriginalArrivalTime: 21 Nov 2005 12:34:00.0170 (UTC) FILETIME=[D9379CA0:01C5EE97] X-Spam-Score: 0.3 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Mike, Henning The issue of fines or criminal prosecution for misuse of emergency sessions/calls is a matter for the regulatory authority of the region where the session/call is made. This will be different for every area e.g. in the uk it is very unusual for an alarm to involve the emergency PSAP as they are either directly connected to the emergency service (fire / police / ambulance) required or via a third party security service which contact the PSAP emergency services after the alarm has been verified.=20 A problem with the traffic lights signalling is not a real issue for the Emergency services, but the signals could be directly connected to the authority that deals with traffic along with any road cameras etc. This point could then be directly connected to the PSAP, or could raise the alarm with the emergency services directly? However Tom's email does raise a number of points that needs to be taken into account when designing the emergency service communication services security capabilities:- 1: A 6 year old or younger must be able to use the emergency communications services (how many times is it reported that some small kid saved a parent by phoning 999/911/112 saying they can't wake mummy/daddy). In other words every device available to the 6 year old to be able to make an emergency communication has to have little or no user authorisation (passwords pins etc.) to be useful. 2: I can also confirm that the report from Tom that the 5% - 9% of calls reaching a PSAP are genuine emergency calls is not unusual so the two requirements from Tom for the call routeing system need to be examined (1) fully agree that all information is made available to emergency calls/sessions and a flag raised against any possible questionable calls. The confirmation of a questionable emergency call/session can only be done by the PSAP operator I cannot see this being automated as yet (I could be wrong here?) (2) The robustness by shedding load intelligently I don't know what this means, (i) all flagged calls/sessions shed (even if not sure they are genuine emergency calls/sessions) (ii) A last in first shed basis (iii) a system based upon a region/area blocking so that all calls from a part of a motorway are blocked if a major incident occurs which may block a emergency not connected to the incident. If these three examples are what is meant by shedding load intelligently then perhaps they can go into the document but a warning needs to be added that they are subject to regulatory/legal and network restraints. Regards Steve -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Michael Hammer (mhammer) Sent: 17 November 2005 18:39 To: Henning Schulzrinne Cc: ecrit@ietf.org Subject: RE: [Ecrit] E911 security issues Agree. I am in such an area. BTW, 6-year-olds don't pay fines, their parents do. Nor do puppies that set off motion detectors. Again, I know from experience. :) Mike=20 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, November 17, 2005 1:30 PM > To: Michael Hammer (mhammer) > Cc: Tom-PT Taylor; ecrit@ietf.org > Subject: Re: [Ecrit] E911 security issues >=20 > In some jurisdictions, you will get fined if your home alarm > system causes too many false alarms. I think we're now well=20 > beyond protocol and systems issues into operational issues.=20 > I'm guessing that most PSAPs don't want to fine 6-year olds=20 > that accidentally dial 911. >=20 > Michael Hammer (mhammer) wrote: > > Tom, > >=20 > > You could provide some means of assessing a penalty ($) to > calls that > > do not rise to the level of what the responders would consider an > > emergency such that users would think twice the next time. =20 > But, that > > would also require some clear guidelines from authorities > to make it > > stick. (For example, does a call to report a traffic light > outage at > > a dangerous intersection with near-hits occurring count, or do you > > need to wait for an accident?) > >=20 > > However, the criteria that the below text suggests is > beyond the level > > of current technology. You need a human to do triage. > >=20 > > Do you rate subsequent calls from a given location area as false > > alarms because of a cry wolf syndrome, or do you rate them as more=20 > > likely true alarms because it is a high crime rate area. =20 > What is your measurement? > >=20 > > Mike > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > >>Of Tom-PT Taylor > >>Sent: Thursday, November 17, 2005 10:11 AM > >>To: ecrit@ietf.org > >>Subject: [Ecrit] E911 security issues > >> > >>We talked ourselves to a standstill in the meeting when discussing > >>security issues. The fundamental problem is this: > >> > >> -- the system has to accept all calls because they could be real > >>emergencies; > >> > >> -- even without internet access, the system receives a > high volume > >>of false alarms. A newspaper article in the Ottawa Citizen today > >>reflects an attempt by local authorities to educate people so they=20 > >>will treat their 911 service more seriously. People will=20 > be able to > >>visit the PSAP on Nov. 29 to hear the crazy calls that come in. > >>"Probably five to nine percent are legitimate police=20 > emergencies, or > >>calls requiring police response. The rest of them are generally > >>requests for information, or misdials." > >> > >>It seems to me we can respond by setting two kinds of > requirement for > >>the call routing system: > >> > >> (1) Ensure that it provides all the information that > could possibly > >>be useful in automated analysis of incoming calls, so that > >>questionable calls can at least be flagged when they are=20 > presented to > >>the call taker. > >> > >> (2) Build robustness into the call routing system. For example, > >>ensure that components of the routing system can shed load=20 > >>intelligently (i.e. perform triage based on call > >>data) when subjected to volumes of traffic beyond what they can=20 > >>handle. > >> > >> > >>_______________________________________________ > >>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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 21 09:49:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeCyi-0007Ow-7i; Mon, 21 Nov 2005 09:49:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeCyg-0007Oo-AT for ecrit@megatron.ietf.org; Mon, 21 Nov 2005 09:49:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05311 for ; Mon, 21 Nov 2005 09:48:27 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeDH6-0005BU-Gp for ecrit@ietf.org; Mon, 21 Nov 2005 10:08:09 -0500 Received: from zrtphxm0.corp.nortel.com (zrtphxm0.corp.nortel.com [47.140.202.49]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jALEmi127291; Mon, 21 Nov 2005 09:48:45 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zrtphxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 09:48:42 -0500 Received: from [127.0.0.1] ([47.130.18.223] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 09:48:41 -0500 Message-ID: <4381DE40.6080401@nortel.com> Date: Mon, 21 Nov 2005 09:48:32 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: steve.norreys@bt.com Subject: Re: [Ecrit] E911 security issues References: <9D598A34672DF24F89FF4F851A416195153E2180@i2km08-ukbr.domain1.systemhost.net> In-Reply-To: <9D598A34672DF24F89FF4F851A416195153E2180@i2km08-ukbr.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2005 14:48:41.0261 (UTC) FILETIME=[A9EC3DD0:01C5EEAA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Load shedding is, of course, something to avoid if at all possible, and obviously something to avoid unless there is no choice. What I had in mind was particularly your third alternative below. Obviously it is better to queue calls with a display of relevant information so call-takers can do the sorting. steve.norreys@bt.com wrote: ... > ... (2) The robustness by > shedding load intelligently I don't know what this means, (i) all > flagged calls/sessions shed (even if not sure they are genuine emergency > calls/sessions) (ii) A last in first shed basis (iii) a system based > upon a region/area blocking so that all calls from a part of a motorway > are blocked if a major incident occurs which may block a emergency not > connected to the incident. If these three examples are what is meant by > shedding load intelligently then perhaps they can go into the document > but a warning needs to be added that they are subject to > regulatory/legal and network restraints. > > Regards > > Steve > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 21 13:26:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGNH-0006zL-Sp; Mon, 21 Nov 2005 13:26:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGNG-0006yz-4P for ecrit@megatron.ietf.org; Mon, 21 Nov 2005 13:26:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20488 for ; Mon, 21 Nov 2005 13:26:03 -0500 (EST) Received: from zproxy.gmail.com ([64.233.162.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeGfk-0003AE-A0 for ecrit@ietf.org; Mon, 21 Nov 2005 13:45:49 -0500 Received: by zproxy.gmail.com with SMTP id 8so731457nzo for ; Mon, 21 Nov 2005 10:26:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=F9OMenAq/OXRK+RmIJAOGT0Tj467lQn7Pf0FkOMvEqUhXCXVQaOr+BV4Vw3taKGnUbpG+GoGgPduJl7XwFviZf9oH5noxD6+VHM+eUCte2U7VA8sOnIU/Lqmw/aUwdzcm9Aa1CPGe5AVVlxVMlw8UukxG01ECyCUsJyIt61MAlw= Received: by 10.36.177.11 with SMTP id z11mr3242742nze; Mon, 21 Nov 2005 10:26:39 -0800 (PST) Received: by 10.36.58.15 with HTTP; Mon, 21 Nov 2005 10:26:39 -0800 (PST) Message-ID: <181f29c0511211026j4473f685g21d2e89d3edaaebb@mail.gmail.com> Date: Mon, 21 Nov 2005 13:26:39 -0500 From: Nate Wilcox To: Tom-PT Taylor Subject: Re: [Ecrit] E911 security issues In-Reply-To: <437C9D6F.9040504@nortel.com> MIME-Version: 1.0 References: <437C9D6F.9040504@nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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="===============1056589495==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============1056589495== Content-Type: multipart/alternative; boundary="----=_Part_14951_14597096.1132597599745" ------=_Part_14951_14597096.1132597599745 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Tom, You stated: " (1) Ensure that it provides all the information that could possibly be useful in automated analysis of incoming calls, so that questionable calls can at least be flagged when they are presented to the call taker." Could you elaborate on how this automated analysis "could" work? Nate Wilcox 802.748.5503 ------=_Part_14951_14597096.1132597599745 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Tom,
 
You stated:
 
" (1) Ensure that it provides all the information that could= possibly be useful in automated analysis of incoming calls, so that questi= onable calls can at least be flagged when they are presented to the call ta= ker."
 
Could you elaborate on how this automated analysis "could" w= ork?
 
Nate Wilcox
802.748.5503
------=_Part_14951_14597096.1132597599745-- --===============1056589495== 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 --===============1056589495==-- From ecrit-bounces@ietf.org Mon Nov 21 16:41:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeJPn-0008Bj-6r; Mon, 21 Nov 2005 16:41:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeJPl-0008BO-2p for ecrit@megatron.ietf.org; Mon, 21 Nov 2005 16:41:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15837 for ; Mon, 21 Nov 2005 16:40:51 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeJiG-0003bw-J3 for ecrit@ietf.org; Mon, 21 Nov 2005 17:00:38 -0500 Received: from zcarhxp0.corp.nortel.com (zcarhxp0.corp.nortel.com [47.129.230.91]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jALLfEn13302; Mon, 21 Nov 2005 16:41:15 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 16:41:14 -0500 Received: from [127.0.0.1] ([47.130.18.223] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 16:41:14 -0500 Message-ID: <43823EF5.40805@nortel.com> Date: Mon, 21 Nov 2005 16:41:09 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Wilcox Subject: Re: [Ecrit] E911 security issues References: <437C9D6F.9040504@nortel.com> <181f29c0511211026j4473f685g21d2e89d3edaaebb@mail.gmail.com> In-Reply-To: <181f29c0511211026j4473f685g21d2e89d3edaaebb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2005 21:41:14.0232 (UTC) FILETIME=[4BD7DF80:01C5EEE4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Obvious criteria are no location in signalling, location in signalling not in PSAP jurisdictional area, no authenticated identity. Getting more sophisticated, it might or might not be worthwhile to identify repeated calls from the same caller or address within the last 24 hours. Depending on how high the flagging threshold is, repeated calls may increase call priority or, past a certain point which should be set high enough, be a fairly clear sign of misuse. Nate Wilcox wrote: > Tom, > You stated: > " (1) Ensure that it provides all the information that could possibly be > useful in automated analysis of incoming calls, so that questionable calls > can at least be flagged when they are presented to the call taker." > Could you elaborate on how this automated analysis "could" work? > Nate Wilcox > 802.748.5503 > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 21 17:53:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeKXR-00009N-JQ; Mon, 21 Nov 2005 17:53:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeKXP-000097-TK for ecrit@megatron.ietf.org; Mon, 21 Nov 2005 17:53:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22962 for ; Mon, 21 Nov 2005 17:52:49 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeKpw-0006CC-BR for ecrit@ietf.org; Mon, 21 Nov 2005 18:12:37 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 16:53:17 -0600 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 21 Nov 2005 16:53:17 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 16:53:16 -0600 Message-ID: From: "Winterbottom, James" To: "Tom-PT Taylor" , "Nate Wilcox" Date: Mon, 21 Nov 2005 16:53:15 -0600 Subject: RE: [Ecrit] E911 security issues 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-OriginalArrivalTime: 21 Nov 2005 22:53:16.0566 (UTC) FILETIME=[5C27B360:01C5EEEE] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] E911 security issues Thread-Index: AcXu5IoylGGxfRMUR36j7gZMhITY3AACSeBA X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Tom, To be clear are you expecting these data to be measured and maintained by a proxy making use of an LCMS or the such like, for example a call-server of some sort? If so I understand how you might keep them, but I am not sure how you would convey this data to the PSPA gateway proxy except by possibly introducing a new SIP header or the like *runs for cover*. I guess I am not sure how you would maintain this information in the case where the client went straight to an LCMS and determined the destination itself. I think that there is a clear difference here, and we probably need to make the two scenarios obvious in terms of what options and safe guards can be taken. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Tom-PT Taylor > Sent: Tuesday, 22 November 2005 8:41 AM > To: Nate Wilcox > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] E911 security issues >=20 > Obvious criteria are no location in signalling, location in signalling > not in PSAP jurisdictional area, no authenticated identity. >=20 > Getting more sophisticated, it might or might not be worthwhile to > identify repeated calls from the same caller or address within the last > 24 hours. Depending on how high the flagging threshold is, repeated > calls may increase call priority or, past a certain point which should > be set high enough, be a fairly clear sign of misuse. >=20 > Nate Wilcox wrote: > > Tom, > > You stated: > > " (1) Ensure that it provides all the information that could possibly > be > > useful in automated analysis of incoming calls, so that questionable > calls > > can at least be flagged when they are presented to the call taker." > > Could you elaborate on how this automated analysis "could" work? > > Nate Wilcox > > 802.748.5503 > > >=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 Mon Nov 21 18:11:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeKoe-0005OI-Rs; Mon, 21 Nov 2005 18:11:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeKod-0005Mn-W1 for ecrit@megatron.ietf.org; Mon, 21 Nov 2005 18:11:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24690 for ; Mon, 21 Nov 2005 18:10:37 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeL7B-0006ra-Gs for ecrit@ietf.org; Mon, 21 Nov 2005 18:30:25 -0500 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jALNB9Wk006929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Nov 2005 18:11:10 -0500 (EST) Message-ID: <438253B2.4040903@cs.columbia.edu> Date: Mon, 21 Nov 2005 18:09:38 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] E911 security issues 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='__C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_TINHORN 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: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org My assumption would be that the proxy serving the PSAP or a group of PSAPs would tabulate this information and then label calls based on their probability of being inadvertent, malicious or otherwise suspect. Labeling can be done in any number of ways, from something simple like a request URI like sip:psap-suspicious@psap.state.gov to a new P- header. This information is only used within a single trust domain, so it doesn't have to be standardized. This is not fundamentally different from the various spam filter headers that email MTAs add to messages today, without great difficulty. Maybe later, we'll develop general content labeling headers for spam/spit control and this work might apply here as well. Henning Winterbottom, James wrote: > Tom, > > To be clear are you expecting these data to be measured and maintained > by a proxy making use of an LCMS or the such like, for example a > call-server of some sort? If so I understand how you might keep them, > but I am not sure how you would convey this data to the PSPA gateway > proxy except by possibly introducing a new SIP header or the like *runs > for cover*. > > I guess I am not sure how you would maintain this information in the > case where the client went straight to an LCMS and determined the > destination itself. I think that there is a clear difference here, and > we probably need to make the two scenarios obvious in terms of what > options and safe guards can be taken. > > Cheers > James > > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > Of > >>Tom-PT Taylor >>Sent: Tuesday, 22 November 2005 8:41 AM >>To: Nate Wilcox >>Cc: ecrit@ietf.org >>Subject: Re: [Ecrit] E911 security issues >> >>Obvious criteria are no location in signalling, location in signalling >>not in PSAP jurisdictional area, no authenticated identity. >> >>Getting more sophisticated, it might or might not be worthwhile to >>identify repeated calls from the same caller or address within the > > last > >>24 hours. Depending on how high the flagging threshold is, repeated >>calls may increase call priority or, past a certain point which should >>be set high enough, be a fairly clear sign of misuse. >> >>Nate Wilcox wrote: >> >>>Tom, >>> You stated: >>> " (1) Ensure that it provides all the information that could > > possibly > >>be >> >>>useful in automated analysis of incoming calls, so that questionable >> >>calls >> >>>can at least be flagged when they are presented to the call taker." >>> Could you elaborate on how this automated analysis "could" work? >>> Nate Wilcox >>>802.748.5503 >>> >> >> >>_______________________________________________ >>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 Nov 21 19:21:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeLv1-0006qt-M6; Mon, 21 Nov 2005 19:21:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeLv1-0006qo-6U for ecrit@megatron.ietf.org; Mon, 21 Nov 2005 19:21:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08353 for ; Mon, 21 Nov 2005 19:21:16 -0500 (EST) Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EeMDV-0003Gq-Rl for ecrit@ietf.org; Mon, 21 Nov 2005 19:41:05 -0500 Received: (qmail invoked by alias); 22 Nov 2005 00:21:41 -0000 Received: from p54985F5E.dip.t-dialin.net (EHLO [192.168.2.102]) [84.152.95.94] by mail.gmx.net (mp018) with SMTP; 22 Nov 2005 01:21:41 +0100 X-Authenticated: #29516787 Message-ID: <43826493.3010008@gmx.net> Date: Tue, 22 Nov 2005 01:21:39 +0100 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: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Review of by Steven Kent X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, Steven Kent reviewed . As part of his review he provided comments throughout the entire document (fixing language issues etc.). Finally, he concluded with the following statements: ------ Frankly, the document should be re-written from scratch, preferably from a different perspective. I'd suggest the following format: 1. start with a brief description of all the steps and entities involved in an emergency call. (maybe do this for the PSTN, the extend to VoIP.) 2. discuss what the emergency call system relies on to function correctly, e.g., in the absence of attacks, i.e., a correct/secure operation model. 3. describe the threats model, i.e., classes of adversaries and their motivations and capabilities. 4. now articulate security requirements, motivated by the threat model and the correct/secure operation model. 5. maybe prioritize these requirements. Do not discuss countermeasures in this document. put them in a separate document. there are many places where the discussion of countermeasures was vague or incomplete, and others where the countermeasure description was technically wrong. ------ His review is quite tough but important. We should discuss it. Here are my first response concerning his review: ad 1) To some extend we provide a brief description of the involved entities in the requirements document (although only very brief). It might be useful to extend the description a bit (but i do not want to go into a description about the PSTN world). ad 2) It might be possible to make some statements about the ideal world but i see difficulties doing this since emergency call handling is not an easy system to secure (from a deployment perspective). For example, we might want to state that the identity of the emergency caller should be authentic and the provided location is the "true" location. I am, however, not quite sure how far we could get with these types of statements. ad 3) Regarding the threat model i thinmk it is possible to indicate what the impact of an adversary with regard to its location and its capabilities are. Since there are a number of protocols that are executed in sequence the task might be quite lengthy with a lot of repetition. ad 4) This again might be quite difficult since the ideal requirements are most likely not accomplishable in a real-world environment. For example, authentication of the emergency caller towards the PSAP would be nice from a security point of view, easy to mandate in a specification but quite difficult to accomplish in the real world. In some sense we have this functionality already in the SIP specification with the usage of end-to-end security mechanisms, such as S/MIME or MIKEY/SRTP (for media traffic) in case of SIP. ad 5) It might be difficult to achieve a ranking since every one of us might have a different perception of the threat impacts. Steven's concluding remark about not including any countermeasures sounds reasonable. In some sense we are then back where we came from, namely at: http://www.ietf-ecrit.org/cache/draft-tschofenig-ecrit-security-threats-01.txt Ciao Hannes ps: Steven's editorial review can be found at: http://www.ietf-ecrit.org/TEMP/ecrit-security-threats-00.pdf _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 21 19:53:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeMPe-0001rQ-Qe; Mon, 21 Nov 2005 19:53:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeMPd-0001rE-Cm for ecrit@megatron.ietf.org; Mon, 21 Nov 2005 19:53:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10669 for ; Mon, 21 Nov 2005 19:52:54 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeMiA-0004HC-PZ for ecrit@ietf.org; Mon, 21 Nov 2005 20:12:44 -0500 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAM0rKG26982; Mon, 21 Nov 2005 19:53:20 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zcarhxm2.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 19:53:20 -0500 Received: from [127.0.0.1] ([47.130.18.223] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 19:53:19 -0500 Message-ID: <43826BFA.5090408@nortel.com> Date: Mon, 21 Nov 2005 19:53:14 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Review of by Steven Kent References: <43826493.3010008@gmx.net> In-Reply-To: <43826493.3010008@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2005 00:53:19.0658 (UTC) FILETIME=[218850A0:01C5EEFF] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'll get to work on it. Familiar ground to many of us! Hannes Tschofenig wrote: > Hi all, > > Steven Kent reviewed . As > part of his review he provided comments throughout the entire document > (fixing language issues etc.). Finally, he concluded with the following > statements: > > ------ > > Frankly, the document should be re-written from scratch, preferably > from a different perspective. I'd suggest the following format: > > 1. start with a brief description of all the steps and entities > involved in an emergency call. (maybe do this for the PSTN, the > extend to VoIP.) > > 2. discuss what the emergency call system relies on to function > correctly, e.g., in the absence of attacks, i.e., a correct/secure > operation model. > > 3. describe the threats model, i.e., classes of adversaries and their > motivations and capabilities. > > 4. now articulate security requirements, motivated by the threat > model and the correct/secure operation model. > > 5. maybe prioritize these requirements. > > Do not discuss countermeasures in this document. put them in a > separate document. there are many places where the discussion of > countermeasures was vague or incomplete, and others where the > countermeasure description was technically wrong. > > ------ > > His review is quite tough but important. We should discuss it. > > Here are my first response concerning his review: > > ad 1) To some extend we provide a brief description of the involved > entities in the requirements document (although only very brief). It > might be useful to extend the description a bit (but i do not want to go > into a description about the PSTN world). > > ad 2) It might be possible to make some statements about the ideal world > but i see difficulties doing this since emergency call handling is not > an easy system to secure (from a deployment perspective). For example, > we might want to state that the identity of the emergency caller should > be authentic and the provided location is the "true" location. I am, > however, not quite sure how far we could get with these types of > statements. > > ad 3) Regarding the threat model i thinmk it is possible to indicate > what the impact of an adversary with regard to its location and its > capabilities are. Since there are a number of protocols that are > executed in sequence the task might be quite lengthy with a lot of > repetition. > > ad 4) This again might be quite difficult since the ideal requirements > are most likely not accomplishable in a real-world environment. For > example, authentication of the emergency caller towards the PSAP would > be nice from a security point of view, easy to mandate in a > specification but quite difficult to accomplish in the real world. In > some sense we have this functionality already in the SIP specification > with the usage of end-to-end security mechanisms, such as S/MIME or > MIKEY/SRTP (for media traffic) in case of SIP. > > ad 5) It might be difficult to achieve a ranking since every one of us > might have a different perception of the threat impacts. > > Steven's concluding remark about not including any countermeasures > sounds reasonable. In some sense we are then back where we came from, > namely at: > http://www.ietf-ecrit.org/cache/draft-tschofenig-ecrit-security-threats-01.txt > > > Ciao > Hannes > > ps: Steven's editorial review can be found at: > http://www.ietf-ecrit.org/TEMP/ecrit-security-threats-00.pdf > > > _______________________________________________ > 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 Nov 22 08:30:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYEJ-0008CX-AD; Tue, 22 Nov 2005 08:30:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYEG-00089K-Ph for ecrit@megatron.ietf.org; Tue, 22 Nov 2005 08:30:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16990 for ; Tue, 22 Nov 2005 08:29:57 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeYWv-0003Eo-7v for ecrit@ietf.org; Tue, 22 Nov 2005 08:49:53 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id jAMDUFl1027793; Tue, 22 Nov 2005 14:30:16 +0100 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 jAMDUEwt013966; Tue, 22 Nov 2005 14:30:15 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 22 Nov 2005 14:30:14 +0100 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: AW: [Ecrit] Review of by Steven Kent Date: Tue, 22 Nov 2005 14:30:14 +0100 Message-ID: Thread-Topic: [Ecrit] Review of by Steven Kent Thread-Index: AcXu/0xzGDiS1wewSjGhZ45rwA6keAAZ743Q From: "Tschofenig, Hannes" To: "Tom-PT Taylor" , "Hannes Tschofenig" X-OriginalArrivalTime: 22 Nov 2005 13:30:14.0950 (UTC) FILETIME=[DF27EC60:01C5EF68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi tom,=20 thanks for immediately showing interest to fix the problem. before you = start your editing work we should get an idea what the right approach is = to address steven's feedback.=20 ciao hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > Im Auftrag von Tom-PT Taylor > Gesendet: Dienstag, 22. November 2005 01:53 > An: Hannes Tschofenig > Cc: ecrit@ietf.org > Betreff: Re: [Ecrit] Review of=20 > by Steven Kent >=20 > I'll get to work on it. Familiar ground to many of us! >=20 > Hannes Tschofenig wrote: > > Hi all, > >=20 > > Steven Kent reviewed=20 > . As=20 > > part of his review he provided comments throughout the=20 > entire document=20 > > (fixing language issues etc.). Finally, he concluded with=20 > the following=20 > > statements: > >=20 > > ------ > >=20 > > Frankly, the document should be re-written from scratch, preferably > > from a different perspective. I'd suggest the following format: > >=20 > > 1. start with a brief description of all the steps and entities > > involved in an emergency call. (maybe do this for the PSTN, the > > extend to VoIP.) > >=20 > > 2. discuss what the emergency call system relies on to function > > correctly, e.g., in the absence of attacks, i.e., a correct/secure > > operation model. > >=20 > > 3. describe the threats model, i.e., classes of adversaries=20 > and their > > motivations and capabilities. > >=20 > > 4. now articulate security requirements, motivated by the threat > > model and the correct/secure operation model. > >=20 > > 5. maybe prioritize these requirements. > >=20 > > Do not discuss countermeasures in this document. put them in a > > separate document. there are many places where the discussion of > > countermeasures was vague or incomplete, and others where the > > countermeasure description was technically wrong. > >=20 > > ------ > >=20 > > His review is quite tough but important. We should discuss it. > >=20 > > Here are my first response concerning his review: > >=20 > > ad 1) To some extend we provide a brief description of the involved=20 > > entities in the requirements document (although only very=20 > brief). It=20 > > might be useful to extend the description a bit (but i do=20 > not want to go=20 > > into a description about the PSTN world). > >=20 > > ad 2) It might be possible to make some statements about=20 > the ideal world=20 > > but i see difficulties doing this since emergency call=20 > handling is not=20 > > an easy system to secure (from a deployment perspective).=20 > For example,=20 > > we might want to state that the identity of the emergency=20 > caller should=20 > > be authentic and the provided location is the "true"=20 > location. I am,=20 > > however, not quite sure how far we could get with these types of=20 > > statements. > >=20 > > ad 3) Regarding the threat model i thinmk it is possible to=20 > indicate=20 > > what the impact of an adversary with regard to its location and its=20 > > capabilities are. Since there are a number of protocols that are=20 > > executed in sequence the task might be quite lengthy with a lot of=20 > > repetition. > >=20 > > ad 4) This again might be quite difficult since the ideal=20 > requirements=20 > > are most likely not accomplishable in a real-world environment. For=20 > > example, authentication of the emergency caller towards the=20 > PSAP would=20 > > be nice from a security point of view, easy to mandate in a=20 > > specification but quite difficult to accomplish in the=20 > real world. In=20 > > some sense we have this functionality already in the SIP=20 > specification=20 > > with the usage of end-to-end security mechanisms, such as S/MIME or=20 > > MIKEY/SRTP (for media traffic) in case of SIP. > >=20 > > ad 5) It might be difficult to achieve a ranking since=20 > every one of us=20 > > might have a different perception of the threat impacts. > >=20 > > Steven's concluding remark about not including any countermeasures=20 > > sounds reasonable. In some sense we are then back where we=20 > came from,=20 > > namely at: > >=20 > http://www.ietf-ecrit.org/cache/draft-tschofenig-ecrit-securit > y-threats-01.txt=20 > >=20 > >=20 > > Ciao > > Hannes > >=20 > > ps: Steven's editorial review can be found at: > > http://www.ietf-ecrit.org/TEMP/ecrit-security-threats-00.pdf > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 22 09:01:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYiK-0004Ev-P2; Tue, 22 Nov 2005 09:01:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYiH-0004EZ-GD for ecrit@megatron.ietf.org; Tue, 22 Nov 2005 09:01:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19971 for ; Tue, 22 Nov 2005 09:00:58 -0500 (EST) Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeZ0w-0004k5-2t for ecrit@ietf.org; Tue, 22 Nov 2005 09:20:55 -0500 Received: from [10.0.1.100] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 22 Nov 2005 09:01:01 -0500 id 0158801D.4383249D.000073CE In-Reply-To: <43826493.3010008@gmx.net> References: <43826493.3010008@gmx.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <27B8D44C-A28D-4B84-BE99-8E46DC3FC180@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Review of by Steven Kent Date: Tue, 22 Nov 2005 09:01:13 -0500 To: Hannes Tschofenig X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Nov 21, 2005, at 7:21 PM, Hannes Tschofenig wrote: > Frankly, the document should be re-written from scratch, preferably > from a different perspective. I'd suggest the following format: > > 1. start with a brief description of all the steps and entities > involved in an emergency call. (maybe do this for the PSTN, the > extend to VoIP.) > > 2. discuss what the emergency call system relies on to function > correctly, e.g., in the absence of attacks, i.e., a correct/secure > operation model. > > 3. describe the threats model, i.e., classes of adversaries and their > motivations and capabilities. > > 4. now articulate security requirements, motivated by the threat > model and the correct/secure operation model. > > 5. maybe prioritize these requirements. > > Do not discuss countermeasures in this document. put them in a > separate document. there are many places where the discussion of > countermeasures was vague or incomplete, and others where the > countermeasure description was technically wrong. I have to say that this does sound different than what he was describing at the microphone. > ad 1) To some extend we provide a brief description of the involved > entities in the requirements document (although only very brief). > It might be useful to extend the description a bit (but i do not > want to go into a description about the PSTN world). I'm not in favor of describing the PSTN as well, but if we know of a security issue that would affect the PSTN (such as the one discussed on this list), then we should include them. > ad 2) It might be possible to make some statements about the ideal > world but i see difficulties doing this since emergency call > handling is not an easy system to secure (from a deployment > perspective). For example, we might want to state that the identity > of the emergency caller should be authentic and the provided > location is the "true" location. I am, however, not quite sure how > far we could get with these types of statements. Even if there is no solution to a particular security threat, we ought to document it. > ad 5) It might be difficult to achieve a ranking since every one of > us might have a different perception of the threat impacts. Yeah, that's gonna be one long food fight. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 29 17:36:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhE5I-000411-O9; Tue, 29 Nov 2005 17:36:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhE5I-00040O-AE for ecrit@megatron.ietf.org; Tue, 29 Nov 2005 17:36:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19610 for ; Tue, 29 Nov 2005 17:35:38 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhEPP-00089q-4M for ecrit@ietf.org; Tue, 29 Nov 2005 17:57:14 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id jATMaAVL003845 for ; Tue, 29 Nov 2005 23:36:10 +0100 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 jATMaAim031982 for ; Tue, 29 Nov 2005 23:36:10 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Nov 2005 23:36:08 +0100 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, 29 Nov 2005 23:36:07 +0100 Message-ID: Thread-Topic: meeting minutes thread-index: AcX1MN3L8UdljbHNT3G2nOj2UZOPng== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 29 Nov 2005 22:36:08.0110 (UTC) FILETIME=[4A73C4E0:01C5F535] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] meeting minutes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 please find a first version of the meeting minutes at: http://www.ietf-ecrit.org/IETF64/meeting_minutes.txt the slides can be found at: http://www.ietf-ecrit.org/IETF64/ ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit