From ecrit-bounces@ietf.org Fri Dec 01 12:19:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqC2I-0000P5-18; Fri, 01 Dec 2006 12:18:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqC2G-0000OH-Qs for ecrit@ietf.org; Fri, 01 Dec 2006 12:18:52 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqC2E-0006fn-F3 for ecrit@ietf.org; Fri, 01 Dec 2006 12:18:52 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 01 Dec 2006 09:18:50 -0800 X-IronPort-AV: i="4.09,486,1157353200"; d="scan'208"; a="89534744:sNHT68524776" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kB1HIn4C028762 for ; Fri, 1 Dec 2006 09:18:49 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB1HInio011272 for ; Fri, 1 Dec 2006 09:18:49 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 09:18:49 -0800 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 09:18:49 -0800 From: "Marc Linsner" To: Date: Fri, 1 Dec 2006 12:18:43 -0500 Message-ID: <00b201c7156c$c115c870$200d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccVTNBCE5QtTltfRR2yNWhJFg30rwABDwwgAAbDQKA= X-OriginalArrivalTime: 01 Dec 2006 17:18:49.0590 (UTC) FILETIME=[C4366960:01C7156C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2096; t=1164993529; x=1165857529; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20FW=3A=20[NENA-ltd]=20LoST |Sender:=20; bh=TJn9yr0OtttMR+v7gG6tSOCWs14reCKCqSc7fSrUboI=; b=VvpIKG7SxyWIJnQ+EWRmcwYN1dvIBdF2LXC4hMaj14FuA6rPCH/QuQbu4YK5e40yNSS70+Aq EDaBNbWVDM4nHgd7lO4QLxcavtlLQIrBeDLjozak3v6xyhsw2hULiP+7; Authentication-Results: sj-dkim-3; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [Ecrit] FW: [NENA-ltd] LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The NENA Long Term Definition work group has been closely following the LoST work evidenced by early requirements Terry's concerns a week or two ago. I again queried that group to see if they have any outstanding issues with Terry's concerns, or any additional. Hence I forwarded below (with permission) Pierre's question about Relax NG. Thanks, -Marc- -----Original Message----- From: Desjardins, Pierre [mailto:pdesjardins@positron911.com] Sent: Friday, December 01, 2006 9:28 AM To: Marc Linsner; nena-ltd@cs.columbia.edu Subject: RE: [NENA-ltd] LoST Marc, I have no further issues with regards to Terry's concerns, however I did voice a negative comment about the choice of RELAX NG as the schema language for defining LoST messages. I have been around XML for a very long time and this is not about the merits of one schema language over another but rather about making life easier for future implementers. Like it or not, W3C XML Schema (WXS) is the mainstream XML schema language and it shows in the multiplicity and diversity of tools out there (commercial or otherwise). The geopriv schemas were are all published using WXS which I believe favored accelerated adoption. It seems to me that we all want the same benefit for LoST. I am willing to help with putting a WXS version together -- I may even be able to come up with a skeleton schema this weekend... What do you think? /Pier -----Original Message----- From: nena-ltd-bounces@cs.columbia.edu [mailto:nena-ltd-bounces@cs.columbia.edu] On Behalf Of Marc Linsner Sent: Friday, December 01, 2006 8:30 AM To: nena-ltd@cs.columbia.edu Subject: [NENA-ltd] LoST All, Sorry I couldn't make yesterday's call. I am curious if discussion took place wrt Terry's questions/concerns about LoST. Is this community satisfied with responses to those concerns? Are there still open issues? Thanks, -Marc- _______________________________________________ Nena-ltd mailing list Nena-ltd@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/nena-ltd _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Dec 01 19:05:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqIMr-0005kk-EL; Fri, 01 Dec 2006 19:04:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqIMq-0005ka-Ar for ecrit@ietf.org; Fri, 01 Dec 2006 19:04:32 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqIMp-00020d-2t for ecrit@ietf.org; Fri, 01 Dec 2006 19:04:32 -0500 Received: from [127.0.0.1] (play.cs.columbia.edu [128.59.21.100]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kB204PLu019247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 1 Dec 2006 19:04:30 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <83A3DE78-9218-4D40-9679-6B1A5EBFD7E6@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "Ecrit@Ietf.Org" From: Henning Schulzrinne Date: Fri, 1 Dec 2006 08:58:19 -0500 X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.7 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Ecrit] Later call-back X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'll raise an issue that Hannes has mentioned to me: callback by the PSAP later. This is actually a general problem, as it would be nice for my home proxy to recognize a callback, as I may have special policies for handling such calls (automatic whitelist, bypass call treatments such as forwarding to voice mail, etc.) Since we don't assume that the original emergency call traverses the home proxy, this has to be stateless, i.e., the PSAP needs to get all the information to convince the home agent that this is indeed an (emergency) callback. Thus, in general, the caller needs to provide the PSAP with some kind of encrypted token that the home proxy can recognize. This does not require setting up a new secret, since the Digest secret can be-reused for that. There seem to be several options: (1) In-Reply-To: If the call-ID is recognizable as an emergency call, the home proxy can perform appropriate call treatments. (For example, some encrypted version of this information.) This seems like a kludge. (2) GRUU: Some special GRUU, with the same basic properties and problem as (1). (3) marked call to Contact or AOR: some kind of "I'm a PSAP" certificate, with all the usual deployment problems. (4) New header or Contact parameter: Basically, the caller provides the callee with a token that they can present later to prove that the call is "special". This seems closely related to the REFER problem and maybe we can re-use some of the same techniques. Any other suggestions? Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Dec 01 20:44:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqJvF-00052w-M6; Fri, 01 Dec 2006 20:44:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqJvE-00052j-9u for ecrit@ietf.org; Fri, 01 Dec 2006 20:44:08 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqJvB-0007xR-Uw for ecrit@ietf.org; Fri, 01 Dec 2006 20:44:08 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 01 Dec 2006 20:43:41 -0500 id 015880D8.4570DA4D.00000C4A In-Reply-To: <00b201c7156c$c115c870$200d0d0a@amer.cisco.com> References: <00b201c7156c$c115c870$200d0d0a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E67A84B-1014-4387-BF44-2E8E67AD7CC7@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] FW: [NENA-ltd] LoST Date: Fri, 1 Dec 2006 20:43:50 -0500 To: Marc Linsner X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org In the IETF RAI area, there is a strong consensus towards moving toward Relax NG and away from XML Schema. This is also echoed by many of the members of the IETF's XML Directorate, most notably Tim Bray -- one of the authors of XML. To be even more specific, the experience within IETF standards with XML Schema has exposed two recurring issues that are solved by Relax NG: 1) The UPA restriction, and 2) readability of XSDs. And to your specific points about existing IETF standards and existing software: 1) It is true that a lot of IETF standards use XML Schema. That is due in part to the fact that XML Schema has been around longer, but also of the mistaken belief that BCP 70 mandated the use of XML Schema in IETF RFCs. BCP 70 actually says no such thing, but this misperception existed for quite some time until the XML Directorate made the clarification. 2) At present, there does exist more software that uses XML Schema than Relax NG. But at one time there was also very little software for XML Schema. As Relax NG heads through the ISO standardization process and more IETF standards emerge that use Relax NG, more software supporting it will appear. -andy On Dec 1, 2006, at 12:18 PM, Marc Linsner wrote: > The NENA Long Term Definition work group has been closely following > the LoST > work evidenced by early requirements Terry's concerns a week or two > ago. > > I again queried that group to see if they have any outstanding > issues with > Terry's concerns, or any additional. Hence I forwarded below (with > permission) Pierre's question about Relax NG. > > Thanks, > > -Marc- > > -----Original Message----- > From: Desjardins, Pierre [mailto:pdesjardins@positron911.com] > Sent: Friday, December 01, 2006 9:28 AM > To: Marc Linsner; nena-ltd@cs.columbia.edu > Subject: RE: [NENA-ltd] LoST > > Marc, > > I have no further issues with regards to Terry's concerns, however > I did > voice a negative comment about the choice of RELAX NG as the schema > language > for defining LoST messages. > > I have been around XML for a very long time and this is not about > the merits > of one schema language over another but rather about making life > easier for > future implementers. > > Like it or not, W3C XML Schema (WXS) is the mainstream XML schema > language > and it shows in the multiplicity and diversity of tools out there > (commercial or otherwise). > > The geopriv schemas were are all published using WXS which I > believe favored > accelerated adoption. It seems to me that we all want the same > benefit for > LoST. > > I am willing to help with putting a WXS version together -- I may > even be > able to come up with a skeleton schema this weekend... > > What do you think? > > /Pier > > -----Original Message----- > From: nena-ltd-bounces@cs.columbia.edu > [mailto:nena-ltd-bounces@cs.columbia.edu] On Behalf Of Marc Linsner > Sent: Friday, December 01, 2006 8:30 AM > To: nena-ltd@cs.columbia.edu > Subject: [NENA-ltd] LoST > > All, > > Sorry I couldn't make yesterday's call. > > I am curious if discussion took place wrt Terry's questions/ > concerns about > LoST. Is this community satisfied with responses to those > concerns? Are > there still open issues? > > > Thanks, > > -Marc- > _______________________________________________ > Nena-ltd mailing list > Nena-ltd@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/nena-ltd > > _______________________________________________ > 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 Dec 01 20:47:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqJyL-00066r-Fe; Fri, 01 Dec 2006 20:47:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqJyK-00066g-FP for ecrit@ietf.org; Fri, 01 Dec 2006 20:47:20 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqJyG-0008Vu-3S for ecrit@ietf.org; Fri, 01 Dec 2006 20:47:20 -0500 Received: from [127.0.0.1] (play.cs.columbia.edu [128.59.21.100]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kB21l9xp009013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 1 Dec 2006 20:47:10 -0500 (EST) In-Reply-To: <9E67A84B-1014-4387-BF44-2E8E67AD7CC7@hxr.us> References: <00b201c7156c$c115c870$200d0d0a@amer.cisco.com> <9E67A84B-1014-4387-BF44-2E8E67AD7CC7@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <07A64EC3-8247-4D85-A22B-36EFD5075CC3@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] FW: [NENA-ltd] LoST Date: Fri, 1 Dec 2006 15:47:12 -0500 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org As a pragmatic matter, creating a non-normative version in XML Schema notation, whether as an IETF draft or not, could be helpful for implementors. After all, it's only a tool, not a religion. On Dec 1, 2006, at 8:43 PM, Andrew Newton wrote: > In the IETF RAI area, there is a strong consensus towards moving > toward Relax NG and away from XML Schema. This is also echoed by > many of the members of the IETF's XML Directorate, most notably Tim > Bray -- one of the authors of XML. > > To be even more specific, the experience within IETF standards with > XML Schema has exposed two recurring issues that are solved by > Relax NG: 1) The UPA restriction, and 2) readability of XSDs. > > And to your specific points about existing IETF standards and > existing software: > > 1) It is true that a lot of IETF standards use XML Schema. That is > due in part to the fact that XML Schema has been around longer, but > also of the mistaken belief that BCP 70 mandated the use of XML > Schema in IETF RFCs. BCP 70 actually says no such thing, but this > misperception existed for quite some time until the XML Directorate > made the clarification. > > 2) At present, there does exist more software that uses XML Schema > than Relax NG. But at one time there was also very little software > for XML Schema. As Relax NG heads through the ISO standardization > process and more IETF standards emerge that use Relax NG, more > software supporting it will appear. > > -andy > > > > On Dec 1, 2006, at 12:18 PM, Marc Linsner wrote: > >> The NENA Long Term Definition work group has been closely >> following the LoST >> work evidenced by early requirements Terry's concerns a week or >> two ago. >> >> I again queried that group to see if they have any outstanding >> issues with >> Terry's concerns, or any additional. Hence I forwarded below (with >> permission) Pierre's question about Relax NG. >> >> Thanks, >> >> -Marc- >> >> -----Original Message----- >> From: Desjardins, Pierre [mailto:pdesjardins@positron911.com] >> Sent: Friday, December 01, 2006 9:28 AM >> To: Marc Linsner; nena-ltd@cs.columbia.edu >> Subject: RE: [NENA-ltd] LoST >> >> Marc, >> >> I have no further issues with regards to Terry's concerns, however >> I did >> voice a negative comment about the choice of RELAX NG as the >> schema language >> for defining LoST messages. >> >> I have been around XML for a very long time and this is not about >> the merits >> of one schema language over another but rather about making life >> easier for >> future implementers. >> >> Like it or not, W3C XML Schema (WXS) is the mainstream XML schema >> language >> and it shows in the multiplicity and diversity of tools out there >> (commercial or otherwise). >> >> The geopriv schemas were are all published using WXS which I >> believe favored >> accelerated adoption. It seems to me that we all want the same >> benefit for >> LoST. >> >> I am willing to help with putting a WXS version together -- I may >> even be >> able to come up with a skeleton schema this weekend... >> >> What do you think? >> >> /Pier >> >> -----Original Message----- >> From: nena-ltd-bounces@cs.columbia.edu >> [mailto:nena-ltd-bounces@cs.columbia.edu] On Behalf Of Marc Linsner >> Sent: Friday, December 01, 2006 8:30 AM >> To: nena-ltd@cs.columbia.edu >> Subject: [NENA-ltd] LoST >> >> All, >> >> Sorry I couldn't make yesterday's call. >> >> I am curious if discussion took place wrt Terry's questions/ >> concerns about >> LoST. Is this community satisfied with responses to those >> concerns? Are >> there still open issues? >> >> >> Thanks, >> >> -Marc- >> _______________________________________________ >> Nena-ltd mailing list >> Nena-ltd@cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/nena-ltd >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Dec 01 20:51:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqK2i-0004YM-PQ; Fri, 01 Dec 2006 20:51:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqK2h-0004KE-Ek for ecrit@ietf.org; Fri, 01 Dec 2006 20:51:51 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqK2g-0001P3-8v for ecrit@ietf.org; Fri, 01 Dec 2006 20:51:51 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 01 Dec 2006 20:51:33 -0500 id 015880CF.4570DC25.00000E26 In-Reply-To: <83A3DE78-9218-4D40-9679-6B1A5EBFD7E6@cs.columbia.edu> References: <83A3DE78-9218-4D40-9679-6B1A5EBFD7E6@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <228CFF69-9D47-4912-A690-E7E148D7A716@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Later call-back Date: Fri, 1 Dec 2006 20:51:45 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "Ecrit@Ietf.Org" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Dec 1, 2006, at 8:58 AM, Henning Schulzrinne wrote: > (4) New header or Contact parameter: Basically, the caller provides > the callee with a token that they can present later to prove that > the call is "special". This seems closely related to the REFER > problem and maybe we can re-use some of the same techniques. This, to me, seems to be the most workable solution. I do worry how such a call back will work with the current peering arrangements. Even when other security mechanisms are in place, nearly every VSP locks peers down by IP address. There would actually be nothing wrong with going directly to the UA, except for those wonderfully handy NATs. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Dec 01 20:54:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqK4m-00086k-Ia; Fri, 01 Dec 2006 20:54:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqK4l-00086e-NQ for ecrit@ietf.org; Fri, 01 Dec 2006 20:53:59 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqK4k-0001z0-H1 for ecrit@ietf.org; Fri, 01 Dec 2006 20:53:59 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 01 Dec 2006 20:53:42 -0500 id 015880CF.4570DCA6.00000EA3 In-Reply-To: <07A64EC3-8247-4D85-A22B-36EFD5075CC3@cs.columbia.edu> References: <00b201c7156c$c115c870$200d0d0a@amer.cisco.com> <9E67A84B-1014-4387-BF44-2E8E67AD7CC7@hxr.us> <07A64EC3-8247-4D85-A22B-36EFD5075CC3@cs.columbia.edu> Mime-Version: 1.0 Message-Id: <1D87E804-88E8-4442-A68D-6A3A0E046A9F@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] FW: [NENA-ltd] LoST Date: Fri, 1 Dec 2006 20:53:56 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) 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="===============0229217957==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0229217957== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-3752-1165024423-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-3752-1165024423-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Dec 1, 2006, at 3:47 PM, Henning Schulzrinne wrote: > As a pragmatic matter, creating a non-normative version in XML > Schema notation, whether as an IETF draft or not, could be helpful > for implementors. After all, it's only a tool, not a religion. Agreed. And when it comes down to nuts and bolts, an implementation requires neither. -andy --=_zeke.ecotroph.net-3752-1165024423-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3
On Dec 1, 2006, at 3:47= PM, Henning Schulzrinne wrote:

As= a pragmatic matter, creating a non-normative version in XML Schema notat= ion, whether as an IETF draft or not, could be helpful for implementors. = After all, it's only a tool, not a religion.


Agreed.=A0 And when it comes down to nuts and bolts, an implem= entation requires neither.

-andy
--=_zeke.ecotroph.net-3752-1165024423-0001-2-- --===============0229217957== 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 --===============0229217957==-- From ecrit-bounces@ietf.org Fri Dec 01 21:04:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqKF6-0002L0-Hu; Fri, 01 Dec 2006 21:04:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqKF5-0002Ki-Ht for ecrit@ietf.org; Fri, 01 Dec 2006 21:04:39 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqKF4-0004Ao-90 for ecrit@ietf.org; Fri, 01 Dec 2006 21:04:39 -0500 Received: from [127.0.0.1] (play.cs.columbia.edu [128.59.21.100]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kB224ZQN013852 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 1 Dec 2006 21:04:36 -0500 (EST) In-Reply-To: <228CFF69-9D47-4912-A690-E7E148D7A716@hxr.us> References: <83A3DE78-9218-4D40-9679-6B1A5EBFD7E6@cs.columbia.edu> <228CFF69-9D47-4912-A690-E7E148D7A716@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <37ADD793-10F6-47EC-961F-6EABD9CDA899@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Later call-back Date: Fri, 1 Dec 2006 16:04:38 -0500 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "Ecrit@Ietf.Org" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Dec 1, 2006, at 8:51 PM, Andrew Newton wrote: > > On Dec 1, 2006, at 8:58 AM, Henning Schulzrinne wrote: >> (4) New header or Contact parameter: Basically, the caller >> provides the callee with a token that they can present later to >> prove that the call is "special". This seems closely related to >> the REFER problem and maybe we can re-use some of the same >> techniques. > > This, to me, seems to be the most workable solution. I agree, but it will require SIP/SIPPING work. I looked at RFC 3892 (Referred-By); while it is indeed similar, it is not directly copyable. In this case, the problem may be slightly simpler, since the UA and the proxy have a trust relationship, so the UA only has to hand something to the PSAP that says "I just made an emergency call". Instead of the S/MIME effort in 3892, something as simple as an HMAC using the Digest secret suffices. > > I do worry how such a call back will work with the current peering > arrangements. Even when other security mechanisms are in place, > nearly every VSP locks peers down by IP address. There would > actually be nothing wrong with going directly to the UA, except for > those wonderfully handy NATs. > I'm not sure I understand. The idea would be that the PSAP would contact the AOR or maybe a GRUU, so it would appear to be a normal phone call to the VSP, assuming it accepts any SIP calls at all. The only reason for the mechanism I discussed was to avoid that the PSAP is auto-forwarded to voicemail due to some call processing rule, particularly the PSAP is unlikely to be on the emergency caller's whitelist. The choice of AOR or GRUU probably depends on the circumstances, such as whether the PSAP wants to reach the person, regardless of device, or the calling device. > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Dec 01 21:30:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqKdQ-0004Kp-H9; Fri, 01 Dec 2006 21:29:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqKdO-0004Ke-VG for ecrit@ietf.org; Fri, 01 Dec 2006 21:29:46 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqKdN-0002lx-Oc for ecrit@ietf.org; Fri, 01 Dec 2006 21:29:46 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 01 Dec 2006 21:29:30 -0500 id 015880CF.4570E50A.00001588 In-Reply-To: <37ADD793-10F6-47EC-961F-6EABD9CDA899@cs.columbia.edu> References: <83A3DE78-9218-4D40-9679-6B1A5EBFD7E6@cs.columbia.edu> <228CFF69-9D47-4912-A690-E7E148D7A716@hxr.us> <37ADD793-10F6-47EC-961F-6EABD9CDA899@cs.columbia.edu> Mime-Version: 1.0 Message-Id: <4A686881-2CCA-4230-957D-F6EF0C794A16@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] Later call-back Date: Fri, 1 Dec 2006 21:29:44 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "Ecrit@Ietf.Org" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2055242267==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============2055242267== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-5514-1165026570-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-5514-1165026570-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Dec 1, 2006, at 4:04 PM, Henning Schulzrinne wrote: > I'm not sure I understand. The idea would be that the PSAP would > contact the AOR or maybe a GRUU, so it would appear to be a normal > phone call to the VSP, assuming it accepts any SIP calls at all. That's exactly the problem. VSPs don't allow calls from just anybody. That's why SPIT is not a problem. One solution is that VSPs should that do this (which is nearly everyone) should list a non-ACLed proxy as the contact for emergency calls, and access is granted based on the data handed to the PSAP. -andy --=_zeke.ecotroph.net-5514-1165026570-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3
On Dec 1, 2006, at 4:04= PM, Henning Schulzrinne wrote:

I'= m not sure I understand. The idea would be that the PSAP would contact th= e AOR or maybe a GRUU, so it would appear to be a normal phone call to th= e VSP, assuming it accepts any SIP calls at all.=A0


That's exa= ctly the problem.=A0 VSPs don't allow calls from just anybody.=A0 That's = why SPIT is not a problem.

One=A0 solution is that VSPs should that do this (which is n= early everyone) should list a non-ACLed proxy as the contact for emergenc= y calls, and access is granted based on the data handed to the PSAP.

-andy=A0
--=_zeke.ecotroph.net-5514-1165026570-0001-2-- --===============2055242267== 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 --===============2055242267==-- From ecrit-bounces@ietf.org Sat Dec 02 10:40:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqWxY-0005WU-MA; Sat, 02 Dec 2006 10:39:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqWxX-0005Vz-L9 for ecrit@ietf.org; Sat, 02 Dec 2006 10:39:23 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqUa6-0001i3-IE for ecrit@ietf.org; Sat, 02 Dec 2006 08:07:04 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kB2D6uMD006197 for ; Sat, 2 Dec 2006 08:06:57 -0500 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] FW: [NENA-ltd] LoST Date: Sat, 2 Dec 2006 15:06:54 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] FW: [NENA-ltd] LoST Thread-Index: AccVs6A+Pnv/nfWzSKyEvDvawTfhwAAXuQhQ From: "Romascanu, Dan \(Dan\) " To: "Andrew Newton" , "Marc Linsner" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: Andy Bierman , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org A similar discussion is happening in the NETCONF Working Group.=20 Dan =20 =20 > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > Sent: Saturday, December 02, 2006 3:44 AM > To: Marc Linsner > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] FW: [NENA-ltd] LoST >=20 > In the IETF RAI area, there is a strong consensus towards=20 > moving toward Relax NG and away from XML Schema. This is=20 > also echoed by many of the members of the IETF's XML=20 > Directorate, most notably Tim Bray -- one of the authors of XML. >=20 > To be even more specific, the experience within IETF=20 > standards with XML Schema has exposed two recurring issues=20 > that are solved by Relax > NG: 1) The UPA restriction, and 2) readability of XSDs. >=20 > And to your specific points about existing IETF standards and=20 > existing software: >=20 > 1) It is true that a lot of IETF standards use XML Schema. =20 > That is due in part to the fact that XML Schema has been=20 > around longer, but also of the mistaken belief that BCP 70=20 > mandated the use of XML Schema in IETF RFCs. BCP 70 actually=20 > says no such thing, but this misperception existed for quite=20 > some time until the XML Directorate made the clarification. >=20 > 2) At present, there does exist more software that uses XML=20 > Schema than Relax NG. But at one time there was also very=20 > little software for XML Schema. As Relax NG heads through=20 > the ISO standardization process and more IETF standards=20 > emerge that use Relax NG, more software supporting it will appear. >=20 > -andy >=20 >=20 >=20 > On Dec 1, 2006, at 12:18 PM, Marc Linsner wrote: >=20 > > The NENA Long Term Definition work group has been closely following=20 > > the LoST work evidenced by early requirements Terry's=20 > concerns a week=20 > > or two ago. > > > > I again queried that group to see if they have any=20 > outstanding issues=20 > > with Terry's concerns, or any additional. Hence I forwarded below=20 > > (with > > permission) Pierre's question about Relax NG. > > > > Thanks, > > > > -Marc- > > > > -----Original Message----- > > From: Desjardins, Pierre [mailto:pdesjardins@positron911.com] > > Sent: Friday, December 01, 2006 9:28 AM > > To: Marc Linsner; nena-ltd@cs.columbia.edu > > Subject: RE: [NENA-ltd] LoST > > > > Marc, > > > > I have no further issues with regards to Terry's concerns,=20 > however I=20 > > did voice a negative comment about the choice of RELAX NG as the=20 > > schema language for defining LoST messages. > > > > I have been around XML for a very long time and this is not=20 > about the=20 > > merits of one schema language over another but rather about making=20 > > life easier for future implementers. > > > > Like it or not, W3C XML Schema (WXS) is the mainstream XML schema=20 > > language and it shows in the multiplicity and diversity of=20 > tools out=20 > > there (commercial or otherwise). > > > > The geopriv schemas were are all published using WXS which=20 > I believe=20 > > favored accelerated adoption. It seems to me that we all=20 > want the same=20 > > benefit for LoST. > > > > I am willing to help with putting a WXS version together --=20 > I may even=20 > > be able to come up with a skeleton schema this weekend... > > > > What do you think? > > > > /Pier > > > > -----Original Message----- > > From: nena-ltd-bounces@cs.columbia.edu=20 > > [mailto:nena-ltd-bounces@cs.columbia.edu] On Behalf Of Marc Linsner > > Sent: Friday, December 01, 2006 8:30 AM > > To: nena-ltd@cs.columbia.edu > > Subject: [NENA-ltd] LoST > > > > All, > > > > Sorry I couldn't make yesterday's call. > > > > I am curious if discussion took place wrt Terry's=20 > questions/ concerns=20 > > about LoST. Is this community satisfied with responses to those=20 > > concerns? Are there still open issues? > > > > > > Thanks, > > > > -Marc- > > _______________________________________________ > > Nena-ltd mailing list > > Nena-ltd@cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/nena-ltd > > > > _______________________________________________ > > 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 Sat Dec 02 16:52:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqcmb-0000E5-1D; Sat, 02 Dec 2006 16:52:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqcma-0000E0-1s for ecrit@ietf.org; Sat, 02 Dec 2006 16:52:28 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqcmY-0001GI-J5 for ecrit@ietf.org; Sat, 02 Dec 2006 16:52:28 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GqcmB-0007Z6-2U; Sat, 02 Dec 2006 15:52:03 -0600 From: "Brian Rosen" To: "'Romascanu, Dan \(Dan\) '" , "'Andrew Newton'" , "'Marc Linsner'" Subject: RE: [Ecrit] FW: [NENA-ltd] LoST Date: Sat, 2 Dec 2006 16:52:20 -0500 Message-ID: <09fb01c7165c$265b2be0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccVs6A+Pnv/nfWzSKyEvDvawTfhwAAXuQhQABIpvyA= X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: 'Andy Bierman' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org And what is their conclusion? Andy's answer is a bit troubling. We're not XML developers, XML is a "tool" (distinguishing from the tools we use with XML) to us. We get disadvantaged when we are early adopters of new XML thingies. The XML development tools probably matter more than the UPA restriction, and readability is in the eye of the beholder: to anyone who has been looking at XML schemas for the last several years, Relax NG is definitely not more readable. Now, I wouldn't really use the latter as an excuse to NOT switch to a new form, because that would keep us on obsolete tools, but it is also not a compelling reason to switch. I had thought the development tools were okay with Relax NG. If that is not the case, then I question whether we should be using it. Brian > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Saturday, December 02, 2006 8:07 AM > To: Andrew Newton; Marc Linsner > Cc: Andy Bierman; ecrit@ietf.org > Subject: RE: [Ecrit] FW: [NENA-ltd] LoST > > A similar discussion is happening in the NETCONF Working Group. > > Dan > > > > > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Saturday, December 02, 2006 3:44 AM > > To: Marc Linsner > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] FW: [NENA-ltd] LoST > > > > In the IETF RAI area, there is a strong consensus towards > > moving toward Relax NG and away from XML Schema. This is > > also echoed by many of the members of the IETF's XML > > Directorate, most notably Tim Bray -- one of the authors of XML. > > > > To be even more specific, the experience within IETF > > standards with XML Schema has exposed two recurring issues > > that are solved by Relax > > NG: 1) The UPA restriction, and 2) readability of XSDs. > > > > And to your specific points about existing IETF standards and > > existing software: > > > > 1) It is true that a lot of IETF standards use XML Schema. > > That is due in part to the fact that XML Schema has been > > around longer, but also of the mistaken belief that BCP 70 > > mandated the use of XML Schema in IETF RFCs. BCP 70 actually > > says no such thing, but this misperception existed for quite > > some time until the XML Directorate made the clarification. > > > > 2) At present, there does exist more software that uses XML > > Schema than Relax NG. But at one time there was also very > > little software for XML Schema. As Relax NG heads through > > the ISO standardization process and more IETF standards > > emerge that use Relax NG, more software supporting it will appear. > > > > -andy > > > > > > > > On Dec 1, 2006, at 12:18 PM, Marc Linsner wrote: > > > > > The NENA Long Term Definition work group has been closely following > > > the LoST work evidenced by early requirements Terry's > > concerns a week > > > or two ago. > > > > > > I again queried that group to see if they have any > > outstanding issues > > > with Terry's concerns, or any additional. Hence I forwarded below > > > (with > > > permission) Pierre's question about Relax NG. > > > > > > Thanks, > > > > > > -Marc- > > > > > > -----Original Message----- > > > From: Desjardins, Pierre [mailto:pdesjardins@positron911.com] > > > Sent: Friday, December 01, 2006 9:28 AM > > > To: Marc Linsner; nena-ltd@cs.columbia.edu > > > Subject: RE: [NENA-ltd] LoST > > > > > > Marc, > > > > > > I have no further issues with regards to Terry's concerns, > > however I > > > did voice a negative comment about the choice of RELAX NG as the > > > schema language for defining LoST messages. > > > > > > I have been around XML for a very long time and this is not > > about the > > > merits of one schema language over another but rather about making > > > life easier for future implementers. > > > > > > Like it or not, W3C XML Schema (WXS) is the mainstream XML schema > > > language and it shows in the multiplicity and diversity of > > tools out > > > there (commercial or otherwise). > > > > > > The geopriv schemas were are all published using WXS which > > I believe > > > favored accelerated adoption. It seems to me that we all > > want the same > > > benefit for LoST. > > > > > > I am willing to help with putting a WXS version together -- > > I may even > > > be able to come up with a skeleton schema this weekend... > > > > > > What do you think? > > > > > > /Pier > > > > > > -----Original Message----- > > > From: nena-ltd-bounces@cs.columbia.edu > > > [mailto:nena-ltd-bounces@cs.columbia.edu] On Behalf Of Marc Linsner > > > Sent: Friday, December 01, 2006 8:30 AM > > > To: nena-ltd@cs.columbia.edu > > > Subject: [NENA-ltd] LoST > > > > > > All, > > > > > > Sorry I couldn't make yesterday's call. > > > > > > I am curious if discussion took place wrt Terry's > > questions/ concerns > > > about LoST. Is this community satisfied with responses to those > > > concerns? Are there still open issues? > > > > > > > > > Thanks, > > > > > > -Marc- > > > _______________________________________________ > > > Nena-ltd mailing list > > > Nena-ltd@cs.columbia.edu > > > https://lists.cs.columbia.edu/cucslists/listinfo/nena-ltd > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Dec 02 16:56:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqcqK-0000tE-Cs; Sat, 02 Dec 2006 16:56:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqcqI-0000t8-Ed for ecrit@ietf.org; Sat, 02 Dec 2006 16:56:18 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqcqG-0001aE-VM for ecrit@ietf.org; Sat, 02 Dec 2006 16:56:18 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gqcpu-0007vI-8R; Sat, 02 Dec 2006 15:55:54 -0600 From: "Brian Rosen" To: "'Andrew Newton'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Later call-back Date: Sat, 2 Dec 2006 16:56:11 -0500 Message-ID: <09fc01c7165c$b02b0480$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4A686881-2CCA-4230-957D-F6EF0C794A16@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccVud+6HKQrXsVJS3O9G3ioPHwugwAokcvw X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e 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="===============0599361630==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0599361630== Content-Type: multipart/alternative; boundary="----=_NextPart_000_09FD_01C71632.C754FC80" This is a multi-part message in MIME format. ------=_NextPart_000_09FD_01C71632.C754FC80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The VSP has to peer, somehow, with the PSAP, to get the call TO the PSAP. Whatever works that direction ought to work for a call back. It may be that PSAPs use commercial carriers for outbound calls, which might alleviate this particular problem. One insight on callback is that there should be two kinds: one that gets back to the same device. You use that when you get disconnected. The other is for use to get back to the same user, much later for some kind of followup action. The former is a GRUU kind of thing, the latter is an AoR. I think the mechanisms being discussed would apply to either, so long as the AoR always lead to something that would recognize tokens, Brian _____ From: Andrew Newton [mailto:andy@hxr.us] Sent: Friday, December 01, 2006 9:30 PM To: Henning Schulzrinne Cc: Ecrit@Ietf.Org Subject: Re: [Ecrit] Later call-back On Dec 1, 2006, at 4:04 PM, Henning Schulzrinne wrote: I'm not sure I understand. The idea would be that the PSAP would contact the AOR or maybe a GRUU, so it would appear to be a normal phone call to the VSP, assuming it accepts any SIP calls at all. That's exactly the problem. VSPs don't allow calls from just anybody. That's why SPIT is not a problem. One solution is that VSPs should that do this (which is nearly everyone) should list a non-ACLed proxy as the contact for emergency calls, and access is granted based on the data handed to the PSAP. -andy ------=_NextPart_000_09FD_01C71632.C754FC80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The VSP has to peer, somehow, with = the PSAP, to get the call TO the PSAP.  Whatever works that direction = ought to work for a call back.  It may be that PSAPs use commercial carriers = for outbound calls, which might alleviate this particular = problem.

 

One insight on callback is that = there should be two kinds: one that gets back to the same device.  You = use that when you get disconnected.  The other is for use to get back to the = same user, much later for some kind of followup action.  The former is a = GRUU kind of thing, the latter is an AoR.

 

I think the mechanisms being = discussed would apply to either, so long as the AoR always lead to something that = would recognize tokens,

 

Brian

 

From: = Andrew Newton [mailto:andy@hxr.us]
Sent: Friday, December = 01, 2006 9:30 PM
To: Henning = Schulzrinne
Cc: Ecrit@Ietf.Org
Subject: Re: [Ecrit] = Later call-back

 

 

On Dec 1, 2006, at 4:04 PM, Henning Schulzrinne = wrote:



I'm not sure I = understand. The idea would be that the PSAP would contact the AOR or maybe a GRUU, so it = would appear to be a normal phone call to the VSP, assuming it accepts any SIP = calls at all. =

 

That's exactly the problem. VSPs don't allow calls from just = anybody. That's why SPIT is not a problem.

 

One solution is that VSPs should that do this (which is nearly everyone) should list a non-ACLed proxy as the contact for emergency = calls, and access is granted based on the data handed to the = PSAP.

 

-andy

------=_NextPart_000_09FD_01C71632.C754FC80-- --===============0599361630== 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 --===============0599361630==-- From ecrit-bounces@ietf.org Sat Dec 02 17:50:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqdgY-000756-KM; Sat, 02 Dec 2006 17:50:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqdgX-00074J-M1 for ecrit@ietf.org; Sat, 02 Dec 2006 17:50:17 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqdgW-0000gt-FH for ecrit@ietf.org; Sat, 02 Dec 2006 17:50:17 -0500 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sat, 02 Dec 2006 17:49:50 -0500 id 015880AF.4572030E.0000146C In-Reply-To: <09fb01c7165c$265b2be0$640fa8c0@cis.neustar.com> References: <09fb01c7165c$265b2be0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] FW: [NENA-ltd] LoST Date: Sat, 2 Dec 2006 17:50:00 -0500 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: 'Andy Bierman' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The tool issue is a bit of FUD, IMO. It is still possible to use SAX or DOM or pull APIs just like with XML Schemas and DTDs and all the other types XML schema languages. There is nothing about Relax NG that requires an implementation to use a special XML parser. The tools people are talking about are normally code generators, which are usually the hallmark of sloppy programming practices (my opinion, but I've seen it a lot). I certainly would hope that anyone serious about fielding LoST knows how XML works and does not have to rely on such crutches. I've had no trouble finding tools for validation. And both my desktop XML editors support Relax NG, one supporting it much better than XML Schema. BTW, regarding your statement about "We're not XML developers." Well, you better understand it. Just like you better have an understanding of how TCP/IP works too. Or would you prefer that people writing software be able to stand behind statements like "We're not Internet applications developers." -andy On Dec 2, 2006, at 4:52 PM, Brian Rosen wrote: > And what is their conclusion? > > Andy's answer is a bit troubling. We're not XML developers, XML is > a "tool" > (distinguishing from the tools we use with XML) to us. We get > disadvantaged > when we are early adopters of new XML thingies. The XML > development tools > probably matter more than the UPA restriction, and readability is > in the eye > of the beholder: to anyone who has been looking at XML schemas for > the last > several years, Relax NG is definitely not more readable. Now, I > wouldn't > really use the latter as an excuse to NOT switch to a new form, > because that > would keep us on obsolete tools, but it is also not a compelling > reason to > switch. > > I had thought the development tools were okay with Relax NG. If > that is not > the case, then I question whether we should be using it. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Dec 02 19:58:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqffx-0006ro-0J; Sat, 02 Dec 2006 19:57:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqffv-0006qd-RY for ecrit@ietf.org; Sat, 02 Dec 2006 19:57:47 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gqffu-0004yd-Lz for ecrit@ietf.org; Sat, 02 Dec 2006 19:57:47 -0500 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sat, 02 Dec 2006 19:57:22 -0500 id 01588027.457220F2.00002DEA In-Reply-To: <09fc01c7165c$b02b0480$640fa8c0@cis.neustar.com> References: <09fc01c7165c$b02b0480$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Later call-back Date: Sat, 2 Dec 2006 19:57:36 -0500 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "'Ecrit@Ietf.Org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Dec 2, 2006, at 4:56 PM, Brian Rosen wrote: > The VSP has to peer, somehow, with the PSAP, to get the call TO the > PSAP. > Whatever works that direction ought to work for a call back. So every VSP is to peer with every PSAP? My understanding is that there is an intention to have regional entities provide the public access for many of the smaller municipal PSAPs. If that is the case, then the PSAPs would have to route back through the regional entity. > It may be that > PSAPs use commercial carriers for outbound calls, which might > alleviate this > particular problem. What about non-E.164 peering fabrics such as FWD and Gizmo? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 04 04:13:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr9sW-0000lM-9G; Mon, 04 Dec 2006 04:12:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr9sV-0000gy-3U for ecrit@ietf.org; Mon, 04 Dec 2006 04:12:47 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gr9sR-0003Di-Lm for ecrit@ietf.org; Mon, 04 Dec 2006 04:12:47 -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] Later call-back Date: Mon, 4 Dec 2006 10:11:55 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C5300@oefeg-s04.oefeg.loc> In-Reply-To: <09fc01c7165c$b02b0480$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Later call-back Thread-Index: AccVud+6HKQrXsVJS3O9G3ioPHwugwAokcvwAEn0h1A= From: "Stastny Richard" To: "Brian Rosen" , "Andrew Newton" , "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "Ecrit@Ietf.Org" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >The VSP has to peer, somehow, with the PSAP, to get the call TO the = PSAP. A minor note: a VSP has not only to peer with THE PSAP, it has to peer = with=20 ALL PSAPs in the world (and vice versa) Richard ________________________________________ From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Saturday, December 02, 2006 10:56 PM To: 'Andrew Newton'; 'Henning Schulzrinne' Cc: 'Ecrit@Ietf.Org' Subject: RE: [Ecrit] Later call-back The VSP has to peer, somehow, with the PSAP, to get the call TO the = PSAP.=A0 Whatever works that direction ought to work for a call back.=A0 = It may be that PSAPs use commercial carriers for outbound calls, which = might alleviate this particular problem. One insight on callback is that there should be two kinds: one that gets = back to the same device.=A0 You use that when you get disconnected.=A0 = The other is for use to get back to the same user, much later for some = kind of followup action.=A0 The former is a GRUU kind of thing, the = latter is an AoR. I think the mechanisms being discussed would apply to either, so long as = the AoR always lead to something that would recognize tokens, Brian ________________________________________ From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Friday, December 01, 2006 9:30 PM To: Henning Schulzrinne Cc: Ecrit@Ietf.Org Subject: Re: [Ecrit] Later call-back On Dec 1, 2006, at 4:04 PM, Henning Schulzrinne wrote: I'm not sure I understand. The idea would be that the PSAP would contact = the AOR or maybe a GRUU, so it would appear to be a normal phone call to = the VSP, assuming it accepts any SIP calls at all.=20 That's exactly the problem. VSPs don't allow calls from just anybody. = That's why SPIT is not a problem. One solution is that VSPs should that do this (which is nearly everyone) = should list a non-ACLed proxy as the contact for emergency calls, and = access is granted based on the data handed to the PSAP. -andy=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 04 09:20:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrEg1-0002XM-5V; Mon, 04 Dec 2006 09:20:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrEg0-0002XH-Sk for ecrit@ietf.org; Mon, 04 Dec 2006 09:20:12 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrEfx-0004G7-Kn for ecrit@ietf.org; Mon, 04 Dec 2006 09:20:12 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GrEgj-0008Cb-FY; Mon, 04 Dec 2006 08:20:57 -0600 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] Later call-back Date: Mon, 4 Dec 2006 09:20:04 -0500 Message-ID: <0c9701c717af$4cfcf3b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccWdfuD8Uj/xeBIRrSoOPhckNqAVwBOPOmA X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "'Ecrit@Ietf.Org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > So every VSP is to peer with every PSAP? My understanding is that > there is an intention to have regional entities provide the public > access for many of the smaller municipal PSAPs. If that is the case, > then the PSAPs would have to route back through the regional entity. Yes, we expect regional entities providing public access. Yes, call backs could route through those entities. > > > It may be that > > PSAPs use commercial carriers for outbound calls, which might > > alleviate this > > particular problem. > > What about non-E.164 peering fabrics such as FWD and Gizmo? An entity that uses the public Internet to peer, would have to accept PSAP calls from the public Internet PSAPs will (probably, as above, indirectly) accept calls on the Internet. We expect most calls will come in via private interconnects with an IP network the PSAP is connected to. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 04 11:21:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGZ7-0005Cy-Qy; Mon, 04 Dec 2006 11:21:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGZ6-0005Cf-4v for ecrit@ietf.org; Mon, 04 Dec 2006 11:21:12 -0500 Received: from srvexchg2.positron.qc.ca ([199.84.137.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrGZ4-0004As-S7 for ecrit@ietf.org; Mon, 04 Dec 2006 11:21:12 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Ecrit] FW: [NENA-ltd] LoST Date: Mon, 4 Dec 2006 11:21:02 -0500 Message-ID: <567E04E775EA244A9F7E4140EAEB41110472537A@srvexchg2.positron.qc.ca> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] FW: [NENA-ltd] LoST Thread-Index: AccWZFLws4KX1TuwSvWq3zm2Q/UCcgBTSQIQ From: "Desjardins, Pierre" To: "Andrew Newton" , "Brian Rosen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Andy Bierman , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org For better or worst, XML Schema is an integral and valuable component of many other XML technology standards and is leveraged in all important web services development & delivery platforms. Editor and validator availability is but one aspect of the more general issue -- how the schema language integrates with other XML-based technologies is what counts when we are talking about encouraging implementations -- which is by no means LoST specific. /Pier -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Saturday, December 02, 2006 5:50 PM To: Brian Rosen Cc: 'Andy Bierman'; ecrit@ietf.org Subject: Re: [Ecrit] FW: [NENA-ltd] LoST The tool issue is a bit of FUD, IMO. It is still possible to use SAX or DOM or pull APIs just like with XML Schemas and DTDs and all the other types XML schema languages. There is nothing about Relax NG that requires an implementation to use a special XML parser. The tools people are talking about are normally code generators, which are usually the hallmark of sloppy programming practices (my opinion, but I've seen it a lot). I certainly would hope that anyone serious about fielding LoST knows how XML works and does not have to rely on =20 such crutches. I've had no trouble finding tools for validation. =20 And both my desktop XML editors support Relax NG, one supporting it much better than XML Schema. BTW, regarding your statement about "We're not XML developers." =20 Well, you better understand it. Just like you better have an understanding of how TCP/IP works too. Or would you prefer that people writing software be able to stand behind statements like "We're not Internet applications developers." -andy On Dec 2, 2006, at 4:52 PM, Brian Rosen wrote: > And what is their conclusion? > > Andy's answer is a bit troubling. We're not XML developers, XML is =20 > a "tool" > (distinguishing from the tools we use with XML) to us. We get =20 > disadvantaged > when we are early adopters of new XML thingies. The XML =20 > development tools > probably matter more than the UPA restriction, and readability is =20 > in the eye > of the beholder: to anyone who has been looking at XML schemas for =20 > the last > several years, Relax NG is definitely not more readable. Now, I =20 > wouldn't > really use the latter as an excuse to NOT switch to a new form, =20 > because that > would keep us on obsolete tools, but it is also not a compelling =20 > reason to > switch. > > I had thought the development tools were okay with Relax NG. If =20 > that is not > the case, then I question whether we should be using it. _______________________________________________ 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 Dec 04 12:04:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrHEG-0005Bz-R6; Mon, 04 Dec 2006 12:03:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrHEF-0005Bs-P9 for ecrit@ietf.org; Mon, 04 Dec 2006 12:03:43 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrHEE-0001sT-FQ for ecrit@ietf.org; Mon, 04 Dec 2006 12:03:43 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GrHEj-0006ZR-4R; Mon, 04 Dec 2006 11:04:13 -0600 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] FW: [NENA-ltd] LoST Date: Mon, 4 Dec 2006 12:03:19 -0500 Message-ID: <0ccf01c717c6$1c80e040$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccWZC/tYy3aw3rSRiSLHruruV/uDQBYbF4A X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: 'Andy Bierman' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I checked with our developers. We use xerces, gSOAP and xmlspy. None of them support Relax NG as far as I can determine. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Saturday, December 02, 2006 5:50 PM > To: Brian Rosen > Cc: 'Romascanu, Dan (Dan) '; 'Marc Linsner'; 'Andy Bierman'; > ecrit@ietf.org > Subject: Re: [Ecrit] FW: [NENA-ltd] LoST > > The tool issue is a bit of FUD, IMO. It is still possible to use SAX > or DOM or pull APIs just like with XML Schemas and DTDs and all the > other types XML schema languages. There is nothing about Relax NG > that requires an implementation to use a special XML parser. The > tools people are talking about are normally code generators, which > are usually the hallmark of sloppy programming practices (my opinion, > but I've seen it a lot). I certainly would hope that anyone serious > about fielding LoST knows how XML works and does not have to rely on > such crutches. I've had no trouble finding tools for validation. > And both my desktop XML editors support Relax NG, one supporting it > much better than XML Schema. > > BTW, regarding your statement about "We're not XML developers." > Well, you better understand it. Just like you better have an > understanding of how TCP/IP works too. Or would you prefer that > people writing software be able to stand behind statements like > "We're not Internet applications developers." > > -andy > > On Dec 2, 2006, at 4:52 PM, Brian Rosen wrote: > > > And what is their conclusion? > > > > Andy's answer is a bit troubling. We're not XML developers, XML is > > a "tool" > > (distinguishing from the tools we use with XML) to us. We get > > disadvantaged > > when we are early adopters of new XML thingies. The XML > > development tools > > probably matter more than the UPA restriction, and readability is > > in the eye > > of the beholder: to anyone who has been looking at XML schemas for > > the last > > several years, Relax NG is definitely not more readable. Now, I > > wouldn't > > really use the latter as an excuse to NOT switch to a new form, > > because that > > would keep us on obsolete tools, but it is also not a compelling > > reason to > > switch. > > > > I had thought the development tools were okay with Relax NG. If > > that is not > > the case, then I question whether we should be using it. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 04 13:03:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrI9v-00084q-73; Mon, 04 Dec 2006 13:03:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrI9u-00083z-Hy for ecrit@ietf.org; Mon, 04 Dec 2006 13:03:18 -0500 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrI9t-0001f4-9H for ecrit@ietf.org; Mon, 04 Dec 2006 13:03:18 -0500 Received: from po2.bbn.com ([128.33.0.56]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1GrI9r-0002KW-3J; Mon, 04 Dec 2006 13:03:15 -0500 Received: from [127.0.0.1] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id kB4I3Ew21916; Mon, 4 Dec 2006 13:03:14 -0500 (EST) Message-ID: <457462E1.30106@bbn.com> Date: Mon, 04 Dec 2006 13:03:13 -0500 From: Richard Barnes User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Henning Schulzrinne , ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Subject: [Ecrit] Comments on ecrit-mapping-arch X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning, After reading the latest mapping architecture draft, I have a few high-level questions: 1. Relation to DNS: Beyond the distinction you make in section 7.1 (trees are organized by geography rather than label), how is this architecture different from the DNS? In particular, what value is added by the forest guides that wouldn't be by a root server or servers? 2. Role of Services: LoST explicitly maps a request that contains both a location and a service to a URI (pointing to the provider of that service in that location). The mapping architecture, on the other hand, seems to say that the heirarchy of tree structure is based only on geography, rather than allowing branches based on services. For example, the state police might have their own separate subtree under the state-level node that handled the territories of their field offices, independently of other emergency services. In general, how did you envision multiple services being located in this architecture? (I think that with the current document, there would have to be separate by-service trees, or all services for a locality would be stored at that locality's leaf node.) 3. FG handling of overlap: I'm worried by the following sentence: "A tree node at the top of a tree can contact any forest guide and inject new coverage region information into the system." Within trees, impersonation is not as large an issue, since a tree is specified to return all results for a given region (because of overlap). But there's no similar specification for FGs: If I set up a tree that directs all emergency calls in New York to me and convince a Forest Guide to accept it, nothing in the architecture says that my tree won't override the existing, legitimate New York tree. It seems like this would be less of an issue if there were some root node that could coordinate trees. 4. Security of Forest Guides: In general, the concept that all FGs have the same information seems at odds (1) use of "local policy" for admitting maps (as specified in section 9), and (2) the notion of a "trusted forest guide". For example, it seems like a situation could arise in which an attacker could feed bad information to a single FG with lax policies for admitting maps, and this FG would propagate that information to the rest of the FG population. Since FGs seem to trust other FGs implicitly (I don't see any contradiction to this), every FG is exactly as trustworthy as any other. Cheers, --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 04 13:39:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrIiX-0001OV-5n; Mon, 04 Dec 2006 13:39:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrIiW-0001OQ-O8 for ecrit@ietf.org; Mon, 04 Dec 2006 13:39:04 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrIiQ-0006t4-9y for ecrit@ietf.org; Mon, 04 Dec 2006 13:39:04 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 04 Dec 2006 13:38:33 -0500 id 0158C300.45746B29.0000536B In-Reply-To: <0ccf01c717c6$1c80e040$640fa8c0@cis.neustar.com> References: <0ccf01c717c6$1c80e040$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Message-Id: <368CA65F-559E-42EB-BB28-AB003E305D4A@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] FW: [NENA-ltd] LoST Date: Mon, 4 Dec 2006 13:38:43 -0500 To: Brian Rosen , Pierre Desjardins X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: 'Andy Bierman' , 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="===============0146740851==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0146740851== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-21360-1165257521-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-21360-1165257521-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Dec 4, 2006, at 11:21 AM, Desjardins, Pierre wrote: > Editor and validator > availability is but one aspect of the more general issue... Actually, if validation isn't THE issue, I fail to see what the big deal is. Even then, validation is not necessary. On Dec 4, 2006, at 12:03 PM, Brian Rosen wrote: > We use xerces, gSOAP and xmlspy. There's nothing stopping you from using Xerces to parse well-formed XML defined with Relax NG. I don't know gSOAP, but it sounds like a SOAP stack and we are not using SOAP. However, your professional software engineers may want to consult with the grad students at Columbia who report success in this area. And regarding XMLSpy, what a pity that such expensive commercial software does not support a feature its much less expensive brethren have supported for years. The high and low of it is this: The switch to Relax NG was made quite some time ago. It was in the issue tracker, called out in release notes, and discussed in our meetings. Our methodology has even been run by the IETF's XML Directorate to help ensure no late surprises. This is an issue that has been put to bed. It is not worth re-opening and delaying the spec further unless somebody can come up with a very specific issue. There is absolutely no reason why any competent developer cannot take an XML compliant parser and use it to parse LoST XML as it is defined right now. -andy --=_zeke.ecotroph.net-21360-1165257521-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3
On Dec 4, 2006, at 11:21 AM= , Desjardins, Pierre wrote:
availability is but one asp= ect of the more general issue...

Actually, if validation isn't THE is= sue, I fail to see what the big deal is.=A0 Even then, validation is not = necessary.

On Dec 4, 2006, at 12:03 PM, Brian Rosen wr= ote:

We use xerces, gSOAP and xmls= py.


There's nothing stopping you f= rom using Xerces to parse well-formed XML defined with Relax NG.=A0 I don= 't know gSOAP, but it sounds like a SOAP stack and we are not using SOAP.= =A0 However, your professional software engineers may want to consult wit= h the grad students at Columbia who report success in this area.=A0 And r= egarding XMLSpy, what a pity that such expensive commercial software does= not support a feature its much less expensive brethren have supported fo= r years.

The h= igh and low of it is this:=A0 The switch to Relax NG was made quite some = time ago.=A0 It was in the issue tracker, called out in release notes, an= d discussed in our meetings.=A0 Our methodology has even been run by the = IETF's XML Directorate to help ensure no late surprises.=A0 This is an is= sue that has been put to bed.=A0 It is not worth re-opening and delaying = the spec further unless somebody can come up with a very specific issue.=A0= There is absolutely no reason why any competent developer cannot take an= XML compliant parser and use it to parse LoST XML as it is defined right= now.

-andy --=_zeke.ecotroph.net-21360-1165257521-0001-2-- --===============0146740851== 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 --===============0146740851==-- From ecrit-bounces@ietf.org Mon Dec 04 22:32:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrR25-0003uX-NO; Mon, 04 Dec 2006 22:31:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrR24-0003uS-PG for ecrit@ietf.org; Mon, 04 Dec 2006 22:31:48 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrR20-0005eZ-Hw for ecrit@ietf.org; Mon, 04 Dec 2006 22:31:48 -0500 Received: from [192.168.0.41] (pool-141-153-178-200.mad.east.verizon.net [141.153.178.200]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kB53VdKJ002111 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 4 Dec 2006 22:31:44 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ECRIT From: Henning Schulzrinne Date: Mon, 4 Dec 2006 22:31:36 -0500 X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Ecrit] RelaxNG vs. Schema X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Just for your reading pleasure http://www.tbray.org/ongoing/When/200x/2006/11/27/Choose-Relax via /. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 04 23:20:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrRmd-0008Bs-68; Mon, 04 Dec 2006 23:19:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrRmc-0008Bn-0Z for ecrit@ietf.org; Mon, 04 Dec 2006 23:19:54 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrRma-00086w-M8 for ecrit@ietf.org; Mon, 04 Dec 2006 23:19:53 -0500 Received: from [192.168.0.41] (pool-141-153-178-200.mad.east.verizon.net [141.153.178.200]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kB54JWa3003822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Dec 2006 23:19:37 -0500 (EST) In-Reply-To: <457462E1.30106@bbn.com> References: <457462E1.30106@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <371529EF-7419-4ED8-A870-4F52FDA44E99@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Mon, 4 Dec 2006 23:19:28 -0500 To: Richard Barnes X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: ECRIT Subject: [Ecrit] Re: Comments on ecrit-mapping-arch X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Richard, I'll start with some answers, in bits and pieces. On Dec 4, 2006, at 1:03 PM, Richard Barnes wrote: > Henning, > > After reading the latest mapping architecture draft, I have a few > high-level questions: > > 1. Relation to DNS: Beyond the distinction you make in section 7.1 > (trees are organized by geography rather than label), how is this > architecture different from the DNS? In particular, what value is > added by the forest guides that wouldn't be by a root server or > servers? The basic architecture is similar, but the absence of root servers is a design decision to make deployment easier even if there is no global coordination body. I rather not create another ICANN or task the ITU with running a root. We've seen how "well" this works, more recently, for ENUM, and so I'd rather provide the flexibility of not needing a single (logical) root server. > > 2. Role of Services: LoST explicitly maps a request that contains > both a location and a service to a URI (pointing to the provider of > that service in that location). The mapping architecture, on the > other hand, seems to say that the heirarchy of tree structure is > based only on geography, rather than allowing branches based on > services. For example, the state police might have their own > separate subtree under the state-level node that handled the > territories of their field offices, independently of other > emergency services. In general, how did you envision multiple > services being located in this architecture? (I think that with the > current document, there would have to be separate by-service trees, > or all services for a locality would be stored at that locality's > leaf node.) > That's probably a lack of specificity in the architecture. The current assumption is that you could indeed have service-specific trees. It's not quite clear to me yet whether we need anything fancier than whole-subtree mechanisms (e.g., advertising service:sos would include all emergency services, while service:sos.police would be just the police.) > 3. FG handling of overlap: I'm worried by the following sentence: > "A tree node at the top of a tree can contact any forest guide and > inject new coverage region information into the system." Within > trees, impersonation is not as large an issue, since a tree is > specified to return all results for a given region (because of > overlap). But there's no similar specification for FGs: If I set > up a tree that directs all emergency calls in New York to me and > convince a Forest Guide to accept it, nothing in the architecture > says that my tree won't override the existing, legitimate New York > tree. It seems like this would be less of an issue if there were > some root node that could coordinate trees. See above. I think in the long run, you need either a consortium that restricts access to peering or signatures, so that the consumer of the information can decide whom to trust. Given the lack of deployment experience, I don't want to prejudge the outcome of that debate. There are several possibilities: (1) consumer choice, based on signed announcements ("As carrier X, I only trust announcements signed by CAs A, B and C"), where 'consumer' is more likely a VSP-operated resolver than an individual (2) virtual root, through a signing mechanism ("The global association of restaurant guides signs the FG announcements") (3) peering among FGs requires cooperation; thus, a group of FGs could decide to limit membership in their "club" to trusted members. Again, this seems like a "layer 9" discussion, where I don't claim to have a good answer. It also seems likely that different services might take different approaches. For some, a fairly loose mechanism that kicks out misbehaving FGs might be perfectly fine, since the stakes are low. > > 4. Security of Forest Guides: In general, the concept that all FGs > have the same information seems at odds (1) use of "local policy" > for admitting maps (as specified in section 9), and (2) the notion > of a "trusted forest guide". For example, it seems like a > situation could arise in which an attacker could feed bad > information to a single FG with lax policies for admitting maps, > and this FG would propagate that information to the rest of the FG > population. Since FGs seem to trust other FGs implicitly (I don't > see any contradiction to this), every FG is exactly as trustworthy > as any other. > See above. > Cheers, > --Richard > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 05 14:06:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grfc7-0007HG-NE; Tue, 05 Dec 2006 14:05:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grfc6-0007H9-2q for ecrit@ietf.org; Tue, 05 Dec 2006 14:05:58 -0500 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grfc0-00021u-Gp for ecrit@ietf.org; Tue, 05 Dec 2006 14:05:58 -0500 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 29D272001C for ; Tue, 5 Dec 2006 14:05:52 -0500 (EST) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26564-02 for ; Tue, 5 Dec 2006 14:05:51 -0500 (EST) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 3064820072 for ; Tue, 5 Dec 2006 14:05:51 -0500 (EST) To: ecrit@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Tue, 5 Dec 2006 14:05:43 -0500 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 12/05/2006 02:05:49 PM, Serialize complete at 12/05/2006 02:05:49 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [Ecrit] Fw: ATIS PRESS RELEASE: ATIS Releases Suite of IP-based Emergency Services Standards X-BeenThere: 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="===============2053635930==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============2053635930== Content-Type: multipart/alternative; boundary="=_alternative 0068E70A8525723B_=" This is a multipart message in MIME format. --=_alternative 0068E70A8525723B_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable FYI, in case folks did not see this go by ... -- Peter Blatherwick From: owner-atispr@lists.atis.org [mailto:owner-atispr@lists.atis.org] On=20 Behalf Of ATIS Sent: Monday, December 04, 2006 12:11 PM Subject: ATIS PRESS RELEASE: ATIS Releases Suite of IP-based Emergency=20 Services Standards ATIS Releases Suite of IP-based Emergency Services Standards December 4, 2006, Washington ? ATIS today announced the availability of=20 its newly developed suite of IP-based Emergency Services Network Interface = (ESNI) standards that will enable the expansion of E9-1-1 services and=20 functionality within the Next Generation Network (NGN).=20 The ESNI suite of standards includes an overall emergency services=20 framework for the ESNI applications and protocols such as the Emergency=20 Information Services Interface (EISI) that provide access to emergency=20 services within or external to the Emergency Services Network (ESNet). The = ESNI standards suite also includes the Emergency Services Messaging=20 Interface (ESMI), released in September 2005, which provides managed=20 interconnections between next generation public service answering points=20 (PSAPs) and the ESNet.=20 For more information, see the full release online at=20 http://www.atis.org/PRESS/pressreleases2006/120406.htm.=20 --=_alternative 0068E70A8525723B_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
FYI, in case folks did not see this go by ...

-- Peter Blatherwick

From: o= wner-atispr@lists.atis.org [mailto:owner-atispr@lists.atis.org] On Behalf Of ATIS
Sent: Monday, December 04, 2006 12:11 PM
Subject: ATIS PRESS RELEASE: ATIS Releases Suite of IP-based Emergency Services Standards

ATIS Releases Suite of IP-based Emergen= cy Services Standards

December 4, 2006, Washington – ATIS today announced the availability of its newly developed suite of IP-based Emergency Services Network Interface (ESNI) standards that will enable the expansion of E9-1-1 services and functionality within the Next Generati= on Network (NGN).

The ESNI suite of standards includes an ov= erall emergency services framework for the ESNI applications and protocols such as the Emergency Information Services Interface (EISI) that provide access to emergency services within or external to the Emergency Services Network (ESNet). The ESNI standards suite also includes the Emergency Services Messaging Interface (ESMI), released in September 2005, which provides managed interconnections between next generation public service answering points (PSAPs) and the ESNet.

For more information, see the full release online at http://www.atis.org/PR= ESS/pressreleases2006/120406.htm. --=_alternative 0068E70A8525723B_=-- --===============2053635930== 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 --===============2053635930==-- From ecrit-bounces@ietf.org Wed Dec 06 03:25:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grs5f-0006kQ-Ev; Wed, 06 Dec 2006 03:25:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grs5e-0006kL-RL for ecrit@ietf.org; Wed, 06 Dec 2006 03:25:18 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Grs5a-0000Do-Dm for ecrit@ietf.org; Wed, 06 Dec 2006 03:25:18 -0500 Received: (qmail invoked by alias); 06 Dec 2006 08:25:13 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp039) with SMTP; 06 Dec 2006 09:25:13 +0100 X-Authenticated: #29516787 Message-ID: <45767E6B.9020009@gmx.net> Date: Wed, 06 Dec 2006 09:25:15 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: peter_blatherwick@mitel.com Subject: Re: [Ecrit] Fw: ATIS PRESS RELEASE: ATIS Releases Suite of IP-based Emergency Services Standards References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Are some documents available? Ciao Hannes peter_blatherwick@mitel.com wrote: > > FYI, in case folks did not see this go by ... > > -- Peter Blatherwick > > ------------------------------------------------------------------------ > *From:* _owner-atispr@lists.atis.org_ > > [mailto:owner-atispr@lists.atis.org] *On Behalf Of *ATIS* > Sent:* Monday, December 04, 2006 12:11 PM* > Subject:* ATIS PRESS RELEASE: ATIS Releases Suite of IP-based > Emergency Services Standards > > *ATIS Releases Suite of IP-based Emergency Services Standards* > > *December 4, 2006, Washington – *ATIS today announced the availability > of its newly developed suite of IP-based Emergency Services Network > Interface (ESNI) standards that will enable the expansion of E9-1-1 > services and functionality within the Next Generation Network (NGN). > > The ESNI suite of standards includes an overall emergency services > framework for the ESNI applications and protocols such as the > Emergency Information Services Interface (EISI) that provide access to > emergency services within or external to the Emergency Services > Network (ESNet). The ESNI standards suite also includes the Emergency > Services Messaging Interface (ESMI), released in September 2005, which > provides managed interconnections between next generation public > service answering points (PSAPs) and the ESNet. > > For more information, see the full release online at > _http://www.atis.org/PRESS/pressreleases2006/120406.htm_. > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 06 10:09:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GryOd-0007wd-O9; Wed, 06 Dec 2006 10:09:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GryOc-0007w1-KJ for ecrit@ietf.org; Wed, 06 Dec 2006 10:09:18 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GryOb-0002Of-Dd for ecrit@ietf.org; Wed, 06 Dec 2006 10:09:18 -0500 Received: from [172.16.10.88] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 06 Dec 2006 10:08:51 -0500 id 015880B2.4576DD03.00003301 In-Reply-To: <45767E6B.9020009@gmx.net> References: <45767E6B.9020009@gmx.net> Mime-Version: 1.0 Message-Id: <2055A531-C8AB-4A95-AB31-F904D17B44FC@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] Fw: ATIS PRESS RELEASE: ATIS Releases Suite of IP-based Emergency Services Standards Date: Wed, 6 Dec 2006 10:09:07 -0500 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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="===============0609262288==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0609262288== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-13060-1165417740-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-13060-1165417740-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Dec 6, 2006, at 3:25 AM, Hannes Tschofenig wrote: > Are some documents available? Good question. I noted that their effort has focused purely on NGN. While I've heard that word thrown around, I've never actually head a good explanation of what it is. The nearest I can tell, NGN is a walled-garden, non-global Internet, US-centric network. It is good that they have done this for NGN, but I doubt those standards will apply to the global Internet. -andy --=_zeke.ecotroph.net-13060-1165417740-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3

On Dec 6, 2006, at 3:25= AM, Hannes Tschofenig wrote:

= Are = some documents available?


Good que= stion.=A0 I noted that their effort has focused purely on NGN.=A0 While I= 've heard that word thrown around, I've never actually head a good explan= ation of what it is.=A0 The nearest I can tell, NGN is a walled-garden, n= on-global Internet, US-centric network.=A0 It is good that they have done= this for NGN, but I doubt those standards will apply to the global Inter= net.=A0=A0

-an= dy
--=_zeke.ecotroph.net-13060-1165417740-0001-2-- --===============0609262288== 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 --===============0609262288==-- From ecrit-bounces@ietf.org Wed Dec 06 11:04:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrzGB-0000kv-17; Wed, 06 Dec 2006 11:04:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrzGA-0000kq-1O for ecrit@ietf.org; Wed, 06 Dec 2006 11:04:38 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrzG8-0003rh-Ot for ecrit@ietf.org; Wed, 06 Dec 2006 11:04:38 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GrzG1-0007f6-4P; Wed, 06 Dec 2006 10:04:30 -0600 From: "Brian Rosen" To: "'Andrew Newton'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] Fw: ATIS PRESS RELEASE: ATIS Releases Suite of IP-basedEmergency Services Standards Date: Wed, 6 Dec 2006 11:04:26 -0500 Message-ID: <052401c71950$38704b70$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2055A531-C8AB-4A95-AB31-F904D17B44FC@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccZSIouI4F8Q40VQCmNfb7GK2M+aAABh8Aw X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Well, actually this is the work product of the "TF34" work group in ATIS/ESIF. It defines basically two protocols, ESMI and EISI. ESMI is used when you have what they call "mediated" access to services by a PSAP, i.e. the PSAP desires a middle man to mediate access to various IP based services the PSAP may have available to it. ESMI is the interface between the mediation (RG = Response Gateway) and the PSAP. The EISI is the other side, Service to RG, although it may be useful to connect directly from a service to the PSAP. I personally think ESMI is a mess. Go read it. EISI is basically a profile of web services, and may be more useful. That's a personal opinion, and doesn't represent the views of . Now, in answer to the original question, yes docs are available, but because this is ATIS, you have to buy them. There are drafts around if you look on the web. Brian ________________________________________ From: Andrew Newton [mailto:andy@hxr.us] Sent: Wednesday, December 06, 2006 10:09 AM To: Hannes Tschofenig Cc: ecrit@ietf.org Subject: Re: [Ecrit] Fw: ATIS PRESS RELEASE: ATIS Releases Suite of IP-basedEmergency Services Standards On Dec 6, 2006, at 3:25 AM, Hannes Tschofenig wrote: Are some documents available? Good question. I noted that their effort has focused purely on NGN. While I've heard that word thrown around, I've never actually head a good explanation of what it is. The nearest I can tell, NGN is a walled-garden, non-global Internet, US-centric network. It is good that they have done this for NGN, but I doubt those standards will apply to the global Internet. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Dec 10 08:44:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtOyc-0000IT-OQ; Sun, 10 Dec 2006 08:44:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtOyb-0000II-8X for ecrit@ietf.org; Sun, 10 Dec 2006 08:44:21 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GtOyZ-0006G4-Rk for ecrit@ietf.org; Sun, 10 Dec 2006 08:44:21 -0500 Received: (qmail invoked by alias); 10 Dec 2006 13:44:18 -0000 Received: from p5498768D.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.118.141] by mail.gmx.net (mp010) with SMTP; 10 Dec 2006 14:44:18 +0100 X-Authenticated: #29516787 Message-ID: <457C0F34.80401@gmx.net> Date: Sun, 10 Dec 2006 14:44:20 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Reminder! [Ecrit] Expert Reviewers Nominated References: <45526A5F.8000602@gmx.net> In-Reply-To: <45526A5F.8000602@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: ecrit-bounces@ietf.org Please do not forget your review! Hannes Tschofenig wrote: > Hi all, > > during the ECRIT meeting today we selected a few expert reviews for > our documents: > > * LoST: Jonathan Rosenberg, Tom Taylor, Shida Schubert, Steve Norreys > > * LoST Mapping Architecture: Cullen Jennings, Rohan Mahy, Murugaraj > Shanmugam, Richard Barnes > > * Framework for Emergency Calling: Jonathan Rosenberg, Peter > Blatherwick, Steve Norreys > > We would like to thank these persons in advance. Their work will > obviously appropriately acknowledged in the respective drafts. > > Ciao > Hannes & Marc > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 11 15:50:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts6E-0000VH-It; Mon, 11 Dec 2006 15:50:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts66-0000Ry-7B; Mon, 11 Dec 2006 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gts65-0004XW-O0; Mon, 11 Dec 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id AE4A532992; Mon, 11 Dec 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gts65-0007hp-Ix; Mon, 11 Dec 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Dec 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-dhc-lost-discovery-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-ecrit-dhc-lost-discovery-00.txt Pages : 9 Date : 2006-12-11 The Location-to-Service Translation Protocol (LoST) describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere but a placement closer to the end host, e.g., in the access network, is desireable. Such a LoST server placement provides benefits in disaster situations with intermittent network connectivity regarding the resiliency of emergency service communication. This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-dhc-lost-discovery-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-11135225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-dhc-lost-discovery-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-11135225.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Mon Dec 11 16:44:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtsw4-0004wn-PE; Mon, 11 Dec 2006 16:43:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtsw3-0004w7-BF for ecrit@ietf.org; Mon, 11 Dec 2006 16:43:43 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gtsw1-0006RI-TF for ecrit@ietf.org; Mon, 11 Dec 2006 16:43:43 -0500 Received: (qmail invoked by alias); 11 Dec 2006 21:43:41 -0000 Received: from p54984B93.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.75.147] by mail.gmx.net (mp027) with SMTP; 11 Dec 2006 22:43:41 +0100 X-Authenticated: #29516787 Message-ID: <457DD10C.7020003@gmx.net> Date: Mon, 11 Dec 2006 22:43:40 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: ECRIT 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: b7b9551d71acde901886cc48bfc088a6 Subject: [Ecrit] [Fwd: I-D ACTION:draft-ietf-ecrit-dhc-lost-discovery-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, we have submitted the LoST DHCP-based discovery draft. The plan is to complete it together with the LoST document. Ciao Hannes -------- Original Message -------- Subject: I-D ACTION:draft-ietf-ecrit-dhc-lost-discovery-00.txt Date: Mon, 11 Dec 2006 15:50:01 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ecrit@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-ecrit-dhc-lost-discovery-00.txt Pages : 9 Date : 2006-12-11 The Location-to-Service Translation Protocol (LoST) describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere but a placement closer to the end host, e.g., in the access network, is desireable. Such a LoST server placement provides benefits in disaster situations with intermittent network connectivity regarding the resiliency of emergency service communication. This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-dhc-lost-discovery-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 11 16:46:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtsyP-0001Fl-CQ; Mon, 11 Dec 2006 16:46:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtsyO-00016S-Bp for ecrit@ietf.org; Mon, 11 Dec 2006 16:46:08 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GtsyN-00075F-3K for ecrit@ietf.org; Mon, 11 Dec 2006 16:46:08 -0500 Received: (qmail invoked by alias); 11 Dec 2006 21:46:05 -0000 Received: from p54984B93.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.75.147] by mail.gmx.net (mp018) with SMTP; 11 Dec 2006 22:46:05 +0100 X-Authenticated: #29516787 Message-ID: <457DD19C.5010704@gmx.net> Date: Mon, 11 Dec 2006 22:46:04 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: ledaigle@cisco.com, leslie@thinkingcat.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ECRIT Subject: [Ecrit] Status of draft-daigle-unaptr-01.txt ? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Leslie, what is the status of http://www.ietf.org/internet-drafts/draft-daigle-unaptr-01.txt What is needed to complete the document? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 11 17:06:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GttHm-000297-R1; Mon, 11 Dec 2006 17:06:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GttHl-00028w-Ne for ecrit@ietf.org; Mon, 11 Dec 2006 17:06:09 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GttHk-0002Bu-Gr for ecrit@ietf.org; Mon, 11 Dec 2006 17:06:09 -0500 Received: from [192.168.0.105] ([::ffff:64.102.254.33]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Mon, 11 Dec 2006 17:05:44 -0500 id 0158C308.457DD638.00005B7F Message-ID: <457DD652.8030408@thinkingcat.com> Date: Mon, 11 Dec 2006 17:06:10 -0500 From: Leslie Daigle User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Hannes Tschofenig References: <457DD19C.5010704@gmx.net> In-Reply-To: <457DD19C.5010704@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ECRIT , ledaigle@cisco.com Subject: [Ecrit] Re: Status of draft-daigle-unaptr-01.txt ? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Howdy, It's on Ted's desk -- I asked him, last week, if he would sponsor it for publication. Leslie. Hannes Tschofenig wrote: > Hi Leslie, > > what is the status of > http://www.ietf.org/internet-drafts/draft-daigle-unaptr-01.txt > > What is needed to complete the document? > > Ciao > Hannes > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 11 17:06:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GttID-0002EA-7c; Mon, 11 Dec 2006 17:06:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GttIB-0002D1-Qz for ecrit@ietf.org; Mon, 11 Dec 2006 17:06:35 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GttIA-0002Hz-G3 for ecrit@ietf.org; Mon, 11 Dec 2006 17:06:35 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kBBM6TI6013976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Dec 2006 14:06:29 -0800 Received: from [129.46.225.224] (carbuncle.qualcomm.com [129.46.225.224]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kBBM3Wbk008556; Mon, 11 Dec 2006 14:04:07 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <457DD19C.5010704@gmx.net> References: <457DD19C.5010704@gmx.net> Date: Mon, 11 Dec 2006 14:03:32 -0800 To: Hannes Tschofenig , ledaigle@cisco.com, leslie@thinkingcat.com From: Ted Hardie Subject: Re: [Ecrit] Status of draft-daigle-unaptr-01.txt ? Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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: , Errors-To: ecrit-bounces@ietf.org At 10:46 PM +0100 12/11/06, Hannes Tschofenig wrote: >Hi Leslie, > >what is the status of >http://www.ietf.org/internet-drafts/draft-daigle-unaptr-01.txt > >What is needed to complete the document? > >Ciao >Hannes Hi Hannes, Leslie asked for publication for the document last week; I've asked for a review from the apps-review team, and it will move forward to Last Call after that. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 11 17:10:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GttLe-0004hd-Ag; Mon, 11 Dec 2006 17:10:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GttLc-0004gA-UU for ecrit@ietf.org; Mon, 11 Dec 2006 17:10:08 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GttLY-0002z3-RD for ecrit@ietf.org; Mon, 11 Dec 2006 17:10:08 -0500 Received: (qmail invoked by alias); 11 Dec 2006 22:10:03 -0000 Received: from p54984B93.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.75.147] by mail.gmx.net (mp040) with SMTP; 11 Dec 2006 23:10:03 +0100 X-Authenticated: #29516787 Message-ID: <457DD73B.4090607@gmx.net> Date: Mon, 11 Dec 2006 23:10:03 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Leslie Daigle References: <457DD19C.5010704@gmx.net> <457DD652.8030408@thinkingcat.com> In-Reply-To: <457DD652.8030408@thinkingcat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ECRIT , ledaigle@cisco.com Subject: [Ecrit] Re: Status of draft-daigle-unaptr-01.txt ? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Thanks for the extremely good response. Thanks for the update. Ciao Hannes Leslie Daigle wrote: > Howdy, > > It's on Ted's desk -- I asked him, last week, if he > would sponsor it for publication. > > Leslie. > > Hannes Tschofenig wrote: >> Hi Leslie, >> >> what is the status of >> http://www.ietf.org/internet-drafts/draft-daigle-unaptr-01.txt >> >> What is needed to complete the document? >> >> Ciao >> Hannes >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 11 17:23:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GttYq-0000eO-SK; Mon, 11 Dec 2006 17:23:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GttYq-0000eF-6g for ecrit@ietf.org; Mon, 11 Dec 2006 17:23:48 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GttYo-0004pm-Rn for ecrit@ietf.org; Mon, 11 Dec 2006 17:23:48 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kBBMNgIY017369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Dec 2006 14:23:42 -0800 Received: from [129.46.225.224] (carbuncle.qualcomm.com [129.46.225.224]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kBBMNeIg017436; Mon, 11 Dec 2006 14:23:40 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <457DD19C.5010704@gmx.net> References: <457DD19C.5010704@gmx.net> Date: Mon, 11 Dec 2006 14:23:40 -0800 To: Hannes Tschofenig , ledaigle@cisco.com, leslie@thinkingcat.com From: Ted Hardie Subject: Re: [Ecrit] Status of draft-daigle-unaptr-01.txt ? Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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: , Errors-To: ecrit-bounces@ietf.org At 10:46 PM +0100 12/11/06, Hannes Tschofenig wrote: >Hi Leslie, > >what is the status of >http://www.ietf.org/internet-drafts/draft-daigle-unaptr-01.txt > >What is needed to complete the document? > >Ciao >Hannes Hi Hannes, Leslie asked for publication for the document last week; I've asked for a review from the apps-review team, and it will move forward to Last Call after that. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 11 17:45:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtttk-0006Oc-S9; Mon, 11 Dec 2006 17:45:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtttj-0006Mn-Li for ecrit@ietf.org; Mon, 11 Dec 2006 17:45:23 -0500 Received: from aopmgw4.andrew.com ([198.17.217.205] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gttti-00008o-8q for ecrit@ietf.org; Mon, 11 Dec 2006 17:45:23 -0500 X-SEF-Processed: 5_0_0_910__2006_12_11_16_43_13 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from Unknown [10.3.20.66] by aopmgw4 - SurfControl E-mail Filter (5.2.1); Mon, 11 Dec 2006 16:43:13 -0600 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 16:45:18 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Dec 2006 16:45:17 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Little LoST Nits Thread-Index: Accddgdd3qSiCq/SS1Ogtq3wzAAozg== From: "Thomson, Martin" To: "Andrew Newton" , "ECRIT" X-OriginalArrivalTime: 11 Dec 2006 22:45:18.0193 (UTC) FILETIME=[080F8610:01C71D76] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Ecrit] Little LoST Nits X-BeenThere: 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="===============1507338515==" Errors-To: ecrit-bounces@ietf.org --===============1507338515== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVsYXRlZCB0byB0aGUgdXNlIG9mIGdlb2RldGljL0dNTCBvYmplY3RzIGluIExvU1QsIHRoZXJl IGFyZSBzZXZlcmFsIGJ1Z3MuDQoNCiAtIERyb3AgdGhlIDxwb3NpdGlvbj4gZWxlbWVudC4gIEl0 IGlzIHVubmVjZXNzYXJ5IGluIHRoaXMgY29udGV4dCwgcGFydGljdWxhcmx5IGlmIHlvdSBoYXZl IFBvbHlnb24gYXQgdGhlIHNhbWUgbGV2ZWwuDQoNCiAtIFRoZSBDUlMgVVJOcyBhcmUgbWlzc2lu ZyBjb2xvbnMuICBUaGV5IHNob3VsZCBiZSAidXJuOm9nYzpkZWY6Y3JzOkVQU0c6OjQzMjYiLg0K DQogLSBUaGUgdGhyZWUgZGltZW5zaW9uYWwgQ1JTIGlzIG5vdCBuZWNlc3NhcnkgZm9yIGEgMkQg cHJvZmlsZSwgZHJvcCA0OTc5IGZvciA0MzI2Lg0KDQogLSBZb3UgaGF2ZW4ndCBhbGxvd2VkIGZv ciBtb3JlIHRoYW4gb25lIHBvaW50IGluIHRoZSBMaW5lYXJSaW5nLiAgVGhlcmUgc2hvdWxkIGJl IGEgbWluaW11bSBvZiA0IDxwb3M+IGVsZW1lbnRzLg0KDQogLSBUaGUgPHBvcz4gZWxlbWVudCBz aG91bGQgdXNlIGEgbW9yZSBjb25zdHJhaW5lZCB0eXBlLiAgVGhpcyBzaG91bGQgYmUgYSBsaXN0 IG9mIGRvdWJsZXMuICAoU2ltcGxlIHR5cGUgZGVmaW5pdGlvbiBpcyB0aGUgb25lIHBsYWNlIHdo ZXJlIFJlbGF4TkcgY29uY2VkZXMgdG8gWE1MIFNjaGVtYS4pDQoNCkNoZWVycywNCk1hcnRpbiAN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2Ug aXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJp dmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAg DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6 ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJdDQo= --===============1507338515== 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 --===============1507338515==-- From ecrit-bounces@ietf.org Mon Dec 11 20:32:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtwV5-0005aZ-1n; Mon, 11 Dec 2006 20:32:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtwV3-0005aQ-Pz for ecrit@ietf.org; Mon, 11 Dec 2006 20:32:05 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtwV1-0000rz-LI for ecrit@ietf.org; Mon, 11 Dec 2006 20:32:05 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 11 Dec 2006 20:31:29 -0500 id 0158C30E.457E0671.000012DB In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <647E3F41-5F43-462F-ADA0-0F88AE702724@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Mon, 11 Dec 2006 20:31:47 -0500 To: "Thomson, Martin" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ECRIT Subject: [Ecrit] Re: Little LoST Nits X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Martin, Comments in-line: On Dec 11, 2006, at 5:45 PM, Thomson, Martin wrote: > - Drop the element. It is unnecessary in this context, > particularly if you have Polygon at the same level. Quite right. > - The CRS URNs are missing colons. They should be > "urn:ogc:def:crs:EPSG::4326". Given the lack of NID registration, you should excuse me for not being able to find the correct syntax. Where did you find it? (And yes, I'm aware this is being worked on). > - The three dimensional CRS is not necessary for a 2D profile, > drop 4979 for 4326. Left over baggage from my attempt at doing 3d. Fortunately, somebody wrote a geo-shapes docs that led me to believe I might never get it right. > - You haven't allowed for more than one point in the LinearRing. > There should be a minimum of 4 elements. A simple oversight. Agreed. > - The element should use a more constrained type. This > should be a list of doubles. (Simple type definition is the one > place where RelaxNG concedes to XML Schema.) Again, left overs from where it might have supported two or three doubles. I'll add the constraint. (And you haven't seen cool unless you've read up on what you can do with RNG lists: http:// books.xmlschemata.org/relaxng/relax-CHP-7-SECT-9.html). -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 11 21:21:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtxGy-0001at-6W; Mon, 11 Dec 2006 21:21:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtxGw-0001aQ-Dw for ecrit@ietf.org; Mon, 11 Dec 2006 21:21:34 -0500 Received: from aopmgw4.andrew.com ([198.17.217.205] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtxGr-0002CY-5h for ecrit@ietf.org; Mon, 11 Dec 2006 21:21:34 -0500 X-SEF-Processed: 5_0_0_910__2006_12_11_20_19_23 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from Unknown [10.3.20.69] by aopmgw4 - SurfControl E-mail Filter (5.2.1); Mon, 11 Dec 2006 20:19:23 -0600 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 20:21:28 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Dec 2006 20:21:27 -0600 Message-ID: In-Reply-To: <647E3F41-5F43-462F-ADA0-0F88AE702724@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Little LoST Nits Thread-Index: AccdjUvgHMrOodHuTxa5q7MOeVxDhgABcSTQ From: "Thomson, Martin" To: "Andrew Newton" X-OriginalArrivalTime: 12 Dec 2006 02:21:28.0753 (UTC) FILETIME=[3B1DEA10:01C71D94] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ECRIT Subject: [Ecrit] RE: Little LoST Nits X-BeenThere: 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="===============0342754114==" Errors-To: ecrit-bounces@ietf.org --===============0342754114== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5keSwNCg0KVGhhbmtzIGZvciB0aGUgcXVpY2sgcmVzcG9uc2UuICBJbmxpbmUuLi4NCg0KPiBH aXZlbiB0aGUgbGFjayBvZiBOSUQgcmVnaXN0cmF0aW9uLCB5b3Ugc2hvdWxkIGV4Y3VzZSBtZSBm b3Igbm90DQo+IGJlaW5nIGFibGUgdG8gZmluZCB0aGUgY29ycmVjdCBzeW50YXguICBXaGVyZSBk aWQgeW91IGZpbmQgaXQ/ICAoQW5kDQo+IHllcywgSSdtIGF3YXJlIHRoaXMgaXMgYmVpbmcgd29y a2VkIG9uKS4NCg0KPGh0dHA6Ly93d3cub3Blbmdlb3NwYXRpYWwub3JnL3N0YW5kYXJkcy9icD4N Ci0+DQo8aHR0cDovL3BvcnRhbC5vcGVuZ2Vvc3BhdGlhbC5vcmcvZmlsZXMvP2FydGlmYWN0X2lk PTE2MzM5Pg0KDQo+ID4gIC0gVGhlIHRocmVlIGRpbWVuc2lvbmFsIENSUyBpcyBub3QgbmVjZXNz YXJ5IGZvciBhIDJEIHByb2ZpbGUsDQo+ID4gZHJvcCA0OTc5IGZvciA0MzI2Lg0KPiANCj4gTGVm dCBvdmVyIGJhZ2dhZ2UgZnJvbSBteSBhdHRlbXB0IGF0IGRvaW5nIDNkLiAgRm9ydHVuYXRlbHks IHNvbWVib2R5DQo+IHdyb3RlIGEgZ2VvLXNoYXBlcyBkb2NzIHRoYXQgbGVkIG1lIHRvIGJlbGll dmUgSSBtaWdodCBuZXZlciBnZXQgaXQNCj4gcmlnaHQuDQoNCjspDQoNCj4gKEFuZCB5b3UgaGF2 ZW4ndCBzZWVuIGNvb2wgdW5sZXNzDQo+IHlvdSd2ZSByZWFkIHVwIG9uIHdoYXQgeW91IGNhbiBk byB3aXRoIFJORyBsaXN0czogPGh0dHA6Ly8NCj4gYm9va3MueG1sc2NoZW1hdGEub3JnL3JlbGF4 bmcvcmVsYXgtQ0hQLTctU0VDVC05Lmh0bWw+KS4NCg0KVGhhdCdzIG5lYXQuICBPYnZpb3VzbHkg dGhlIHNhbWUgY29uc3RyYWludHMgYXBwbHkgYXMgZG8gd2l0aCBlbGVtZW50cyAtIGxpc3RzIG9m IG1peGVkIHR5cGVzIGFyZSBwb3NzaWJsZSwgd2hpY2ggaXMgc29tZXRoaW5nIHRoYXQgWE1MIFNj aGVtYSBjYW5ub3QgZG8gKHBlcmhhcHMgZm9yIGdvb2QgcmVhc29uLCBidXQgdGhlIGVsZWdhbnQg c2ltcGxpY2l0eSBvZiBSZWxheE5HIGlzIHN0aWxsIGFuIGFkdmFudGFnZSkuICBJIGp1c3Qgd2lz aCB0aGF0IHRoZXkgaGFkIGFkZGVkIHN1cHBvcnQgZm9yIGNhcmRpbmFsaXR5IG90aGVyIHRoYW4g dGhlIHNldCBvZiB7MCwgMSwgMCssIDErfS4NCg0KTV9UDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0 ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFy eSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2Vp dmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFu ZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1h aWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KW21mMl0NCg== --===============0342754114== 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 --===============0342754114==-- From ecrit-bounces@ietf.org Thu Dec 14 12:39:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuuXl-0007cO-IF; Thu, 14 Dec 2006 12:38:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuuXk-0007bU-3O for ecrit@ietf.org; Thu, 14 Dec 2006 12:38:52 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GuuXi-0005LQ-JY for ecrit@ietf.org; Thu, 14 Dec 2006 12:38:52 -0500 Received: (qmail invoked by alias); 14 Dec 2006 17:38:49 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp035) with SMTP; 14 Dec 2006 18:38:49 +0100 X-Authenticated: #29516787 Message-ID: <45818C23.2010807@gmx.net> Date: Thu, 14 Dec 2006 18:38:43 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: ECRIT 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Christian.Militeau@Intrado.com Subject: [Ecrit] Regarding ATIS PRESS RELEASE: ATIS Releases Suite ofIP-basedEmergency Services Standards X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, Christian kindly offered the possibility to make the mentioned ATIS documents available for our working group. This would require a bit of work via the liaison process. Before we invest time to figure out how this procedure would work I would like to get feedback from the group whether there is interest in obtaining and reviewing the documents. Deadline for a response: 21st December 2006. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 14 12:55:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guunp-0005uQ-RV; Thu, 14 Dec 2006 12:55:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guuno-0005sb-F7 for ecrit@ietf.org; Thu, 14 Dec 2006 12:55:28 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guulp-0006x0-Na for ecrit@ietf.org; Thu, 14 Dec 2006 12:53:26 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Guulh-00024S-Fn; Thu, 14 Dec 2006 11:53:17 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ECRIT'" Subject: RE: [Ecrit] Regarding ATIS PRESS RELEASE: ATIS Releases Suite ofIP-basedEmergency Services Standards Date: Thu, 14 Dec 2006 12:53:20 -0500 Message-ID: <166701c71fa8$bf9e7c30$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccfpsCevHWFGtubRcGXfDwnr6UXwQAAdFwg In-Reply-To: <45818C23.2010807@gmx.net> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Christian.Militeau@Intrado.com X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I have access to the documents now, so this is not of much value to me. I personally think they are of no value to the ecrit working group at this time. If our charter changes, they could become interesting. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, December 14, 2006 12:39 PM > To: ECRIT > Cc: Christian.Militeau@Intrado.com > Subject: [Ecrit] Regarding ATIS PRESS RELEASE: ATIS Releases Suite ofIP- > basedEmergency Services Standards > > Hi all, > > Christian kindly offered the possibility to make the mentioned ATIS > documents available for our working group. This would require a bit of > work via the liaison process. Before we invest time to figure out how > this procedure would work I would like to get feedback from the group > whether there is interest in obtaining and reviewing the documents. > > Deadline for a response: 21st December 2006. > > Ciao > Hannes > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 14 13:57:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuvlH-0005UW-Js; Thu, 14 Dec 2006 13:56:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuvlG-0005UP-46 for ecrit@ietf.org; Thu, 14 Dec 2006 13:56:54 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuvlE-0004Tj-Rk for ecrit@ietf.org; Thu, 14 Dec 2006 13:56:54 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 14 Dec 2006 13:56:52 -0500 X-IronPort-AV: i="4.12,170,1165208400"; d="scan'208"; a="109517863:sNHT44218440" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBEIuq63031451; Thu, 14 Dec 2006 13:56:52 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBEIup0n001650; Thu, 14 Dec 2006 13:56:52 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 13:56:51 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.20.111]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 13:56:50 -0500 Message-Id: <4.3.2.7.2.20061214125551.031f7278@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Dec 2006 12:56:49 -0600 To: Hannes Tschofenig , ECRIT From: "James M. Polk" Subject: Re: [Ecrit] Regarding ATIS PRESS RELEASE: ATIS Releases Suite ofIP-basedEmergency Services Standards In-Reply-To: <45818C23.2010807@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Dec 2006 18:56:51.0064 (UTC) FILETIME=[9D36DF80:01C71FB1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=737; t=1166122612; x=1166986612; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Regarding=20ATIS=20PRESS=20RELEASE=3A=20ATI S=20Releases=20Suite=0A=20=20ofIP-basedEmergency=20Services=20Standards |Sender:=20 |To:=20Hannes=20Tschofenig=20, =20ECRIT=20; bh=anGop+I/xslFQwu/6UsxhQVusbhHt/643YbTNb2qT8k=; b=XVA77nwjgYoaSGrSz3GgCMek3Ra45tUUfjbC1b/0SKd3J0o/hMgmP4odgjGlcQaHf/kzaJAV Y0d7D84QANv+6/D3xzdsHughuyg5zsLotmcZYQtFd0PJYyF3b5q2DHcs; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Christian.Militeau@Intrado.com X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I didn't think the IETF did liaisons with national organizations (only international ones)? At 06:38 PM 12/14/2006 +0100, Hannes Tschofenig wrote: >Hi all, > >Christian kindly offered the possibility to make the mentioned ATIS >documents available for our working group. This would require a bit of >work via the liaison process. Before we invest time to figure out how this >procedure would work I would like to get feedback from the group whether >there is interest in obtaining and reviewing the documents. > >Deadline for a response: 21st December 2006. > >Ciao >Hannes > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 14 14:52:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guwd2-0001yc-2v; Thu, 14 Dec 2006 14:52:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guwd0-0001wV-E9 for ecrit@ietf.org; Thu, 14 Dec 2006 14:52:26 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Guwcz-0002X5-0l for ecrit@ietf.org; Thu, 14 Dec 2006 14:52:26 -0500 Received: (qmail invoked by alias); 14 Dec 2006 19:52:21 -0000 Received: from p5498767A.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.118.122] by mail.gmx.net (mp039) with SMTP; 14 Dec 2006 20:52:21 +0100 X-Authenticated: #29516787 Message-ID: <4581AB74.10801@gmx.net> Date: Thu, 14 Dec 2006 20:52:20 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] Regarding ATIS PRESS RELEASE: ATIS Releases Suite ofIP-basedEmergency Services Standards References: <4.3.2.7.2.20061214125551.031f7278@email.cisco.com> In-Reply-To: <4.3.2.7.2.20061214125551.031f7278@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Christian.Militeau@Intrado.com, ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi James, that's the part of my sentence "would require a bit of work ..." to figure out whether and how it works. Before we start I would obviously like to determine whether there is interest. Ciao Hannes James M. Polk wrote: > I didn't think the IETF did liaisons with national organizations (only > international ones)? > > At 06:38 PM 12/14/2006 +0100, Hannes Tschofenig wrote: >> Hi all, >> >> Christian kindly offered the possibility to make the mentioned ATIS >> documents available for our working group. This would require a bit >> of work via the liaison process. Before we invest time to figure out >> how this procedure would work I would like to get feedback from the >> group whether there is interest in obtaining and reviewing the >> documents. >> >> Deadline for a response: 21st December 2006. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 14 15:55:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guxbi-00021E-V3; Thu, 14 Dec 2006 15:55:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guxbg-000218-UY for ecrit@ietf.org; Thu, 14 Dec 2006 15:55:08 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Guxbc-0000nL-MM for ecrit@ietf.org; Thu, 14 Dec 2006 15:55:08 -0500 Received: (qmail invoked by alias); 14 Dec 2006 20:55:03 -0000 Received: from p5498767A.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.118.122] by mail.gmx.net (mp049) with SMTP; 14 Dec 2006 21:55:03 +0100 X-Authenticated: #29516787 Message-ID: <4581BA26.9050202@gmx.net> Date: Thu, 14 Dec 2006 21:55:02 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: ECRIT 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: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Ecrit] ECRIT Wiki X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, we thought about replacing the ECRIT weblog with a wiki. Please find it here: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/ Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Dec 15 09:33:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvE7a-0008B6-DX; Fri, 15 Dec 2006 09:33:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvE7Y-0008Aj-L7; Fri, 15 Dec 2006 09:33:08 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvE7U-0003rG-UD; Fri, 15 Dec 2006 09:33:08 -0500 Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id kBFEWxD7012888; Fri, 15 Dec 2006 15:33:00 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id kBFEWn6d000502; Fri, 15 Dec 2006 15:32:59 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Dec 2006 15:32:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Dec 2006 15:32:54 +0100 Message-ID: <6F0CB04509C11D46A54232E852E390AC0240F63F@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ETSI TISPAN Specialist Task Force working on Location Info for Emergency Services Thread-Index: AccgVef9+NCWfg5CT/6fc3VBjNPWtA== From: "Tschofenig, Hannes" To: , X-OriginalArrivalTime: 15 Dec 2006 14:32:55.0760 (UTC) FILETIME=[E90CFD00:01C72055] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ecrit] ETSI TISPAN Specialist Task Force working on Location Info for Emergency Services X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all,=20 =20 you might be interested to learn that a Specialist Task Force in ETSI TISPAN is going to re-evaluate location information protocols for emergency services. The full title is:=20 " TISPAN Emergency call standards development of Location Information and protocol support for Emergency Communications - review of extended requirements " My understanding of the work is that a small group of consultants are going to review existing location work and determine whether it can fulfill the requirements for emergency services support.=20 =20 Please find more information at: http://portal.etsi.org/Portal_STF/Detail.asp?FullSearch=3DYes&PTCODE=3D31= 5&P TTYPE=3D&TbId=3D625&TabId=3D&SubTB=3D0&Param=3D&SelectSTF=3D&SelectTB=3D&= SelectTBName=3D &SelectStatusSTF =20 Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Dec 15 14:34:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvIpZ-0003t3-OG; Fri, 15 Dec 2006 14:34:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvIpY-0003sZ-9P for ecrit@ietf.org; Fri, 15 Dec 2006 14:34:52 -0500 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvIpV-0005eB-Vc for ecrit@ietf.org; Fri, 15 Dec 2006 14:34:52 -0500 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id A0BDB200AB; Fri, 15 Dec 2006 14:34:49 -0500 (EST) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05920-06; Fri, 15 Dec 2006 14:34:49 -0500 (EST) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 1D7D82002A; Fri, 15 Dec 2006 14:34:49 -0500 (EST) In-Reply-To: <4581AB74.10801@gmx.net> To: Hannes Tschofenig Subject: Re: [Ecrit] Regarding ATIS PRESS RELEASE: ATIS Releases Suite ofIP-basedEmergency Services Standards MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Fri, 15 Dec 2006 14:34:49 -0500 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 12/15/2006 02:34:44 PM, Serialize complete at 12/15/2006 02:34:44 PM Content-Type: text/plain; charset="US-ASCII" X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Christian.Militeau@Intrado.com, ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hmmmm ... Kinda hard to tell if documents are of interest without actually looking at them. But based on Brian's earlier take on these (email 06.12.06), it *sounds* like it is not a major concern. If others on list have also actually read these over, perhaps they could comment on where / if they might or might not interact with ECRIT work items? -- Peter Blatherwick Hannes Tschofenig 14.12.06 14:52 To: "James M. Polk" cc: Christian.Militeau@Intrado.com, ECRIT Subject: Re: [Ecrit] Regarding ATIS PRESS RELEASE: ATIS Releases Suite ofIP-basedEmergency Services Standards Hi James, that's the part of my sentence "would require a bit of work ..." to figure out whether and how it works. Before we start I would obviously like to determine whether there is interest. Ciao Hannes James M. Polk wrote: > I didn't think the IETF did liaisons with national organizations (only > international ones)? > > At 06:38 PM 12/14/2006 +0100, Hannes Tschofenig wrote: >> Hi all, >> >> Christian kindly offered the possibility to make the mentioned ATIS >> documents available for our working group. This would require a bit >> of work via the liaison process. Before we invest time to figure out >> how this procedure would work I would like to get feedback from the >> group whether there is interest in obtaining and reviewing the >> documents. >> >> Deadline for a response: 21st December 2006. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Dec 15 16:37:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvKkT-0007WR-9n; Fri, 15 Dec 2006 16:37:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvJVL-0003KP-6W for ecrit@ietf.org; Fri, 15 Dec 2006 15:18:03 -0500 Received: from smtp01out.dot.gov ([199.79.179.239]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GvJVJ-0005WX-Fu for ecrit@ietf.org; Fri, 15 Dec 2006 15:18:03 -0500 Received: from dothqnwms005.ad.dot.gov ([152.119.86.155]) by smtp01out.dot.gov with ESMTP; 15 Dec 2006 15:17:56 -0500 X-IronPort-AV: i="4.12,176,1165208400"; d="scan'208,217"; a="58851569:sNHT483592272" Received: from OSTMAIL03VS3.ad.dot.gov ([152.119.86.69]) by DOTHQNWMS005.ad.dot.gov with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Dec 2006 15:17:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Dec 2006 15:17:53 -0500 Message-ID: <0A0D0FBCB8154043B909C961D02A7A4402E62EE9@OSTMAIL03VS3.ad.dot.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The U.S. Department of Transportation Next Generation 9-1-1 Project: Notice of Contract Award Thread-Index: Accghhih2CoPadvQSZObaczofTiuYA== From: Bcc: X-OriginalArrivalTime: 15 Dec 2006 20:17:55.0297 (UTC) FILETIME=[1AEFAD10:01C72086] X-Spam-Score: 0.3 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 X-Mailman-Approved-At: Fri, 15 Dec 2006 16:37:43 -0500 Subject: [Ecrit] The U.S. Department of Transportation Next Generation 9-1-1 Project: Notice of Contract Award X-BeenThere: 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="===============0916502830==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0916502830== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72086.1A77E82F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C72086.1A77E82F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The U.S. Department of Transportation (ITS JPO, RITA & EMS Office, NHTSA) has announced the selection of Booz Allen Hamilton, Inc. (BAH) to support the USDOT Next Generation 9-1-1 (NG9-1-1) initiative. =20 The $4.4 million dollar contract requires the team spearheaded by BAH to develop and validate requirements for the NG9-1-1 system, define a system architecture, and develop a transition plan that considers responsibilities, costs, schedule, and benefits for deploying IP-based emergency services across America. The system will be evaluated to determine how it supports emergency call initiation, routing, and processing that will ultimately fulfill public safety emergency response information needs. The contract's period of performance is expected to be two years. The growing market penetration of both cellular and Voice-Over-Internet-Protocol (VOIP) telephony have underscored the limitation of the current 9-1-1 infrastructure. =20 Anticipated benefits to be derived from a next-generation system include: * Quicker and more accurate information delivery to responders; * Better and more useful forms of information: real-time text, images, video, and other data; * More flexible, secure, and robust Public Safety Answering Point (PSAP) operations; and * Lower public capital and operating costs for emergency communication services.=09 NG9-1-1 is one of USDOT's major ITS research initiatives. =20 For detailed information on NG9-1-1 and the other major ITS initiatives, go to the USDOT's ITS Website at www.its.dot.gov. Jenny Hansen, Project Coordinator Next Generation 9-1-1 (NG 9-1-1) www.its.dot.gov/ng911=20 USDOT/NHTSA (202) 366-5598 ------_=_NextPart_001_01C72086.1A77E82F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The U.S. Department of Transportation Next Generation 9-1-1 = Project: Notice of Contract Award

The U.S. Department of Transportation = (ITS JPO, RITA & EMS Office, NHTSA) has announced the selection of = Booz Allen Hamilton, Inc. (BAH) to support the USDOT Next Generation = 9-1-1 (NG9-1-1) initiative. 

The $4.4 million dollar contract = requires the team spearheaded by BAH to develop and validate = requirements for the NG9-1-1 system, define a system architecture, and = develop a transition plan that considers responsibilities, costs, = schedule, and benefits for deploying IP-based emergency services across = America. The system will be evaluated to determine how it supports = emergency call initiation, routing, and processing that will ultimately = fulfill public safety emergency response information needs.  The = contract’s period of performance is expected to be two = years.

The growing market penetration of both = cellular and Voice-Over-Internet-Protocol (VOIP) telephony have = underscored the limitation of the current 9-1-1 infrastructure.  =

Anticipated benefits to be derived from = a next-generation system include:

    • Quicker and more accurate information = delivery to responders;
    • Better and more useful forms of = information:  real-time text, images, video, and other = data;
    • More flexible, secure, and robust = Public Safety Answering Point (PSAP) operations; and
    • Lower public capital and operating = costs for emergency communication services. 

NG9-1-1 is one of USDOT’s major = ITS research initiatives. 
For detailed information on NG9-1-1 = and the other major ITS initiatives, go to the USDOT’s ITS Website = at www.its.dot.gov.

Jenny Hansen, Project = Coordinator
Next Generation 9-1-1 (NG = 9-1-1)
www.its.dot.gov/ng911
USDOT/NHTSA
(202) 366-5598

------_=_NextPart_001_01C72086.1A77E82F-- --===============0916502830== 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 --===============0916502830==-- From ecrit-bounces@ietf.org Sat Dec 16 17:16:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvhpY-0001FB-P4; Sat, 16 Dec 2006 17:16:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvhpX-0001F6-LI for ecrit@ietf.org; Sat, 16 Dec 2006 17:16:31 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvhpW-0000HS-EL for ecrit@ietf.org; Sat, 16 Dec 2006 17:16:31 -0500 Received: from [192.168.0.41] (pool-141-153-196-78.mad.east.verizon.net [141.153.196.78]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kBGMFpMC008955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 16 Dec 2006 17:16:30 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <26DA5548-F561-4B38-9FAB-4673423523DA@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Henning Schulzrinne Date: Sat, 16 Dec 2006 17:16:29 -0500 X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ecrit] Update of draft-ietf-ecrit-mapping-arch X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I have submitted draft-ietf-ecrit-mapping-arch-01 to the I-D editor, with the following major changes: - The document has been restructured to avoid duplication of material. - Since LoST is now the accepted protocol implementing the architecture, I could be somewhat more specific in parts, hopefully making the document easier to follow. - Where applicable, I've avoided text that restricts the architecture only to emergency calling, citing emergency calling as a running example. Comments are appreciated. An HTML version can be found at http://www.cs.columbia.edu/sip/draft/lost-arch/draft-ietf-ecrit- mapping-arch-01.html Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Dec 17 13:33:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw0pI-0000z2-LZ; Sun, 17 Dec 2006 13:33:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw0pH-0000yt-7Y for ecrit@ietf.org; Sun, 17 Dec 2006 13:33:31 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gw0pF-0003d7-U6 for ecrit@ietf.org; Sun, 17 Dec 2006 13:33:31 -0500 Received: from [192.168.0.41] (pool-141-153-196-78.mad.east.verizon.net [141.153.196.78]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kBHIX9r7000263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 17 Dec 2006 13:33:14 -0500 (EST) In-Reply-To: <454E761C.8060603@ntt-at.com> References: <454120F9.50402@cs.columbia.edu> <454E761C.8060603@ntt-at.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <93776093-F3AE-4F71-875B-F01A84DF3B9F@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Changes in LoST -02 Date: Sun, 17 Dec 2006 13:33:08 -0500 To: Shida Schubert X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm in the process of folding in comments into the -03 edition of the LoST spec, which should appear before Christmas. Adding to Andy comments and splitting the response to keep the size manageable: On Nov 5, 2006, at 6:39 PM, Shida Schubert wrote: > > Hi; > > General comments on the 02 version of the draft. > BTW Overall I really like where the draft is going. > 1. Now that the protocol is allowed to carry more than 1 location > information > in the findservice query, it may be a good idea to indicate > which location was > used to find out the URIs. > > Otherwise I don't see how a server(proxy etc.) would be able > to cache a response and > later correlate it to a new request. The text now indicates that the server picks the first-listed profile it understands. The service boundary indicates which one it used (via 'profile'). > > 2. Last paragraph in section 1 talks about how LoST is able to > provide list of services that > are provided in the location requested. Does this always hold > true? I can see that the server > is able to provide a list of services that the server in > question can provide but I don't see > how server will be aware of all the services that is provided > in the area.. (What if service > X is provided at a state level but service Y is provided at a > city level??) I amplified the description to say that this can only be about the services known to a particular server. If a resolver doesn't know about 'food:pizza', it can't provide a useful answer, even if another resolver somewhere is an expert on food delivery services. > > 3. With many location possibly included in the findService is there > any way to > prioritize and indicate the location user wants LoST server > to use? (I might have read the > draft wrong but section 6.3.1 reads as if you can have more > than one location with the > same location-profile..) I clarified that each profile MUST only appear once and that the server picks the first one it knows. > > 4. There is no text explaining the ordering of and its > semantics. If there is no rule, > there is no way for an endpoint to figure out which LoST server > provided the final > resolution. > Added text to the effect that its in response order, i.e., an entity processing a response appends its . > 5. What happens when the LoST query is exhausted while it's being > iterated? You mean 'recursed'? Iteration is done by the querier, so it can give up if there's a loop, such as server A telling the querier to go back to B, where it just came from. > > 6. Can client put an asterisk to indicate it wants all the possible > information LoST server > can provide in "include" attribute. We'll probably drop the 'include' mechanism, so this will become moot. > > 7. Figure 6 shows a response with the ServiceBoundry but it is not > requested in the > request. Is serviceBoundry a MUST in a response? No, but the mechanism of requesting a serviceBoundary (none, value, reference) is still under discussion. > > 8. Section 6.4.7. is the only thing that is > declared optional in the > draft? Is everything else mandatory?? No, everything is optional in a mapping. I've clarified that aspect. > > 9. Section 6.4.4. Let's say the LoST server being queried is > responsible for the city, > and it only provides X and Y. But the server responsible for > state may provide > service X, Y and Z. Would it only return the alternative it is > aware of or should > it query the server responsible for the state and respond > according to what it > finds out.. Let's unwrap this a bit. The resolver knows about several different trees (indirectly, via forest guides). The assumption was (see architecture document) that each tree supports a whole service (e.g., all of urn:service:sos). Things get messier if trees support some subset only. Is this something we want to support? (It's still possible to do that, but the resolver would have to contact multiple trees.) We probably need to have a more in-depth discussion on what we want to use listServices for. This is probably not as well defined as the other operations. > > 10. I don't understand why needs to be > defined. Can't > we just use the findService and have include I'm not sure I understand your question. The idea is that the response, for space reasons, includes the reference, which the client then retrieves. > > 11. does not have the serviceURN in question. > I am assuming > that with LoST server possibly providing different services, > each services can also > have different boundary. If so the request and response should > have the relevant > service. Andy answered that one. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 18 11:07:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwL17-0003VM-If; Mon, 18 Dec 2006 11:07:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwL16-0003VB-Li for ecrit@ietf.org; Mon, 18 Dec 2006 11:07:04 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwL13-0007wh-Ak for ecrit@ietf.org; Mon, 18 Dec 2006 11:07:04 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 5E41E4C953; Mon, 18 Dec 2006 17:06:49 +0100 (CET) Date: Mon, 18 Dec 2006 17:06:49 +0100 From: Otmar Lendl To: ecrit@ietf.org Subject: Re: [Ecrit] Update of draft-ietf-ecrit-mapping-arch Message-ID: <20061218160649.GA21939@nic.at> References: <26DA5548-F561-4B38-9FAB-4673423523DA@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26DA5548-F561-4B38-9FAB-4673423523DA@cs.columbia.edu> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On 2006/12/16 23:12, Henning Schulzrinne wrote: > > Comments are appreciated. > Here are some: In the Definition section: | parent: A mapping server that covers the region of all of its | children. A mapping server without a parent is a root resolver. Shouldn't that be the root AMS? There are two definitions for "resolver": | resolver: A resolver is contacted by a seeker, consults a forest | mapping server and then resolves the query using an appropriate | tree. |... | resolver: Resolvers contact authoritative mapping servers to answer | queries by seekers, and may cache query results. Regarding Forrest Guides: We're running into a contradiction here, e.g.: | For scalability and reliability, there will need to be a | large number of forest guides, all providing the same information. A | seeker can contact any forest guide and will then be directed to the | right tree or, rarely, set of trees. vs. | Trees can also restrict | their cooperation to parts of the information. For example, if | country C does not recognize country T, C can propagate tree regions | for all but T. Either the FGs offer all the same information or they don't. As I see the problem, we have basically two choices: One choice is to keep the forrest guides in sync with each other, with an automated protocol between them. This is the first statement from above plus these three sentences: | A tree node at the top of a tree can contact any forest | guide and inject new coverage region information into the system. | One would expect that each tree announces its coverage to more than | one forest guide. Each forest guide peers with one or more other | guides and distributes new coverage region announcements to all other | guides. In that case, this set of forrest guides act just as another layer in the hierarchical resolution model. Thus we don't actually have a forrest, but a single tree with the cluster of forrest guides as the root. This, of course, reopens the pandora's box of who controls what to put in there, which was the reason for the introduction of the forrest in the first place. Reading between the lines of the security section: Do you propose that the forrest guides just sync a set of digitally signed tree referrals amongst each other and then each FG decides based on local configuration which ones he considers when answering questions? And who is going to decide who can participate in this FG coverage exchange system? The other option is to leave the question of forrest guide synchronization completely out of scope and thus don't even try to solve a political problem with technical means. I have this nagging feeling what we want to have our cake and eat it, too. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 18 13:26:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwNCM-0003R2-3Q; Mon, 18 Dec 2006 13:26:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwNCL-0003Qt-4d for ecrit@ietf.org; Mon, 18 Dec 2006 13:26:49 -0500 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwNCJ-0006S1-P1 for ecrit@ietf.org; Mon, 18 Dec 2006 13:26:49 -0500 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1GwNCJ-0001K4-5A for ecrit@ietf.org; Mon, 18 Dec 2006 13:26:47 -0500 Message-ID: <4586DD67.70703@bbn.com> Date: Mon, 18 Dec 2006 13:26:47 -0500 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Subject: [Ecrit] Comments on draft-ietf-ecrit-mapping-arch-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning, Here are some comments on draft-ietf-ecrit-mapping-arch-01. In general, I like the current state of the document and therefore many of my comments are just minor editorial suggestions. 3. Definitions ----------------- - The term "coverage region" is used frequently throughout the document but is not defined. Consider inserting a definition such as: "The coverage region of an AMS is the geographic region within which the AMS is able to authoritatively answer mapping queries. Coverage regions are generally, but not necessarily, contigous and may be represented as either a subset of a civic address or a geometric object." - The term "region map" is defined but the term only appears in the Security Considerations section. This may be acceptable, however, consider deleting this definition and rewording the security considerations section to use other terms. (Note: If the term 'coverage region' were specifically defined, its definition could include - In Section 7.1 you state "The collection of all trees for one service is known as a forest". For consistancy, you may want to augment the definition of a Forest Guide as follows: "... the coverage regions of all trees for a particular service". Additionally, Section 7.1 indicates that (in a logical sense) each tree provides mappings for a particular service. Therefore, you might want to consider augmenting the definitoin of a tree in a similar fashion: "... of authoritative mapping servers for a particular service." - The term "resolver" is definded twice. The first of the two resolver definitions (the between parent and seeker) appears to be the better one, and so I would recommend deleting the second definition (and adjusting the order of the other entries to preserve alphabetical ordering). However, consider adding a second sentance to the definition indicating that a resolver may also cache mapping results. - I agree with Otmar Lendl regarding the change to the definition of "parent". (I.e., change root resolver to root AMS). - The last sentance of the definition of AMS is unclear: consider "An AMS may redirect or forward a query to another AMS within the tree." 6. Resolver -------------- - The second paragraph states "From a protocol perspective, a resolver acts in the same way as a seeker, except that it knows one or more forest guides." I'm not sure what the phrase "from a protocol perspective" means in this context. In particular, resolvers accept queries from seekers, whereas seekers "have no obligations to other entities in the system" ... this would seem to me to be a difference in behaivor from a protocol perspective. 7.1 Basic Operation ------------------------ - Consider rewording the first sentance of the first paragraph as follows: "... entities, but clients (seekers) may potentially need to find out mapping information for any spot on Earth." - I believe that a location in a query is typically described by either civic or geospatial coordinates (but not both). Therefore, consider rewording the first sentance of the second paragraph as follows: "Each tree can map a location described by civic or geospatial coordinates for ..." - In the second to the last paragraph, you indicate that the difference between coverage region data (stored at non-leafs) and mapping data (stored at leafs) is that coverage regions return LoST URLs whereas mapping entries contain service URLs. However, in your example of data at a leaf node includes an entry with a LoST URL, which seems to imply that leaf node mapping data can include LoST URLs. 8. Forest Guides -------------------- - Section 7.1 indicates that a forest consists of all trees for one service. For consistency, consider rewording the third sentance of the first paragraph as follows: "It is a server that keeps track of the coverage regions of all trees for one service." - The second paragraph states: "For authenticity, the records SHOULD be digitally signed." This is the first (and I believe, only) use of the term "records", therefore I would clarify. Perhaps "the coverage regions returned by a forest guide SHOULD be digitally signed." Also, I fear that it might be unclear to a reader who it is that should be digitally signing the records. (e.g., Might a reader think that the forest guide should be signing the records it sends out?) There is some discussion of this in the security considerations section, however, I think it might be useful to include a forward reference here to the discussion in Section 10. - As Otmar Lendl pointed out, there is a contradiction regarding whether or not all forest guides (for a particular service) contain the same information. My personal viewpoint is that we should accept the fact that all forest guides will not necessarily have consistant information. This is the price we pay for not having a global root. Therefore, I think the less we say about forest guide synchronization the better. It's reasonable to expect that some (hopefully many) forest guides will peer with each other and that each forest guide will share its records with all its peers. However, I don't think its reasonable to expect (as stated in the final sentance of paragraph 3) that each forest guide wil distribute coverage region announcements to ALL other forest guides. - Consider deleting the second sentance of paragraph 4, I believe this has been sentance is redundent given what's been said in paragraphs 1, 2 and 3. If this sentance is deleted, perhaps the 4th and 5th paragraphs could be merged into a single paragraph. 9. Configuring Service Numbers --------------------------------------- - In the last sentance of paragraph 6, delete the word "to" so that the sentance reads: "... uncertain origin, as a user may contact the home network or some local branch office of the corporate network." - In the last paragraph, I think the third sentance would be more clear if it were reworded as follows: "The mapping can be obtained either along with the service URL or through a separate request." - In the last sentance of the last paragraph, replace the final occurance of "the" with "its" so the sentance reads: "... service number for its home location, not just its current its current (visited) location." _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Dec 18 15:51:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwPRo-0002RG-AC; Mon, 18 Dec 2006 15:50:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwPRQ-0001xy-ML; Mon, 18 Dec 2006 15:50:32 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GwPRQ-0000Uk-An; Mon, 18 Dec 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 03A10175DF; Mon, 18 Dec 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GwPQv-00071z-IO; Mon, 18 Dec 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 18 Dec 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-mapping-arch-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Location-to-URL Mapping Architecture and Framework Author(s) : H. Schulzrinne Filename : draft-ietf-ecrit-mapping-arch-01.txt Pages : 17 Date : 2006-12-18 This document describes an architecture for a global, scalable, resilient and administratively distributed system for mapping geographic location information to URLs, using the Location-to- Service (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-mapping-arch-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-mapping-arch-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-18143730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-mapping-arch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-mapping-arch-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-18143730.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Mon Dec 18 22:39:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwVot-0004by-Pw; Mon, 18 Dec 2006 22:39:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwVos-0004bf-2v for ecrit@ietf.org; Mon, 18 Dec 2006 22:39:10 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwVoq-0003ZA-P7 for ecrit@ietf.org; Mon, 18 Dec 2006 22:39:10 -0500 Received: from [192.168.0.41] (pool-141-153-196-78.mad.east.verizon.net [141.153.196.78]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kBJ3d72m017741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Dec 2006 22:39:07 -0500 (EST) In-Reply-To: <20061218160649.GA21939@nic.at> References: <26DA5548-F561-4B38-9FAB-4673423523DA@cs.columbia.edu> <20061218160649.GA21939@nic.at> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Forest guides Date: Mon, 18 Dec 2006 22:39:04 -0500 To: Otmar Lendl X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'll change the subject line to reflect the more substantive issue you are raising. I'm trying to walk a fine line in providing an architectural description that illustrates what's possible, without trying to nail down various practical "governance" approaches. In practice, I think a few options are possible: - A real root, run by somebody. This is plausible for commercial directories for non-emergency services, possibly for a more limited geographic region. Effectively, a single FG or a single tree, depending on how you look at it. - A "cooperative club": A group of organizations that propagate each other's announcements, but have some mechanism for admitting new members. - A "semi-cooperative club": Everybody propagates most records, maybe with exceptions. - Full peering: Each FG peers with all (say) countries it wants to work with. Thus, the "official" US FG would not talk to Iran and Cuba, say, except maybe through Switzerland. In each case, records may be signed or, in a more tightly controlled environment, not. There are probably more variations. I'm not sure I want to detail them all, since I'm reluctant to rule out "business models". Clearly, the text needs to be consistent, so I'll work on that. Henning On Dec 18, 2006, at 11:06 AM, Otmar Lendl wrote: > > Regarding Forrest Guides: > > We're running into a contradiction here, e.g.: > > | For scalability and reliability, there will need to be a > | large number of forest guides, all providing the same > information. A > | seeker can contact any forest guide and will then be directed > to the > | right tree or, rarely, set of trees. > > vs. > > | Trees can also restrict > | their cooperation to parts of the information. For example, if > | country C does not recognize country T, C can propagate tree > regions > | for all but T. > > Either the FGs offer all the same information or they don't. > > As I see the problem, we have basically two choices: > > One choice is to keep the forrest guides in sync with each other, > with > an automated protocol between them. This is the first statement from > above plus these three sentences: > > | A tree node at the top of a tree can contact any forest > | guide and inject new coverage region information into the system. > | One would expect that each tree announces its coverage to more > than > | one forest guide. Each forest guide peers with one or more other > | guides and distributes new coverage region announcements to all > other > | guides. > > In that case, this set of forrest guides act just as another layer in > the hierarchical resolution model. Thus we don't actually have a > forrest, > but a single tree with the cluster of forrest guides as the root. > > This, of course, reopens the pandora's box of who controls what to put > in there, which was the reason for the introduction of the forrest in > the first place. > > Reading between the lines of the security section: Do you propose that > the forrest guides just sync a set of digitally signed tree referrals > amongst each other and then each FG decides based on local > configuration > which ones he considers when answering questions? And who is going to > decide who can participate in this FG coverage exchange system? > > The other option is to leave the question of forrest guide > synchronization > completely out of scope and thus don't even try to solve a > political problem > with technical means. > > I have this nagging feeling what we want to have our cake and eat > it, too. > > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > _______________________________________________ > 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 Dec 19 07:31:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwe85-0005Hg-8E; Tue, 19 Dec 2006 07:31:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwe83-0005Hb-Rx for ecrit@ietf.org; Tue, 19 Dec 2006 07:31:31 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwe82-0002FF-E1 for ecrit@ietf.org; Tue, 19 Dec 2006 07:31:31 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gwe7q-0007Qd-BM; Tue, 19 Dec 2006 06:31:18 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Otmar Lendl'" Subject: RE: [Ecrit] Forest guides Date: Tue, 19 Dec 2006 07:31:14 -0500 Message-ID: <074601c72369$96792b10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AccjHzvxiVF/okRjTmSMJm2aBAb7WwASeZuw In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think there is a problem with this approach. This is ecrit, so the tree that matters is the sos tree. It needs to work, always, no matter where you roam. How do we do that? We can't leave that part without a real plan that will work. You have repeatedly derided the ENUM approach, but, cumbersome though it is, it works. What will work which will allow any caller to determine the route to the PSAP that serves where he is, no matter where he is? That is not a business model. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, December 18, 2006 10:39 PM > To: Otmar Lendl > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Forest guides > > I'll change the subject line to reflect the more substantive issue > you are raising. > > I'm trying to walk a fine line in providing an architectural > description that illustrates what's possible, without trying to nail > down various practical "governance" approaches. In practice, I think > a few options are possible: > > - A real root, run by somebody. This is plausible for commercial > directories for non-emergency services, possibly for a more limited > geographic region. Effectively, a single FG or a single tree, > depending on how you look at it. > > - A "cooperative club": A group of organizations that propagate each > other's announcements, but have some mechanism for admitting new > members. > > - A "semi-cooperative club": Everybody propagates most records, maybe > with exceptions. > > - Full peering: Each FG peers with all (say) countries it wants to > work with. Thus, the "official" US FG would not talk to Iran and > Cuba, say, except maybe through Switzerland. > > In each case, records may be signed or, in a more tightly controlled > environment, not. > > There are probably more variations. I'm not sure I want to detail > them all, since I'm reluctant to rule out "business models". Clearly, > the text needs to be consistent, so I'll work on that. > > > > Henning > > > On Dec 18, 2006, at 11:06 AM, Otmar Lendl wrote: > > > > > Regarding Forrest Guides: > > > > We're running into a contradiction here, e.g.: > > > > | For scalability and reliability, there will need to be a > > | large number of forest guides, all providing the same > > information. A > > | seeker can contact any forest guide and will then be directed > > to the > > | right tree or, rarely, set of trees. > > > > vs. > > > > | Trees can also restrict > > | their cooperation to parts of the information. For example, if > > | country C does not recognize country T, C can propagate tree > > regions > > | for all but T. > > > > Either the FGs offer all the same information or they don't. > > > > As I see the problem, we have basically two choices: > > > > One choice is to keep the forrest guides in sync with each other, > > with > > an automated protocol between them. This is the first statement from > > above plus these three sentences: > > > > | A tree node at the top of a tree can contact any forest > > | guide and inject new coverage region information into the system. > > | One would expect that each tree announces its coverage to more > > than > > | one forest guide. Each forest guide peers with one or more other > > | guides and distributes new coverage region announcements to all > > other > > | guides. > > > > In that case, this set of forrest guides act just as another layer in > > the hierarchical resolution model. Thus we don't actually have a > > forrest, > > but a single tree with the cluster of forrest guides as the root. > > > > This, of course, reopens the pandora's box of who controls what to put > > in there, which was the reason for the introduction of the forrest in > > the first place. > > > > Reading between the lines of the security section: Do you propose that > > the forrest guides just sync a set of digitally signed tree referrals > > amongst each other and then each FG decides based on local > > configuration > > which ones he considers when answering questions? And who is going to > > decide who can participate in this FG coverage exchange system? > > > > The other option is to leave the question of forrest guide > > synchronization > > completely out of scope and thus don't even try to solve a > > political problem > > with technical means. > > > > I have this nagging feeling what we want to have our cake and eat > > it, too. > > > > /ol > > -- > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 19 07:54:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GweTs-0007Mq-BA; Tue, 19 Dec 2006 07:54:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GweTr-0007MZ-Fj for ecrit@ietf.org; Tue, 19 Dec 2006 07:54:03 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GweTp-0006ys-2D for ecrit@ietf.org; Tue, 19 Dec 2006 07:54:03 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 4898C4C567; Tue, 19 Dec 2006 13:53:56 +0100 (CET) Date: Tue, 19 Dec 2006 13:53:56 +0100 From: Otmar Lendl To: Henning Schulzrinne Subject: Re: [Ecrit] Forest guides Message-ID: <20061219125356.GA10755@nic.at> References: <26DA5548-F561-4B38-9FAB-4673423523DA@cs.columbia.edu> <20061218160649.GA21939@nic.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On 2006/12/19 04:12, Henning Schulzrinne wrote: > I'll change the subject line to reflect the more substantive issue > you are raising. Good. > I'm trying to walk a fine line in providing an architectural > description that illustrates what's possible, without trying to nail > down various practical "governance" approaches. In practice, I think > a few options are possible: Your list of options makes a lot of sense. I'm a bit lost though, what the process will be to to establish one of these options as the solution which will be deployed. My experience in the ENUM world makes me a bit wary about mixing protocol issues with world-wide political agreements. There are many pitfalls and potential delays (dare I say "ITU"?) to consider when trying to forge world-wide cooperation for this collaborative effort. Based on this, I'd rule out > - A real root, run by somebody. This is plausible for commercial > directories for non-emergency services, possibly for a more limited > geographic region. Effectively, a single FG or a single tree, > depending on how you look at it. > > - A "cooperative club": A group of organizations that propagate each > other's announcements, but have some mechanism for admitting new > members. as a short-term solution. > - A "semi-cooperative club": Everybody propagates most records, maybe > with exceptions. > > - Full peering: Each FG peers with all (say) countries it wants to > work with. Thus, the "official" US FG would not talk to Iran and > Cuba, say, except maybe through Switzerland. These two options are more reasonable in the short term, though I'm not sure that even such a loose cooperation between countries is easy and fast to set up. > In each case, records may be signed or, in a more tightly controlled > environment, not. That depends a lot on protocol details for overage announcements and FG synchronization. Perhaps we just need to specify a data-format which each country/organization can use to publish it's coverage region with the entrance point to its tree. Anybody then can aggregate this information as they wish to configure their FG. One of the open questions is whether we should even try to develop a protocol for FG synchronization. That data is rather static anyway, so I don't see the pressing need to encode all the politics of which coverage announcements to honor into software. As I see it, either go for an ENUM-like worldwide agreement, or leave the question of FGs open to competing aggregation services. (Similar to RSS aggregation or news.google.com) /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 19 08:38:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwfAt-0000Af-QQ; Tue, 19 Dec 2006 08:38:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwfAt-00009b-0x for ecrit@ietf.org; Tue, 19 Dec 2006 08:38:31 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwfAq-0008R3-NC for ecrit@ietf.org; Tue, 19 Dec 2006 08:38:31 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 19 Dec 2006 08:37:54 -0500 id 0158842F.4587EB32.00006EB3 In-Reply-To: <20061219125356.GA10755@nic.at> References: <26DA5548-F561-4B38-9FAB-4673423523DA@cs.columbia.edu> <20061218160649.GA21939@nic.at> <20061219125356.GA10755@nic.at> Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: [Ecrit] Forest guides Date: Tue, 19 Dec 2006 08:38:07 -0500 To: Otmar Lendl X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1699582143==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1699582143== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-28343-1166535486-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-28343-1166535486-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Dec 19, 2006, at 7:53 AM, Otmar Lendl wrote: > One of the open questions is whether we should even try to develop > a protocol for FG synchronization. That data is rather static > anyway, so > I don't see the pressing need to encode all the politics of which > coverage announcements to honor into software. We've been through this in the working group, and it has been subject of much controversy. I believe we now have a fair compromise, leaving out the server synchronization from the base spec but doing those things we know will make synchronization more viable. Henning has a draft on synchronization of servers (which I don't believe would be any different for authoritative-to-authoritative than FG-to- FG). While I reman skeptical that such a scheme would be better than back-end data store schemes already in existence for tightly coupled clusters, Henning's approach seems very reasonable for the many other situations, such as FG-to-FG. If some FGs decide not to run the synchronization aspect, it should not preclude others from doing so. > As I see it, either go for an ENUM-like worldwide agreement, or leave > the question of FGs open to competing aggregation services. Given the ability of the world to agree upon issues at the moment, I'm not holding my breathe for anything ENUM-like. -andy --=_zeke.ecotroph.net-28343-1166535486-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3
On Dec 19, 2006, at 7:5= 3 AM, Otmar Lendl wrote:

One of th= e open questions is whether we should even try to develop

a protocol for FG synchronization. T= hat data is rather static anyway, so

I don't see the pressing need to encode all the politics = of which

coverage ann= ouncements to honor into software.


We've been through this in the wo= rking group, and it has been subject of much controversy.=A0 I believe we= now have a fair compromise, leaving out the server synchronization from = the base spec but doing those things we know will make synchronization mo= re viable.=A0 Henning has a draft on synchronization of servers (which I = don't believe would be any different for authoritative-to-authoritative t= han FG-to-FG).=A0 While I reman skeptical that such a scheme would be bet= ter than back-end data store schemes already in existence for tightly cou= pled clusters, Henning's approach seems very reasonable for the many othe= r situations, such as FG-to-FG.=A0 If some FGs decide not to run the sync= hronization aspect, it should not preclude others from doing so.

<= FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">As I = see it, either go for an ENUM-like worldwide agreement, or leave

the question of FGs open to c= ompeting aggregation services.


Giv= en the ability of the world to agree upon issues at the moment, I'm not h= olding my breathe for anything ENUM-like.

-andy
--=_zeke.ecotroph.net-28343-1166535486-0001-2-- --===============1699582143== 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 --===============1699582143==-- From ecrit-bounces@ietf.org Tue Dec 19 10:24:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwgpm-0007jK-HS; Tue, 19 Dec 2006 10:24:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwgpl-0007jC-5r; Tue, 19 Dec 2006 10:24:49 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwgpj-0007OW-Lt; Tue, 19 Dec 2006 10:24:49 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Dec 2006 15:24:44 +0000 Received: from mail pickup service by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 19 Dec 2006 15:24:04 +0000 Received: from smtp3.smtp.bt.com ([217.32.164.170]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Dec 2006 20:54:06 +0000 Received: from megatron.ietf.org ([156.154.16.145]) by smtp3.smtp.bt.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 20:54:04 +0000 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwPRr-0002V5-TV; Mon, 18 Dec 2006 15:50:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwPRQ-0001xy-ML; Mon, 18 Dec 2006 15:50:32 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GwPRQ-0000Uk-An; Mon, 18 Dec 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 03A10175DF; Mon, 18 Dec 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GwPQv-00071z-IO; Mon, 18 Dec 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 18 Dec 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-OriginalArrivalTime: 18 Dec 2006 20:54:04.0432 (UTC) FILETIME=[A714A900:01C722E6] X-Spam-Score: 0.3 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-mapping-arch-01.txt X-BeenThere: ecrit@ietf.org Reply-To: internet-drafts@ietf.org List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Location-to-URL Mapping Architecture and Framework Author(s) : H. Schulzrinne Filename : draft-ietf-ecrit-mapping-arch-01.txt Pages : 17 Date : 2006-12-18 This document describes an architecture for a global, scalable, resilient and administratively distributed system for mapping geographic location information to URLs, using the Location-to- Service (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-mapping-arch-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-mapping-arch-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-18143730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-mapping-arch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-mapping-arch-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-18143730.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Tue Dec 19 15:24:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwlVh-0007FK-WB; Tue, 19 Dec 2006 15:24:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwlVh-0007Da-9F for ecrit@ietf.org; Tue, 19 Dec 2006 15:24:25 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwlVe-0001fI-TO for ecrit@ietf.org; Tue, 19 Dec 2006 15:24:24 -0500 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kBJKO1Oa014508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 19 Dec 2006 15:24:14 -0500 (EST) In-Reply-To: <20061219125356.GA10755@nic.at> References: <26DA5548-F561-4B38-9FAB-4673423523DA@cs.columbia.edu> <20061218160649.GA21939@nic.at> <20061219125356.GA10755@nic.at> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Forest guides Date: Tue, 19 Dec 2006 15:24:39 -0500 To: Otmar Lendl X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > I'm a bit lost though, what the process will be to to establish one > of these options as the solution which will be deployed. My experience > in the ENUM world makes me a bit wary about mixing protocol issues > with world-wide political agreements. There are many pitfalls > and potential delays (dare I say "ITU"?) to consider when trying > to forge world-wide cooperation for this collaborative effort. I agree. Unlike for ENUM, I hope we don't have to wait for a "big bang" that creates a nice, cooperative universe. Rather, I suspect a more likely scenario is bottom up, rather than top down. In other words, US states each build their own tree, as does Austria. First, some subset of US states cooperate, e.g., regionally. (This is not uncommon in other cases, and makes sense, given the "continental divide" and the uneven distribution of population in the US. As one recent example, take the propagation of EZPass, the electronic toll collection system. Started either in NY or NJ and is now slowly spreading west, north and south.) On a peer-to-peer basis, Austria and the US then peer, adding in other interested countries. Maybe Canada gets added next, etc. >> >> - A "cooperative club": A group of organizations that propagate each >> other's announcements, but have some mechanism for admitting new >> members. > > as a short-term solution. The latter seems actually pretty reasonable to me, except maybe to add that there may be several such "clubs" in the beginning, say a "European" club and a "North American" club. > >> - A "semi-cooperative club": Everybody propagates most records, maybe >> with exceptions. >> >> - Full peering: Each FG peers with all (say) countries it wants to >> work with. Thus, the "official" US FG would not talk to Iran and >> Cuba, say, except maybe through Switzerland. > > These two options are more reasonable in the short term, though I'm > not > sure that even such a loose cooperation between countries is easy and > fast to set up. I'm hoping that some of the problems are a bit easier than for ENUM: There are clear jurisdictional responsibilities in each country and the ownership issues are easier, compared to E.164. As long as countries don't claim each other's territory, there don't seem to be insurmountable coordination problems. > > Perhaps we just need to specify a data-format which each > country/organization can use to publish it's coverage region with the > entrance point to its tree. Anybody then can aggregate this > information > as they wish to configure their FG. That format has been (implicitly) specific, namely , where the is a LoST URL. (This element will appear in -03.) As Andy pointed out, the lost-sync draft allows FGs to exchange these. Whether they'll use the tool, I don't know, but they definitely won't if it isn't available. I suspect that anything involving different organizations will require some kind of protocol mechanism, even if it's ftp. > > One of the open questions is whether we should even try to develop > a protocol for FG synchronization. That data is rather static > anyway, so > I don't see the pressing need to encode all the politics of which > coverage announcements to honor into software. > > As I see it, either go for an ENUM-like worldwide agreement, or leave > the question of FGs open to competing aggregation services. As far as I can tell, the architecture precludes neither outcome, so I think we don't need to polish our crystal ball too much. > (Similar to RSS aggregation or news.google.com) > > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 19 15:47:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwlrV-0002U3-2X; Tue, 19 Dec 2006 15:46:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwlrT-0002Tt-KJ for ecrit@ietf.org; Tue, 19 Dec 2006 15:46:55 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwlrS-00077V-D2 for ecrit@ietf.org; Tue, 19 Dec 2006 15:46:55 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Dec 2006 15:46:55 -0500 X-IronPort-AV: i="4.12,188,1165208400"; d="scan'208"; a="109875743:sNHT41844704" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBJKksQo029066; Tue, 19 Dec 2006 15:46:54 -0500 Received: from [68.49.215.202] (che-vpn-cluster-1-142.cisco.com [10.86.240.142]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBJKkrOd029172; Tue, 19 Dec 2006 15:46:53 -0500 (EST) In-Reply-To: References: <26DA5548-F561-4B38-9FAB-4673423523DA@cs.columbia.edu> <20061218160649.GA21939@nic.at> <20061219125356.GA10755@nic.at> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] Forest guides Date: Tue, 19 Dec 2006 15:46:52 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.624) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=432; t=1166561214; x=1167425214; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:=20John=20Schnizlein=20 |Subject:=20Re=3A=20[Ecrit]=20Forest=20guides |Sender:=20 |To:=20Henning=20Schulzrinne=20; bh=Bn0JrZgF7ZiXrrFmlvHM9pPuOoyYi/L8AQ50YA8Cx1A=; b=qQC04lz2hgdi2pKEAQIkBtktUyx4FRcg2zl0wS+zkKFwrJZMNfxZopC+vCbsCuh2/x1Wp8SJ tOL3OFYtFiuaH/+UqCmKYFPHzrGG52hMs86uQpxZoVTxWDXXDlh7aYX1; Authentication-Results: rtp-dkim-2; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Otmar Lendl , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I hope it can be accomplished without multiple separate systems and a phase of interoperability engineering as this history of EZPass suggests: http://en.wikipedia.org/wiki/EZPass On Dec 19, 2006, at 3:24 PM, Henning Schulzrinne wrote: > As one recent example, take the propagation of EZPass, the electronic > toll collection system. Started either in NY or NJ and is now slowly > spreading west, north and south.) _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Dec 19 22:24:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gws4W-0006HJ-5q; Tue, 19 Dec 2006 22:24:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gws4U-0006EA-JY for ecrit@ietf.org; Tue, 19 Dec 2006 22:24:46 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gws4T-0001Dz-84 for ecrit@ietf.org; Tue, 19 Dec 2006 22:24:46 -0500 Received: from [192.168.0.41] (pool-141-153-196-78.mad.east.verizon.net [141.153.196.78]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kBK3OQZY017644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 19 Dec 2006 22:24:29 -0500 (EST) In-Reply-To: <074601c72369$96792b10$640fa8c0@cis.neustar.com> References: <074601c72369$96792b10$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <01662E97-DCDD-4A4A-A107-9ECE45500034@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Forest guides Date: Tue, 19 Dec 2006 22:24:25 -0500 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: 'Otmar Lendl' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, I share your concern, but I believe that solving the policy problem is beyond the scope of ECRIT. Just like ENUM didn't try to deal with the ITU to set up (or not) e164.arpa, I don't think we can do working group documents that describe this. There is one commonality between this discussion and the ENUM effort: Since countries and even regions within a country are going to move at very different speeds on all-IP emergency calling, it seems unlikely that we'll have the same sense of urgency globally at the same time, so I think it's important to have an architecture that can evolve over time. To answer your direct question: I think we have several possible plans that can work, where "work" means that all accessible FGs can be accessed. (Which doesn't mean that things will work in every country, simply because there may be no authoritative servers at all.) ISPs and VSPs will operate resolvers that point to FGs, either operated by them or some government authority. Henning On Dec 19, 2006, at 7:31 AM, Brian Rosen wrote: > I think there is a problem with this approach. This is ecrit, so > the tree > that matters is the sos tree. It needs to work, always, no matter > where you > roam. How do we do that? > > We can't leave that part without a real plan that will work. You have > repeatedly derided the ENUM approach, but, cumbersome though it is, it > works. What will work which will allow any caller to determine the > route to > the PSAP that serves where he is, no matter where he is? > > That is not a business model. > > Brian > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Monday, December 18, 2006 10:39 PM >> To: Otmar Lendl >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Forest guides >> >> I'll change the subject line to reflect the more substantive issue >> you are raising. >> >> I'm trying to walk a fine line in providing an architectural >> description that illustrates what's possible, without trying to nail >> down various practical "governance" approaches. In practice, I think >> a few options are possible: >> >> - A real root, run by somebody. This is plausible for commercial >> directories for non-emergency services, possibly for a more limited >> geographic region. Effectively, a single FG or a single tree, >> depending on how you look at it. >> >> - A "cooperative club": A group of organizations that propagate each >> other's announcements, but have some mechanism for admitting new >> members. >> >> - A "semi-cooperative club": Everybody propagates most records, maybe >> with exceptions. >> >> - Full peering: Each FG peers with all (say) countries it wants to >> work with. Thus, the "official" US FG would not talk to Iran and >> Cuba, say, except maybe through Switzerland. >> >> In each case, records may be signed or, in a more tightly controlled >> environment, not. >> >> There are probably more variations. I'm not sure I want to detail >> them all, since I'm reluctant to rule out "business models". Clearly, >> the text needs to be consistent, so I'll work on that. >> >> >> >> Henning >> >> >> On Dec 18, 2006, at 11:06 AM, Otmar Lendl wrote: >> >>> >>> Regarding Forrest Guides: >>> >>> We're running into a contradiction here, e.g.: >>> >>> | For scalability and reliability, there will need to be a >>> | large number of forest guides, all providing the same >>> information. A >>> | seeker can contact any forest guide and will then be directed >>> to the >>> | right tree or, rarely, set of trees. >>> >>> vs. >>> >>> | Trees can also restrict >>> | their cooperation to parts of the information. For example, if >>> | country C does not recognize country T, C can propagate tree >>> regions >>> | for all but T. >>> >>> Either the FGs offer all the same information or they don't. >>> >>> As I see the problem, we have basically two choices: >>> >>> One choice is to keep the forrest guides in sync with each other, >>> with >>> an automated protocol between them. This is the first statement from >>> above plus these three sentences: >>> >>> | A tree node at the top of a tree can contact any forest >>> | guide and inject new coverage region information into the >>> system. >>> | One would expect that each tree announces its coverage to more >>> than >>> | one forest guide. Each forest guide peers with one or more >>> other >>> | guides and distributes new coverage region announcements to all >>> other >>> | guides. >>> >>> In that case, this set of forrest guides act just as another >>> layer in >>> the hierarchical resolution model. Thus we don't actually have a >>> forrest, >>> but a single tree with the cluster of forrest guides as the root. >>> >>> This, of course, reopens the pandora's box of who controls what >>> to put >>> in there, which was the reason for the introduction of the >>> forrest in >>> the first place. >>> >>> Reading between the lines of the security section: Do you propose >>> that >>> the forrest guides just sync a set of digitally signed tree >>> referrals >>> amongst each other and then each FG decides based on local >>> configuration >>> which ones he considers when answering questions? And who is >>> going to >>> decide who can participate in this FG coverage exchange system? >>> >>> The other option is to leave the question of forrest guide >>> synchronization >>> completely out of scope and thus don't even try to solve a >>> political problem >>> with technical means. >>> >>> I have this nagging feeling what we want to have our cake and eat >>> it, too. >>> >>> /ol >>> -- >>> < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 20 07:35:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx0ew-0006Yo-5x; Wed, 20 Dec 2006 07:34:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx0ev-0006Yj-Jd for ecrit@ietf.org; Wed, 20 Dec 2006 07:34:57 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx0eu-0004g8-3K for ecrit@ietf.org; Wed, 20 Dec 2006 07:34:57 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gx0ej-0001rB-O5; Wed, 20 Dec 2006 06:34:46 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Forest guides Date: Wed, 20 Dec 2006 07:34:44 -0500 Message-ID: <098001c72433$3d133730$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Accj5l8zymzLKcXwT/yGgnAd1GamkwAS+Nfw In-Reply-To: <01662E97-DCDD-4A4A-A107-9ECE45500034@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: 'Otmar Lendl' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning I don't see this as a policy issue. I see it as a design issue. What is the design of the Forest Guides for the world's emergency call routing database going to be? When they worked out the design of ENUM, they planned for the ITU to do the delegation. They asked ITU if it was willing to do the delegation, and the positive answer was known well before the documents were published. They created a design, and they were pretty sure it would be implemented, however slowly and ungainly. We need a plan, not a hand wave, and not a "could be this, could be that". We need to state what our expectations are, and we need to do some checks to make sure that at least a few key regions are willing to do it that way. We don't have to write rules for governments, but we have to describe something that will work, something we can write code to. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, December 19, 2006 10:24 PM > To: Brian Rosen > Cc: 'Otmar Lendl'; ecrit@ietf.org > Subject: Re: [Ecrit] Forest guides > > Brian, > > I share your concern, but I believe that solving the policy problem > is beyond the scope of ECRIT. Just like ENUM didn't try to deal with > the ITU to set up (or not) e164.arpa, I don't think we can do working > group documents that describe this. There is one commonality between > this discussion and the ENUM effort: Since countries and even regions > within a country are going to move at very different speeds on all-IP > emergency calling, it seems unlikely that we'll have the same sense > of urgency globally at the same time, so I think it's important to > have an architecture that can evolve over time. > > To answer your direct question: I think we have several possible > plans that can work, where "work" means that all accessible FGs can > be accessed. (Which doesn't mean that things will work in every > country, simply because there may be no authoritative servers at > all.) ISPs and VSPs will operate resolvers that point to FGs, either > operated by them or some government authority. > > Henning > > On Dec 19, 2006, at 7:31 AM, Brian Rosen wrote: > > > I think there is a problem with this approach. This is ecrit, so > > the tree > > that matters is the sos tree. It needs to work, always, no matter > > where you > > roam. How do we do that? > > > > We can't leave that part without a real plan that will work. You have > > repeatedly derided the ENUM approach, but, cumbersome though it is, it > > works. What will work which will allow any caller to determine the > > route to > > the PSAP that serves where he is, no matter where he is? > > > > That is not a business model. > > > > Brian > > > >> -----Original Message----- > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> Sent: Monday, December 18, 2006 10:39 PM > >> To: Otmar Lendl > >> Cc: ecrit@ietf.org > >> Subject: Re: [Ecrit] Forest guides > >> > >> I'll change the subject line to reflect the more substantive issue > >> you are raising. > >> > >> I'm trying to walk a fine line in providing an architectural > >> description that illustrates what's possible, without trying to nail > >> down various practical "governance" approaches. In practice, I think > >> a few options are possible: > >> > >> - A real root, run by somebody. This is plausible for commercial > >> directories for non-emergency services, possibly for a more limited > >> geographic region. Effectively, a single FG or a single tree, > >> depending on how you look at it. > >> > >> - A "cooperative club": A group of organizations that propagate each > >> other's announcements, but have some mechanism for admitting new > >> members. > >> > >> - A "semi-cooperative club": Everybody propagates most records, maybe > >> with exceptions. > >> > >> - Full peering: Each FG peers with all (say) countries it wants to > >> work with. Thus, the "official" US FG would not talk to Iran and > >> Cuba, say, except maybe through Switzerland. > >> > >> In each case, records may be signed or, in a more tightly controlled > >> environment, not. > >> > >> There are probably more variations. I'm not sure I want to detail > >> them all, since I'm reluctant to rule out "business models". Clearly, > >> the text needs to be consistent, so I'll work on that. > >> > >> > >> > >> Henning > >> > >> > >> On Dec 18, 2006, at 11:06 AM, Otmar Lendl wrote: > >> > >>> > >>> Regarding Forrest Guides: > >>> > >>> We're running into a contradiction here, e.g.: > >>> > >>> | For scalability and reliability, there will need to be a > >>> | large number of forest guides, all providing the same > >>> information. A > >>> | seeker can contact any forest guide and will then be directed > >>> to the > >>> | right tree or, rarely, set of trees. > >>> > >>> vs. > >>> > >>> | Trees can also restrict > >>> | their cooperation to parts of the information. For example, if > >>> | country C does not recognize country T, C can propagate tree > >>> regions > >>> | for all but T. > >>> > >>> Either the FGs offer all the same information or they don't. > >>> > >>> As I see the problem, we have basically two choices: > >>> > >>> One choice is to keep the forrest guides in sync with each other, > >>> with > >>> an automated protocol between them. This is the first statement from > >>> above plus these three sentences: > >>> > >>> | A tree node at the top of a tree can contact any forest > >>> | guide and inject new coverage region information into the > >>> system. > >>> | One would expect that each tree announces its coverage to more > >>> than > >>> | one forest guide. Each forest guide peers with one or more > >>> other > >>> | guides and distributes new coverage region announcements to all > >>> other > >>> | guides. > >>> > >>> In that case, this set of forrest guides act just as another > >>> layer in > >>> the hierarchical resolution model. Thus we don't actually have a > >>> forrest, > >>> but a single tree with the cluster of forrest guides as the root. > >>> > >>> This, of course, reopens the pandora's box of who controls what > >>> to put > >>> in there, which was the reason for the introduction of the > >>> forrest in > >>> the first place. > >>> > >>> Reading between the lines of the security section: Do you propose > >>> that > >>> the forrest guides just sync a set of digitally signed tree > >>> referrals > >>> amongst each other and then each FG decides based on local > >>> configuration > >>> which ones he considers when answering questions? And who is > >>> going to > >>> decide who can participate in this FG coverage exchange system? > >>> > >>> The other option is to leave the question of forrest guide > >>> synchronization > >>> completely out of scope and thus don't even try to solve a > >>> political problem > >>> with technical means. > >>> > >>> I have this nagging feeling what we want to have our cake and eat > >>> it, too. > >>> > >>> /ol > >>> -- > >>> < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ecrit > >> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 20 08:19:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx1MF-0001Gn-Vy; Wed, 20 Dec 2006 08:19:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx1MF-0001Gi-1l for ecrit@ietf.org; Wed, 20 Dec 2006 08:19:43 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx1MD-0006l5-MK for ecrit@ietf.org; Wed, 20 Dec 2006 08:19:43 -0500 Received: from [192.168.0.41] (pool-141-153-196-78.mad.east.verizon.net [141.153.196.78]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kBKDJW4m017153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Dec 2006 08:19:33 -0500 (EST) In-Reply-To: <098001c72433$3d133730$640fa8c0@cis.neustar.com> References: <098001c72433$3d133730$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8DA7FED6-E259-4C3C-86CE-D1062774A8ED@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Forest guides Date: Wed, 20 Dec 2006 08:19:29 -0500 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: 'Otmar Lendl' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, I agree that we should check with a few regions, but unlike ENUM, where plausibly the IAB, and ITU could claim "ownership" (due to owning E.164 and the DNS root), there doesn't seem to be a natural point of initial contact. Who would be the authoritative contact in the US, just to pick a relatively simple example? Henning On Dec 20, 2006, at 7:34 AM, Brian Rosen wrote: > Henning > > I don't see this as a policy issue. I see it as a design issue. > What is > the design of the Forest Guides for the world's emergency call routing > database going to be? > > When they worked out the design of ENUM, they planned for the ITU > to do the > delegation. They asked ITU if it was willing to do the delegation, > and the > positive answer was known well before the documents were > published. They > created a design, and they were pretty sure it would be > implemented, however > slowly and ungainly. > > We need a plan, not a hand wave, and not a "could be this, could be > that". > We need to state what our expectations are, and we need to do some > checks to > make sure that at least a few key regions are willing to do it that > way. We > don't have to write rules for governments, but we have to describe > something > that will work, something we can write code to. > > Brian > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Tuesday, December 19, 2006 10:24 PM >> To: Brian Rosen >> Cc: 'Otmar Lendl'; ecrit@ietf.org >> Subject: Re: [Ecrit] Forest guides >> >> Brian, >> >> I share your concern, but I believe that solving the policy problem >> is beyond the scope of ECRIT. Just like ENUM didn't try to deal with >> the ITU to set up (or not) e164.arpa, I don't think we can do working >> group documents that describe this. There is one commonality between >> this discussion and the ENUM effort: Since countries and even regions >> within a country are going to move at very different speeds on all-IP >> emergency calling, it seems unlikely that we'll have the same sense >> of urgency globally at the same time, so I think it's important to >> have an architecture that can evolve over time. >> >> To answer your direct question: I think we have several possible >> plans that can work, where "work" means that all accessible FGs can >> be accessed. (Which doesn't mean that things will work in every >> country, simply because there may be no authoritative servers at >> all.) ISPs and VSPs will operate resolvers that point to FGs, either >> operated by them or some government authority. >> >> Henning >> >> On Dec 19, 2006, at 7:31 AM, Brian Rosen wrote: >> >>> I think there is a problem with this approach. This is ecrit, so >>> the tree >>> that matters is the sos tree. It needs to work, always, no matter >>> where you >>> roam. How do we do that? >>> >>> We can't leave that part without a real plan that will work. You >>> have >>> repeatedly derided the ENUM approach, but, cumbersome though it >>> is, it >>> works. What will work which will allow any caller to determine the >>> route to >>> the PSAP that serves where he is, no matter where he is? >>> >>> That is not a business model. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>> Sent: Monday, December 18, 2006 10:39 PM >>>> To: Otmar Lendl >>>> Cc: ecrit@ietf.org >>>> Subject: Re: [Ecrit] Forest guides >>>> >>>> I'll change the subject line to reflect the more substantive issue >>>> you are raising. >>>> >>>> I'm trying to walk a fine line in providing an architectural >>>> description that illustrates what's possible, without trying to >>>> nail >>>> down various practical "governance" approaches. In practice, I >>>> think >>>> a few options are possible: >>>> >>>> - A real root, run by somebody. This is plausible for commercial >>>> directories for non-emergency services, possibly for a more limited >>>> geographic region. Effectively, a single FG or a single tree, >>>> depending on how you look at it. >>>> >>>> - A "cooperative club": A group of organizations that propagate >>>> each >>>> other's announcements, but have some mechanism for admitting new >>>> members. >>>> >>>> - A "semi-cooperative club": Everybody propagates most records, >>>> maybe >>>> with exceptions. >>>> >>>> - Full peering: Each FG peers with all (say) countries it wants to >>>> work with. Thus, the "official" US FG would not talk to Iran and >>>> Cuba, say, except maybe through Switzerland. >>>> >>>> In each case, records may be signed or, in a more tightly >>>> controlled >>>> environment, not. >>>> >>>> There are probably more variations. I'm not sure I want to detail >>>> them all, since I'm reluctant to rule out "business models". >>>> Clearly, >>>> the text needs to be consistent, so I'll work on that. >>>> >>>> >>>> >>>> Henning >>>> >>>> >>>> On Dec 18, 2006, at 11:06 AM, Otmar Lendl wrote: >>>> >>>>> >>>>> Regarding Forrest Guides: >>>>> >>>>> We're running into a contradiction here, e.g.: >>>>> >>>>> | For scalability and reliability, there will need to be a >>>>> | large number of forest guides, all providing the same >>>>> information. A >>>>> | seeker can contact any forest guide and will then be directed >>>>> to the >>>>> | right tree or, rarely, set of trees. >>>>> >>>>> vs. >>>>> >>>>> | Trees can also restrict >>>>> | their cooperation to parts of the information. For >>>>> example, if >>>>> | country C does not recognize country T, C can propagate tree >>>>> regions >>>>> | for all but T. >>>>> >>>>> Either the FGs offer all the same information or they don't. >>>>> >>>>> As I see the problem, we have basically two choices: >>>>> >>>>> One choice is to keep the forrest guides in sync with each other, >>>>> with >>>>> an automated protocol between them. This is the first statement >>>>> from >>>>> above plus these three sentences: >>>>> >>>>> | A tree node at the top of a tree can contact any forest >>>>> | guide and inject new coverage region information into the >>>>> system. >>>>> | One would expect that each tree announces its coverage to more >>>>> than >>>>> | one forest guide. Each forest guide peers with one or more >>>>> other >>>>> | guides and distributes new coverage region announcements to >>>>> all >>>>> other >>>>> | guides. >>>>> >>>>> In that case, this set of forrest guides act just as another >>>>> layer in >>>>> the hierarchical resolution model. Thus we don't actually have a >>>>> forrest, >>>>> but a single tree with the cluster of forrest guides as the root. >>>>> >>>>> This, of course, reopens the pandora's box of who controls what >>>>> to put >>>>> in there, which was the reason for the introduction of the >>>>> forrest in >>>>> the first place. >>>>> >>>>> Reading between the lines of the security section: Do you propose >>>>> that >>>>> the forrest guides just sync a set of digitally signed tree >>>>> referrals >>>>> amongst each other and then each FG decides based on local >>>>> configuration >>>>> which ones he considers when answering questions? And who is >>>>> going to >>>>> decide who can participate in this FG coverage exchange system? >>>>> >>>>> The other option is to leave the question of forrest guide >>>>> synchronization >>>>> completely out of scope and thus don't even try to solve a >>>>> political problem >>>>> with technical means. >>>>> >>>>> I have this nagging feeling what we want to have our cake and eat >>>>> it, too. >>>>> >>>>> /ol >>>>> -- >>>>> < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 20 08:31:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx1Xf-0001J5-AL; Wed, 20 Dec 2006 08:31:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx1Xe-0001Iv-3w for ecrit@ietf.org; Wed, 20 Dec 2006 08:31:30 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx1Xd-0000Ir-27 for ecrit@ietf.org; Wed, 20 Dec 2006 08:31:30 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gx1XW-0003cb-GZ; Wed, 20 Dec 2006 07:31:23 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Forest guides Date: Wed, 20 Dec 2006 08:31:21 -0500 Message-ID: <099901c7243b$258c4a90$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcckOX6nu5CmpESoRkSjeXDgiAoo0AAARdPw In-Reply-To: <8DA7FED6-E259-4C3C-86CE-D1062774A8ED@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: 'Otmar Lendl' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org In the U.S., you ask NENA, and you, for completeness, ask the FCC. The FCC may not answer in a time frame that matters. NENA would. But what are we asking? If we have a plan, and we're validating that the entities that have to implement some part of the plan are agreeable, then the above is a good answer. We don't (yet) have a plan. We have "maybe this, maybe that, maybe something else". Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, December 20, 2006 8:19 AM > To: Brian Rosen > Cc: 'Otmar Lendl'; ecrit@ietf.org > Subject: Re: [Ecrit] Forest guides > > Brian, > > I agree that we should check with a few regions, but unlike ENUM, > where plausibly the IAB, and ITU could claim "ownership" (due to > owning E.164 and the DNS root), there doesn't seem to be a natural > point of initial contact. Who would be the authoritative contact in > the US, just to pick a relatively simple example? > > Henning > > On Dec 20, 2006, at 7:34 AM, Brian Rosen wrote: > > > Henning > > > > I don't see this as a policy issue. I see it as a design issue. > > What is > > the design of the Forest Guides for the world's emergency call routing > > database going to be? > > > > When they worked out the design of ENUM, they planned for the ITU > > to do the > > delegation. They asked ITU if it was willing to do the delegation, > > and the > > positive answer was known well before the documents were > > published. They > > created a design, and they were pretty sure it would be > > implemented, however > > slowly and ungainly. > > > > We need a plan, not a hand wave, and not a "could be this, could be > > that". > > We need to state what our expectations are, and we need to do some > > checks to > > make sure that at least a few key regions are willing to do it that > > way. We > > don't have to write rules for governments, but we have to describe > > something > > that will work, something we can write code to. > > > > Brian > > > >> -----Original Message----- > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> Sent: Tuesday, December 19, 2006 10:24 PM > >> To: Brian Rosen > >> Cc: 'Otmar Lendl'; ecrit@ietf.org > >> Subject: Re: [Ecrit] Forest guides > >> > >> Brian, > >> > >> I share your concern, but I believe that solving the policy problem > >> is beyond the scope of ECRIT. Just like ENUM didn't try to deal with > >> the ITU to set up (or not) e164.arpa, I don't think we can do working > >> group documents that describe this. There is one commonality between > >> this discussion and the ENUM effort: Since countries and even regions > >> within a country are going to move at very different speeds on all-IP > >> emergency calling, it seems unlikely that we'll have the same sense > >> of urgency globally at the same time, so I think it's important to > >> have an architecture that can evolve over time. > >> > >> To answer your direct question: I think we have several possible > >> plans that can work, where "work" means that all accessible FGs can > >> be accessed. (Which doesn't mean that things will work in every > >> country, simply because there may be no authoritative servers at > >> all.) ISPs and VSPs will operate resolvers that point to FGs, either > >> operated by them or some government authority. > >> > >> Henning > >> > >> On Dec 19, 2006, at 7:31 AM, Brian Rosen wrote: > >> > >>> I think there is a problem with this approach. This is ecrit, so > >>> the tree > >>> that matters is the sos tree. It needs to work, always, no matter > >>> where you > >>> roam. How do we do that? > >>> > >>> We can't leave that part without a real plan that will work. You > >>> have > >>> repeatedly derided the ENUM approach, but, cumbersome though it > >>> is, it > >>> works. What will work which will allow any caller to determine the > >>> route to > >>> the PSAP that serves where he is, no matter where he is? > >>> > >>> That is not a business model. > >>> > >>> Brian > >>> > >>>> -----Original Message----- > >>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>> Sent: Monday, December 18, 2006 10:39 PM > >>>> To: Otmar Lendl > >>>> Cc: ecrit@ietf.org > >>>> Subject: Re: [Ecrit] Forest guides > >>>> > >>>> I'll change the subject line to reflect the more substantive issue > >>>> you are raising. > >>>> > >>>> I'm trying to walk a fine line in providing an architectural > >>>> description that illustrates what's possible, without trying to > >>>> nail > >>>> down various practical "governance" approaches. In practice, I > >>>> think > >>>> a few options are possible: > >>>> > >>>> - A real root, run by somebody. This is plausible for commercial > >>>> directories for non-emergency services, possibly for a more limited > >>>> geographic region. Effectively, a single FG or a single tree, > >>>> depending on how you look at it. > >>>> > >>>> - A "cooperative club": A group of organizations that propagate > >>>> each > >>>> other's announcements, but have some mechanism for admitting new > >>>> members. > >>>> > >>>> - A "semi-cooperative club": Everybody propagates most records, > >>>> maybe > >>>> with exceptions. > >>>> > >>>> - Full peering: Each FG peers with all (say) countries it wants to > >>>> work with. Thus, the "official" US FG would not talk to Iran and > >>>> Cuba, say, except maybe through Switzerland. > >>>> > >>>> In each case, records may be signed or, in a more tightly > >>>> controlled > >>>> environment, not. > >>>> > >>>> There are probably more variations. I'm not sure I want to detail > >>>> them all, since I'm reluctant to rule out "business models". > >>>> Clearly, > >>>> the text needs to be consistent, so I'll work on that. > >>>> > >>>> > >>>> > >>>> Henning > >>>> > >>>> > >>>> On Dec 18, 2006, at 11:06 AM, Otmar Lendl wrote: > >>>> > >>>>> > >>>>> Regarding Forrest Guides: > >>>>> > >>>>> We're running into a contradiction here, e.g.: > >>>>> > >>>>> | For scalability and reliability, there will need to be a > >>>>> | large number of forest guides, all providing the same > >>>>> information. A > >>>>> | seeker can contact any forest guide and will then be directed > >>>>> to the > >>>>> | right tree or, rarely, set of trees. > >>>>> > >>>>> vs. > >>>>> > >>>>> | Trees can also restrict > >>>>> | their cooperation to parts of the information. For > >>>>> example, if > >>>>> | country C does not recognize country T, C can propagate tree > >>>>> regions > >>>>> | for all but T. > >>>>> > >>>>> Either the FGs offer all the same information or they don't. > >>>>> > >>>>> As I see the problem, we have basically two choices: > >>>>> > >>>>> One choice is to keep the forrest guides in sync with each other, > >>>>> with > >>>>> an automated protocol between them. This is the first statement > >>>>> from > >>>>> above plus these three sentences: > >>>>> > >>>>> | A tree node at the top of a tree can contact any forest > >>>>> | guide and inject new coverage region information into the > >>>>> system. > >>>>> | One would expect that each tree announces its coverage to more > >>>>> than > >>>>> | one forest guide. Each forest guide peers with one or more > >>>>> other > >>>>> | guides and distributes new coverage region announcements to > >>>>> all > >>>>> other > >>>>> | guides. > >>>>> > >>>>> In that case, this set of forrest guides act just as another > >>>>> layer in > >>>>> the hierarchical resolution model. Thus we don't actually have a > >>>>> forrest, > >>>>> but a single tree with the cluster of forrest guides as the root. > >>>>> > >>>>> This, of course, reopens the pandora's box of who controls what > >>>>> to put > >>>>> in there, which was the reason for the introduction of the > >>>>> forrest in > >>>>> the first place. > >>>>> > >>>>> Reading between the lines of the security section: Do you propose > >>>>> that > >>>>> the forrest guides just sync a set of digitally signed tree > >>>>> referrals > >>>>> amongst each other and then each FG decides based on local > >>>>> configuration > >>>>> which ones he considers when answering questions? And who is > >>>>> going to > >>>>> decide who can participate in this FG coverage exchange system? > >>>>> > >>>>> The other option is to leave the question of forrest guide > >>>>> synchronization > >>>>> completely out of scope and thus don't even try to solve a > >>>>> political problem > >>>>> with technical means. > >>>>> > >>>>> I have this nagging feeling what we want to have our cake and eat > >>>>> it, too. > >>>>> > >>>>> /ol > >>>>> -- > >>>>> < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > >>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>> > >>>> > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 20 08:45:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx1kq-0000Xi-QU; Wed, 20 Dec 2006 08:45:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx1kp-0000TJ-68 for ecrit@ietf.org; Wed, 20 Dec 2006 08:45:07 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx1kn-0002qA-Vy for ecrit@ietf.org; Wed, 20 Dec 2006 08:45:07 -0500 Received: from [192.168.0.41] (pool-141-153-196-78.mad.east.verizon.net [141.153.196.78]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kBKDijHE015709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Dec 2006 08:45:02 -0500 (EST) In-Reply-To: <099901c7243b$258c4a90$640fa8c0@cis.neustar.com> References: <099901c7243b$258c4a90$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1E4E568B-61DB-47F3-B750-B6D925479BDD@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Forest guides Date: Wed, 20 Dec 2006 08:44:43 -0500 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 'Otmar Lendl' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm happy to provide a plan: FGs operated by states (or their contractors), with mutual peering. On Dec 20, 2006, at 8:31 AM, Brian Rosen wrote: > In the U.S., you ask NENA, and you, for completeness, ask the FCC. > The FCC > may not answer in a time frame that matters. NENA would. > > But what are we asking? If we have a plan, and we're validating > that the > entities that have to implement some part of the plan are > agreeable, then > the above is a good answer. We don't (yet) have a plan. We have > "maybe > this, maybe that, maybe something else". > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 20 08:57:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx1wi-0005QN-DH; Wed, 20 Dec 2006 08:57:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx1wh-0005QG-E7 for ecrit@ietf.org; Wed, 20 Dec 2006 08:57:23 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx1wg-0004vF-7E for ecrit@ietf.org; Wed, 20 Dec 2006 08:57:23 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gx1wb-0002ci-J7; Wed, 20 Dec 2006 07:57:17 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Forest guides Date: Wed, 20 Dec 2006 08:57:17 -0500 Message-ID: <09aa01c7243e$c4860c00$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcckPQuggxGI7GGJTgOIbx5pmHhDXAAAYfFA In-Reply-To: <1E4E568B-61DB-47F3-B750-B6D925479BDD@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'Otmar Lendl' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm sure we can get that to work, but what is the international plan? How does an enterprise VoIP system in the U.S. find routing for a roamer in France? Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, December 20, 2006 8:45 AM > To: Brian Rosen > Cc: 'Otmar Lendl'; ecrit@ietf.org > Subject: Re: [Ecrit] Forest guides > > I'm happy to provide a plan: FGs operated by states (or their > contractors), with mutual peering. > > > > On Dec 20, 2006, at 8:31 AM, Brian Rosen wrote: > > > In the U.S., you ask NENA, and you, for completeness, ask the FCC. > > The FCC > > may not answer in a time frame that matters. NENA would. > > > > But what are we asking? If we have a plan, and we're validating > > that the > > entities that have to implement some part of the plan are > > agreeable, then > > the above is a good answer. We don't (yet) have a plan. We have > > "maybe > > this, maybe that, maybe something else". > > > > Brian > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 20 09:07:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx266-0001uP-Ik; Wed, 20 Dec 2006 09:07:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx265-0001uE-1f for ecrit@ietf.org; Wed, 20 Dec 2006 09:07:05 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx263-00066Y-Rc for ecrit@ietf.org; Wed, 20 Dec 2006 09:07:05 -0500 Received: from [192.168.0.41] (pool-141-153-196-78.mad.east.verizon.net [141.153.196.78]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kBKE6enY009339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Dec 2006 09:06:41 -0500 (EST) In-Reply-To: <09aa01c7243e$c4860c00$640fa8c0@cis.neustar.com> References: <09aa01c7243e$c4860c00$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C0CE30B-EF96-41F9-83B8-01567E186155@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Forest guides Date: Wed, 20 Dec 2006 09:06:35 -0500 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'Otmar Lendl' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The answer, I think, depends on whether we believe we'll see national peering (NENA-appointed entity peering with their counterpart in France) or some global coordination body. I suspect that the former is more likely, but I don't know whether there is much international contact between these bodies. From what I know, most countries don't even have the equivalent of NENA, which arose at least partially due to the extremely distributed operation of the US 911 system. Any suggestions? On Dec 20, 2006, at 8:57 AM, Brian Rosen wrote: > I'm sure we can get that to work, but what is the international > plan? How > does an enterprise VoIP system in the U.S. find routing for a > roamer in > France? > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 20 09:12:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2BB-0004tA-VC; Wed, 20 Dec 2006 09:12:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2BB-0004t5-AO for ecrit@ietf.org; Wed, 20 Dec 2006 09:12:21 -0500 Received: from smtp01out.dot.gov ([199.79.179.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx2BA-0006tW-0o for ecrit@ietf.org; Wed, 20 Dec 2006 09:12:21 -0500 Received: from dotfaawms005.ad.dot.gov ([152.119.86.161]) by smtp01out.dot.gov with ESMTP; 20 Dec 2006 09:12:17 -0500 X-IronPort-AV: i="4.12,192,1165208400"; d="scan'208"; a="59334440:sNHT70663054" Received: from OSTMAIL03VS3.ad.dot.gov ([152.119.86.69]) by DOTFAAWMS005.ad.dot.gov with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 09:12:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Forest guides Date: Wed, 20 Dec 2006 09:09:14 -0500 Message-ID: <0A0D0FBCB8154043B909C961D02A7A44020A981E@OSTMAIL03VS3.ad.dot.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Forest guides Thread-Index: AcckQCYn+/REhNgwRSy75FAWKP/6kgAAEevO References: <09aa01c7243e$c4860c00$640fa8c0@cis.neustar.com> <3C0CE30B-EF96-41F9-83B8-01567E186155@cs.columbia.edu> From: To: , X-OriginalArrivalTime: 20 Dec 2006 14:12:15.0901 (UTC) FILETIME=[DA1A44D0:01C72440] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: lendl@nic.at, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hello Gentlemen, =20 This issue surfaced at a National Press Club event I attended this = month. In fact, the same question came from a man from Paris who visits = here often. He wanted to know if the EU participated on the research in = the US as there was nothing that he knew of underway in France (let = alone other countries). =20 My question to you: Is there a member of the EU who participates on = IETF? In any case, perhaps we can extend specific invitations to the = Spring meeting? =20 Jenny ________________________________ From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Wed 12/20/2006 9:06 AM To: Brian Rosen Cc: 'Otmar Lendl'; ecrit@ietf.org Subject: Re: [Ecrit] Forest guides The answer, I think, depends on whether we believe we'll see national=20 peering (NENA-appointed entity peering with their counterpart in=20 France) or some global coordination body. I suspect that the former=20 is more likely, but I don't know whether there is much international=20 contact between these bodies. From what I know, most countries don't=20 even have the equivalent of NENA, which arose at least partially due=20 to the extremely distributed operation of the US 911 system. Any=20 suggestions? On Dec 20, 2006, at 8:57 AM, Brian Rosen wrote: > I'm sure we can get that to work, but what is the international=20 > plan? How > does an enterprise VoIP system in the U.S. find routing for a=20 > roamer in > France? > > 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 Wed Dec 20 09:45:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2hJ-0004AE-7l; Wed, 20 Dec 2006 09:45:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2hH-0004A7-Ls for ecrit@ietf.org; Wed, 20 Dec 2006 09:45:31 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx2hF-00063r-8z for ecrit@ietf.org; Wed, 20 Dec 2006 09:45:31 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Dec 2006 06:45:28 -0800 X-IronPort-AV: i="4.12,192,1165219200"; d="scan'208"; a="93294073:sNHT92269773" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBKEjQ6q000662; Wed, 20 Dec 2006 06:45:26 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBKEjQZi009882; Wed, 20 Dec 2006 06:45:26 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 06:45:26 -0800 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 06:45:24 -0800 From: "Marc Linsner" To: Subject: RE: [Ecrit] Forest guides Date: Wed, 20 Dec 2006 09:45:21 -0500 Message-ID: <006c01c72445$7b070730$250d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcckQCYn+/REhNgwRSy75FAWKP/6kgAAEevOAAD7n+A= In-Reply-To: <0A0D0FBCB8154043B909C961D02A7A44020A981E@OSTMAIL03VS3.ad.dot.gov> X-OriginalArrivalTime: 20 Dec 2006 14:45:25.0948 (UTC) FILETIME=[7C4357C0:01C72445] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2333; t=1166625926; x=1167489926; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Forest=20guides |Sender:=20; bh=DvFTU2p2z/lMgcU4yxS3duWcKnx23zCXVfpuBFiw+0U=; b=hlhEUQFWM199wykxlRAPAmFkgDBcfMDsHErwm02xmgDdC0I8v3587ZHLQM9XxhUYWb2dnWYn CCLwUs2Gc3LBCKsgIM0jmTWkKQshB8UrI7U5OHw9Bx0sISzmVpCH24li; Authentication-Results: sj-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: 'Alain Van Gaever' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Jenny, et al, Alain Van Gaever from the EU Commission presented at ESW06. Alain is very interested in including the EU in a global solution. I agree that time should be spent on this issue at the spring ESW. -Marc- > -----Original Message----- > From: Jenny.Hansen@dot.gov [mailto:Jenny.Hansen@dot.gov] > Sent: Wednesday, December 20, 2006 9:09 AM > To: hgs@cs.columbia.edu; br@brianrosen.net > Cc: lendl@nic.at; ecrit@ietf.org > Subject: RE: [Ecrit] Forest guides > > Hello Gentlemen, > > This issue surfaced at a National Press Club event I attended > this month. In fact, the same question came from a man from > Paris who visits here often. He wanted to know if the EU > participated on the research in the US as there was nothing > that he knew of underway in France (let alone other countries). > > My question to you: Is there a member of the EU who > participates on IETF? In any case, perhaps we can extend > specific invitations to the Spring meeting? > > Jenny > > ________________________________ > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wed 12/20/2006 9:06 AM > To: Brian Rosen > Cc: 'Otmar Lendl'; ecrit@ietf.org > Subject: Re: [Ecrit] Forest guides > > > > The answer, I think, depends on whether we believe we'll see > national peering (NENA-appointed entity peering with their > counterpart in > France) or some global coordination body. I suspect that the > former is more likely, but I don't know whether there is much > international contact between these bodies. From what I know, > most countries don't even have the equivalent of NENA, which > arose at least partially due to the extremely distributed > operation of the US 911 system. Any suggestions? > > On Dec 20, 2006, at 8:57 AM, Brian Rosen wrote: > > > I'm sure we can get that to work, but what is the > international plan? > > How does an enterprise VoIP system in the U.S. find routing for a > > roamer in France? > > > > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 20 10:57:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx3oS-000210-1t; Wed, 20 Dec 2006 10:57:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx3oQ-0001zj-C0 for ecrit@ietf.org; Wed, 20 Dec 2006 10:56:58 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx3oP-0001Na-4b for ecrit@ietf.org; Wed, 20 Dec 2006 10:56:58 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gx3o3-0006GG-L2; Wed, 20 Dec 2006 09:56:35 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Forest guides Date: Wed, 20 Dec 2006 10:56:35 -0500 Message-ID: <09d701c7244f$6fc73110$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcckQB3P3O+zJSauRP+gUSg0a0jglAADtCcA In-Reply-To: <3C0CE30B-EF96-41F9-83B8-01567E186155@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'Otmar Lendl' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I agree a global coordination body would be difficult. I'm sure we could get the ITU to do it, but I'm also sure we won't like the result, and I'm not in favor of that unless we have no other viable alternatives. What I was thinking was that there was a partial mesh with referral. There are clearly areas of the world that would flatly refuse to cooperate with one another, so a full mesh is never going to happen. However, a partial mesh would work. If you allow referral, then we can get the "Switzerland handles our diplomatic contacts with NeverNeverLand, because we don't have diplomatic relations with them). Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, December 20, 2006 9:07 AM > To: Brian Rosen > Cc: 'Otmar Lendl'; ecrit@ietf.org > Subject: Re: [Ecrit] Forest guides > > The answer, I think, depends on whether we believe we'll see national > peering (NENA-appointed entity peering with their counterpart in > France) or some global coordination body. I suspect that the former > is more likely, but I don't know whether there is much international > contact between these bodies. From what I know, most countries don't > even have the equivalent of NENA, which arose at least partially due > to the extremely distributed operation of the US 911 system. Any > suggestions? > > On Dec 20, 2006, at 8:57 AM, Brian Rosen wrote: > > > I'm sure we can get that to work, but what is the international > > plan? How > > does an enterprise VoIP system in the U.S. find routing for a > > roamer in > > France? > > > > Brian > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 20 11:02:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx3tB-0003gT-CI; Wed, 20 Dec 2006 11:01:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx3tA-0003gO-Ps for ecrit@ietf.org; Wed, 20 Dec 2006 11:01:52 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx3t9-0002Dy-EX for ecrit@ietf.org; Wed, 20 Dec 2006 11:01:52 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gx3t1-0000ZN-AI; Wed, 20 Dec 2006 10:01:43 -0600 From: "Brian Rosen" To: "'Marc Linsner'" , Subject: RE: [Ecrit] Forest guides Date: Wed, 20 Dec 2006 11:01:43 -0500 Message-ID: <09e001c72450$27305110$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcckQCYn+/REhNgwRSy75FAWKP/6kgAAEevOAAD7n+AAAsYvgA== In-Reply-To: <006c01c72445$7b070730$250d0d0a@amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: 'Alain Van Gaever' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Alain is the right guy, and he does follow this stuff fairly closely. I did give a presentation to the EU Expert Group on Emergency Calling last year so they are mostly at least aware of what is happening. We could probably ask him to seek advice from the expert group if anyone saw problems with a specific approach. I'll let him directly answer the question of whether we could get a more formal response to a specific "would you implement this" kind of question. A couple of people from EU countries also participate here. Steve Norreys is probably the one we all know. I'm pretty sure there are others who monitor the list. There are also several people from Asia who participate here, and I hope we could get some response from them. Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Wednesday, December 20, 2006 9:45 AM > To: Jenny.Hansen@dot.gov > Cc: 'Alain Van Gaever'; ecrit@ietf.org > Subject: RE: [Ecrit] Forest guides > > Jenny, et al, > > Alain Van Gaever from the EU Commission presented at ESW06. Alain is very > interested in including the EU in a global solution. > > I agree that time should be spent on this issue at the spring ESW. > > -Marc- > > > -----Original Message----- > > From: Jenny.Hansen@dot.gov [mailto:Jenny.Hansen@dot.gov] > > Sent: Wednesday, December 20, 2006 9:09 AM > > To: hgs@cs.columbia.edu; br@brianrosen.net > > Cc: lendl@nic.at; ecrit@ietf.org > > Subject: RE: [Ecrit] Forest guides > > > > Hello Gentlemen, > > > > This issue surfaced at a National Press Club event I attended > > this month. In fact, the same question came from a man from > > Paris who visits here often. He wanted to know if the EU > > participated on the research in the US as there was nothing > > that he knew of underway in France (let alone other countries). > > > > My question to you: Is there a member of the EU who > > participates on IETF? In any case, perhaps we can extend > > specific invitations to the Spring meeting? > > > > Jenny > > > > ________________________________ > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Wed 12/20/2006 9:06 AM > > To: Brian Rosen > > Cc: 'Otmar Lendl'; ecrit@ietf.org > > Subject: Re: [Ecrit] Forest guides > > > > > > > > The answer, I think, depends on whether we believe we'll see > > national peering (NENA-appointed entity peering with their > > counterpart in > > France) or some global coordination body. I suspect that the > > former is more likely, but I don't know whether there is much > > international contact between these bodies. From what I know, > > most countries don't even have the equivalent of NENA, which > > arose at least partially due to the extremely distributed > > operation of the US 911 system. Any suggestions? > > > > On Dec 20, 2006, at 8:57 AM, Brian Rosen wrote: > > > > > I'm sure we can get that to work, but what is the > > international plan? > > > How does an enterprise VoIP system in the U.S. find routing for a > > > roamer in France? > > > > > > 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 > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 20 20:01:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxCIl-00074k-Nr; Wed, 20 Dec 2006 20:00:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxCIk-00074H-PC for ecrit@ietf.org; Wed, 20 Dec 2006 20:00:50 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxCIi-0001sw-I3 for ecrit@ietf.org; Wed, 20 Dec 2006 20:00:50 -0500 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 20 Dec 2006 20:00:17 -0500 id 0158C30E.4589DCA1.00002AE5 In-Reply-To: <09d701c7244f$6fc73110$640fa8c0@cis.neustar.com> References: <09d701c7244f$6fc73110$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Forest guides Date: Wed, 20 Dec 2006 20:00:30 -0500 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "Ecrit@Ietf.Org" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Dec 20, 2006, at 10:56 AM, Brian Rosen wrote: > What I was thinking was that there was a partial mesh with > referral. There > are clearly areas of the world that would flatly refuse to > cooperate with > one another, so a full mesh is never going to happen. However, a > partial > mesh would work. If you allow referral, then we can get the > "Switzerland > handles our diplomatic contacts with NeverNeverLand, because we > don't have > diplomatic relations with them). Brian, considering your accusation against Henning for handing waving, I think you've just done exactly the same thing. I don't know what it is you think the IETF is gonna do about this, but running around the world and asking governments to appoint LoST coordinators is likely something the IETF will never do. As Henning pointed out, ENUM was designed to be E.164 layered on DNS, both of which had authorities appointed already. And a lot of good it did, huh? Today, there are far more ENUM activities in private trees than in the IETF-blessed, public ENUM. If anything, it illustrates the point. The IETF is good at technical solutions, not political solutions. Creating LoST and the outputs of ECRIT is the IETF's role in this. Selling it to the world is the role of NENA (and its counterparts in other countries). -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Dec 20 20:45:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxCzU-0003Hq-MO; Wed, 20 Dec 2006 20:45:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxCzT-0003Fa-6S for ecrit@ietf.org; Wed, 20 Dec 2006 20:44:59 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxCzQ-0003KD-W9 for ecrit@ietf.org; Wed, 20 Dec 2006 20:44:59 -0500 Received: from [192.168.0.41] (pool-141-153-196-78.mad.east.verizon.net [141.153.196.78]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kBL1igkq015079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Dec 2006 20:44:43 -0500 (EST) In-Reply-To: References: <09d701c7244f$6fc73110$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Forest guides Date: Wed, 20 Dec 2006 20:44:39 -0500 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "Ecrit@Ietf.Org" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > Today, there are far more ENUM activities in private trees than in > the IETF-blessed, public ENUM. If anything, it illustrates the > point. The IETF is good at technical solutions, not political > solutions. > I think there's a lesson in the ENUM evolution: The ENUM folks had to do a fair amount of work to make a variety of non-centralized solutions work ("enterprise ENUM"). Given the ENUM experience, if not just plain common sense, I think we need to anticipate that we won't get to where we want in one neat step, so making sure that we can support a range of deployment options seems a sensible thing to me, even if it is hand-waving. I'd rather wave hands than polish my crystal ball. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 21 04:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxKBO-0007Cc-Bx; Thu, 21 Dec 2006 04:25:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxKBN-0007C5-CA for ecrit@ietf.org; Thu, 21 Dec 2006 04:25:45 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GxKBL-00006Y-Qu for ecrit@ietf.org; Thu, 21 Dec 2006 04:25:45 -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] Forest guides Date: Thu, 21 Dec 2006 10:24:59 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C53B0@oefeg-s04.oefeg.loc> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Forest guides Thread-Index: AcckoY2s8QfPQ1cDSfWM75ZXV2ncRgAPo7oQ From: "Stastny Richard" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: "Ecrit@Ietf.Org" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Folks, >From my ENUM experience: I think we first need a stable technical solution (done in IETF). ENUM RFC3761 and the related RFCs are used by public User and Infrastructure ENUM and also by all private trees. It would be nice if this technical solution is also accepted by other standard bodies (3GPP, ETSI TISPAN - and eventually ITU-T NGN) I see them slowly moving in this direction. Lets talk first about emergency services only: Emergency services are nationally organized, so the trees will be also national. The FG should coordinate between the trees. Not all countries will move to IP PSAPs at the same time, but some large countries (e.g the US) will do and will create facts. Most of these countries have diplomatic relationships and there will be no problems to point to each other. Countries not doing this at the moment will follow later, because they have no choice. But this will only work if we have ONE stable global standard, and this is the task if the IETF (together with the other large standard bodies involved in VoIP. Regards Richard > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, December 21, 2006 2:45 AM > To: Andrew Newton > Cc: Ecrit@Ietf.Org > Subject: Re: [Ecrit] Forest guides >=20 > > Today, there are far more ENUM activities in private trees than in > > the IETF-blessed, public ENUM. If anything, it illustrates the > > point. The IETF is good at technical solutions, not political > > solutions. > > >=20 > I think there's a lesson in the ENUM evolution: The ENUM folks had to > do a fair amount of work to make a variety of non-centralized > solutions work ("enterprise ENUM"). Given the ENUM experience, if not > just plain common sense, I think we need to anticipate that we won't > get to where we want in one neat step, so making sure that we can > support a range of deployment options seems a sensible thing to me, > even if it is hand-waving. I'd rather wave hands than polish my > crystal ball. >=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 Thu Dec 21 09:03:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxOVi-0004hP-Oh; Thu, 21 Dec 2006 09:03:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxOVh-0004eA-S0 for ecrit@ietf.org; Thu, 21 Dec 2006 09:03:01 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxOVf-0005bO-IL for ecrit@ietf.org; Thu, 21 Dec 2006 09:03:01 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1GxOVU-0004xI-Po; Thu, 21 Dec 2006 08:02:49 -0600 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] Forest guides Date: Thu, 21 Dec 2006 09:02:50 -0500 Message-ID: <0c3001c72508$b50de020$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acckm3cYOeg8sQN6QuKG9TWOVAn4FAAbBAYw In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: "'Ecrit@Ietf.Org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Excuse me, but I thought I proposed a specific, workable answer. I think we probably CAN arrange a partial mesh. It will never be a full mesh. It will be voluntary. Since we can't get a partial mesh, we may need some referral operation where an entity in the mesh undertakes to return a tree he is not authoritative for, but merely acts as an agent. I do think we want to have some more specifics. I'm not sure if the specifics can be an IETF document, but that would be my preference. What I hope for is that there is a normative document that describes exactly how meshes and partial meshes work (in a protocol sense). Then I think we can draft a BCP that would guide creation of the mesh by countries. The latter document would be something we would solicit input from NENA, the EU Expert Group on Emergency Access, the appropriate Asian agencies, etc. If we got positive responses from them, we may have a solution. It's a BCP, not a treaty. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Wednesday, December 20, 2006 8:01 PM > To: Brian Rosen > Cc: Henning Schulzrinne; Ecrit@Ietf.Org > Subject: Re: [Ecrit] Forest guides > > > On Dec 20, 2006, at 10:56 AM, Brian Rosen wrote: > > > What I was thinking was that there was a partial mesh with > > referral. There > > are clearly areas of the world that would flatly refuse to > > cooperate with > > one another, so a full mesh is never going to happen. However, a > > partial > > mesh would work. If you allow referral, then we can get the > > "Switzerland > > handles our diplomatic contacts with NeverNeverLand, because we > > don't have > > diplomatic relations with them). > > Brian, considering your accusation against Henning for handing > waving, I think you've just done exactly the same thing. I don't > know what it is you think the IETF is gonna do about this, but > running around the world and asking governments to appoint LoST > coordinators is likely something the IETF will never do. As Henning > pointed out, ENUM was designed to be E.164 layered on DNS, both of > which had authorities appointed already. And a lot of good it did, > huh? Today, there are far more ENUM activities in private trees than > in the IETF-blessed, public ENUM. If anything, it illustrates the > point. The IETF is good at technical solutions, not political > solutions. > > Creating LoST and the outputs of ECRIT is the IETF's role in this. > Selling it to the world is the role of NENA (and its counterparts in > other countries). > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 21 09:39:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxP4c-00008R-Vq; Thu, 21 Dec 2006 09:39:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxP4b-00005a-2w for ecrit@ietf.org; Thu, 21 Dec 2006 09:39:05 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxP4Z-0004kl-Qn for ecrit@ietf.org; Thu, 21 Dec 2006 09:39:05 -0500 Received: from [192.168.0.41] (pool-141-153-196-78.mad.east.verizon.net [141.153.196.78]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kBLEcroe006137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Dec 2006 09:38:54 -0500 (EST) In-Reply-To: <0c3001c72508$b50de020$640fa8c0@cis.neustar.com> References: <0c3001c72508$b50de020$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1E90512C-5A7F-4BF3-960C-9CB3DDBC138F@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Forest guides Date: Thu, 21 Dec 2006 09:38:52 -0500 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "Ecrit@Ietf.Org" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Dec 21, 2006, at 9:02 AM, Brian Rosen wrote: > > Since we can't get a partial mesh, we may need some referral > operation where > an entity in the mesh undertakes to return a tree he is not > authoritative > for, but merely acts as an agent. > That's already possible with the existing spec. Any LoST server can always return a referral (another LoST URL) in a mapping response or a special redirection error response. Hopefully, the details will be clearer in LoST -03. > I do think we want to have some more specifics. I'm not sure if the > specifics can be an IETF document, but that would be my > preference. What I > hope for is that there is a normative document that describes > exactly how > meshes and partial meshes work (in a protocol sense). Then I think > we can > draft a BCP that would guide creation of the mesh by countries. > The latter > document would be something we would solicit input from NENA, the > EU Expert > Group on Emergency Access, the appropriate Asian agencies, etc. If > we got > positive responses from them, we may have a solution. It's a BCP, > not a > treaty. The lost-sync document describes this, although it can probably use more detail in places. It allows any set of LoST servers to synchronize their data, be that FGs or authoritative servers. This can be either a full mesh or some partial peering mesh that floods mapping information by more than one step. Thus, I'd appreciate comments on the lost-sync document to make sure it has enough details to be usable. I'm trying to minimize the number of mechanisms across the architecture. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Dec 21 09:56:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPKt-00019m-Vn; Thu, 21 Dec 2006 09:55:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPKs-000185-RL for ecrit@ietf.org; Thu, 21 Dec 2006 09:55:54 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxPKq-0007Xs-UV for ecrit@ietf.org; Thu, 21 Dec 2006 09:55:54 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1GxPKl-0003j7-L0; Thu, 21 Dec 2006 08:55:47 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Forest guides Date: Thu, 21 Dec 2006 09:55:49 -0500 Message-ID: <0c3c01c72510$1c104040$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcclDcAJFve01WKvRaWz0kOOP3JF+gAAYRTw In-Reply-To: <1E90512C-5A7F-4BF3-960C-9CB3DDBC138F@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "'Ecrit@Ietf.Org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > Since we can't get a partial mesh, we may need some referral > > operation where > > an entity in the mesh undertakes to return a tree he is not > > authoritative > > for, but merely acts as an agent. > > > > That's already possible with the existing spec. Any LoST server can > always return a referral (another LoST URL) in a mapping response or > a special redirection error response. Hopefully, the details will be > clearer in LoST -03. That's pretty much what I was expecting, although it's hard to see how that works for trees in the documentation as it exists today. I'll wait for Lost-03 and if I still get confused, maybe I'll suggest specifics. > > > > I do think we want to have some more specifics. I'm not sure if the > > specifics can be an IETF document, but that would be my > > preference. What I > > hope for is that there is a normative document that describes > > exactly how > > meshes and partial meshes work (in a protocol sense). Then I think > > we can > > draft a BCP that would guide creation of the mesh by countries. > > The latter > > document would be something we would solicit input from NENA, the > > EU Expert > > Group on Emergency Access, the appropriate Asian agencies, etc. If > > we got > > positive responses from them, we may have a solution. It's a BCP, > > not a > > treaty. > > The lost-sync document describes this, although it can probably use > more detail in places. It allows any set of LoST servers to > synchronize their data, be that FGs or authoritative servers. This > can be either a full mesh or some partial peering mesh that floods > mapping information by more than one step. Thus, I'd appreciate > comments on the lost-sync document to make sure it has enough details > to be usable. I had not realized that this was the intended mechanism. Again probably not thinking of this as applying to the forest. I'll review the documents again. > > I'm trying to minimize the number of mechanisms across the architecture. Yeah, you've said that, and I understand it, but maybe we haven't gotten the documents there yet. Now that would be the protocol part. A BCP on how you use it may still be usefull. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Dec 22 14:21:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxpxn-0007bF-UB; Fri, 22 Dec 2006 14:21:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxpxl-0007am-OC for ecrit@ietf.org; Fri, 22 Dec 2006 14:21:49 -0500 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxpxk-0006zD-AC for ecrit@ietf.org; Fri, 22 Dec 2006 14:21:49 -0500 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id DE0FB2002C; Fri, 22 Dec 2006 14:21:47 -0500 (EST) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19423-06; Fri, 22 Dec 2006 14:21:47 -0500 (EST) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 4E57220024; Fri, 22 Dec 2006 14:21:47 -0500 (EST) To: "Brian Rosen" , "Henning Schulzrinne" , "James Polk" , "Andrew Newton" , "ECRIT list" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Fri, 22 Dec 2006 14:21:43 -0500 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 12/22/2006 02:21:45 PM, Serialize complete at 12/22/2006 02:21:45 PM Content-Type: text/plain; charset="US-ASCII" X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: Subject: [Ecrit] review comments: draft-ietf-ecrit-framework-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: , Errors-To: ecrit-bounces@ietf.org Hi, OK, I've finally found some time to compile comments on draft-ietf-ecrit-framework-00 ... read it through just ages ago now. I've only made it to compiling comments through end of section 4 so far (my main area of expertise anyway). May have more later. Overall, I find this doc very useful, in fact required to understand all the other bits and pieces. Glad to see it become an official WG item! Cheers, Peter Blatherwick =============================================================== General ------- o Biggest comment is I think the Overview needs some work, for clarity and readability. Real important to get this very clear, since it sets up all the other pieces. Most of the appropriate material seems to be there, but it is confusing in current form. See some specific suggestions below. o Generally, the document seems focused on "public" scenarios (lumping residential in here), and does not mention enterprise needs much at all. Phrases like "access network" (which shows up very often) tend to emphasize this. Framework should be applicable to both. It needs to be pointed out that enterprise networks also must work into this overall framework, and may (or may not) reuse the same mechanisms in exactly the same ways, but with some pieces inside the enterprise infrastructure or otherwise differently arranged (notably LIS and other location resources, IMHO..). Also, it should be pointed out that many networks perceived by the end user as "public" are actually managed enterprise-like networks -- notable examples would be airport and municipal run WiFi, university campuses, etc. Not sure how to fix this, or if others also share this view for that matter. Maybe some scoping statements, or just a bit more discussion on applicability somewhere up front would clarify? (I will put my thinking cap on for this one.) o Sec 5, Location, is primarily an informative discussion, with some pros and cons, at present. Is it intended to add explicit requirements into this section as they get settled (MUSTs, SHOULDs ...)? Would be very helpful. Specific (issues, comments, etc) -------------------------------- o sec 1 Terminology, I think it would be very helpful to spell out definitions here, even where they come from other docs (notably the Req'ts and core SIP). Yes, i know, creates dependancies. But it would make this doc stand alone, and it will be the first thing on the topic many people read. o sec 1 Terminology, Location Determination. Should add more likely examples here, including ones not device-driven (GPS is low likelihood, other than cellular). Would add words to effect of " ..., or location may be determined by administration using a wiremap database or similar." o sec 3 Overview. Needs a brief description of Fig 1, outlining each of the main elements. (See more below.) o sec 3 Overview, para 2, bullet 2. Should be stated more clearly that other methods are equally applicable (remove bias). Please add words to effect of "... we use DHCP as an example location acquisition protocol (LLDP or [L7] methods are equally applicable). o sec 3 Overview, description of fig 2. Here, I start to get confused... I find the description pretty hard to follow, kinda crammed and jumbled. Also, there are multiple errors in which message is which in the description, and Fig 2 and Fig 1 seem to be reversed (eg. UA contacting the LoST server is M3 (not M7) in Fig 1, or is it M5-6 in Fig 2 ??) There are others lower down as well. Suggest a re-organization of the material would be a big help. Suggest: - adding descr of the functional elements shown in Fig 1, immediately below fig 1 (comment above); - then Fig 2; - then description of Fig 2 main steps, with each step description led with the messages it applies to, eg "[M5]-[M6] Alice's UA performs an initial Lost query ..." - line up message numbers between Fig 1 and Fig 2, if possible (or maybe lose the numbers altogether in Fig 1). o sec 3 Overview, description of fig 2. The roll of the LIS in this is quite unclear, making it hard to correlate Fig to Fig 2. Please describe how the LIS fits in. o sec 5.2. Add references for DHCP-Civic, DHCP-geo, [L7] (TBD), as well as LLDP-MED. o sec 5.2, final paragraph. Protocols developed outside of IETF are also used in the ECRIT framework, and also can support all IETF recommended formats. Notably LLDP-MED (now MUST in the Phone BCP) uses exact same data formats as the DHCP methods (and more). Current wording implies that only IETF protocols are used. Suggest this get re-worded to effect of "In IETF recommended Location Configuration Protocols [x-ref sec 5.5], both civic and geospatial formats are supported. ..." o sec 5.5, LLDP. LLDP-MED is no longer "proposed", was released last year. Also, should point out it carries exact same civic and geo content as DHCP methods. Suggest: "Link Layer Discovery Protocol [LLDP] with Media Endpoint Device extensions [LLDP-MED] can be used to deliver location information directly from the Layer 2 network infrastructure, and also supports both civic and geospatial formats identical in format to DHCP methods." Nits ---- o sec 2 Intro, 1st paragraph. Suggest wording fix " ... many of the technical [properties] of Internet multimedia require re-thinking..." Having to re-think is not an "advantage". o sec 2 Intro, 2nd paragraph, bullet 2. Broken sentence, suggest: " interleaving of emergency call traffic along with non-emergency traffic (e.g. normal call or other data) over the same infrastructure." o sec 2 Intro, 2nd paragraph, bullet 5. Would lose the second sentence -- it is out of place with other bullets. Or, add some example to the other bullets. o sec 2 Intro, paragraph 5 & 6. Some boundaries can be nation, state/province, county. Think it would be better to just keep it neutral. Suggest: "... systems are organized [regionally]; ..." "... Internet does not respect [regional] boundaries ..." "... emergency calls can be [in different regions (even continents)], with different [regulatory constraints,] conventions and processes ..." "... refused to create [regional] variants ..." o sec 2 Intro, paragraph 8, last sentence. It is really the phone BCP that mandates common codecs, so sentence is a bit confusing / misleading. Suggest something like "... this document describes that certain minimal capabilities, that call taker UAs and PSAP operated proxies should support, will be required for reliable operation. [Phone BCP] describes these requirements in detail. " o sec 5.2, Jurisdictional. Should point out that Civic/Jurisdictional is preferred. (Postal description says that that one is not preferred.) o sec 5.3.4. Needs a preamble. o sec 5.4, formatting of pros / cons would be easier as a table. =============================================================== _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit