RE: [Geopriv] Open discussion: Revised Civic LO draft

From geopriv-bounces@ietf.org Thu Sep 01 00:05:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAgKF-0004Rm-OY; Thu, 01 Sep 2005 00:05:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAgKB-0004RT-8n for geopriv@megatron.ietf.org; Thu, 01 Sep 2005 00:05:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08436 for ; Thu, 1 Sep 2005 00:05:11 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAgM1-000646-2w for geopriv@ietf.org; Thu, 01 Sep 2005 00:07:11 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8144v206138 for ; Wed, 31 Aug 2005 23:04:57 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Sep 2005 14:04:56 +1000 Message-ID: From: "Martin Thomson" To: GEOPRIV Subject: RE: [Geopriv] Open discussion: Revised Civic LO draft Date: Thu, 1 Sep 2005 14:04:52 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0534944547==" Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0534944547== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5AEAA.4DF8E43C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5AEAA.4DF8E43C Content-Type: text/plain Hi All, I haven't received any comments on the civic draft. Just in case this got lost in the noise last week, I'd like to remind you of the existence of this draft. Ta, Martin -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Thomson, Martin [WOLL:5500:EXCH] Sent: Monday, 22 August 2005 1:16 PM To: GEOPRIV Subject: [Geopriv] Open discussion: Revised Civic LO draft Hi Everyone, I have submitted a draft that updates the civic address format for PIDF-LO. This includes Henning's DHCP types as well as a few more. http://www.ietf.org/internet-drafts/draft-thomson-revised-civic-lo-00.txt If you have any comments, let fly. I'd be happy to discuss any of the decisions that have been made. Cheers, Martin ------_=_NextPart_001_01C5AEAA.4DF8E43C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Geopriv] Open discussion: Revised Civic LO draft

Hi All,

I haven't received any comments on the civic = draft. Just in case this got lost in the noise last week, I'd = like to remind you of the existence of this draft.

Ta,
Martin

-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org= ] On Behalf Of Thomson, Martin [WOLL:5500:EXCH]
Sent: Monday, 22 August 2005 1:16 PM
To: GEOPRIV
Subject: [Geopriv] Open discussion: Revised Civic LO = draft

Hi Everyone,

I have submitted a draft that updates the civic = address format for PIDF-LO. This includes Henning's DHCP types as = well as a few more.

http://www.ietf.org/internet-drafts/draft-thomson-revi= sed-civic-lo-00.txt

If you have any comments, let fly. I'd be happy = to discuss any of the decisions that have been made.

Cheers,
Martin

------_=_NextPart_001_01C5AEAA.4DF8E43C-- --===============0534944547== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0534944547==-- From geopriv-bounces@ietf.org Thu Sep 01 08:05:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAnpJ-0004LK-1W; Thu, 01 Sep 2005 08:05:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAnpG-0004KL-Aw for geopriv@megatron.ietf.org; Thu, 01 Sep 2005 08:05:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29645 for ; Thu, 1 Sep 2005 08:05:47 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAnrC-0003s3-6S for geopriv@ietf.org; Thu, 01 Sep 2005 08:07:51 -0400 Received: from [10.0.1.5] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 01 Sep 2005 08:05:45 -0400 id 000C7E5E.4316EE99.00007DA2 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] Open discussion: Revised Civic LO draft Date: Thu, 1 Sep 2005 08:05:46 -0400 To: Martin Thomson X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org Martin, I haven't had my morning coffee, so I'm likely not to get this right. But in Section 2.3, you mention dropping 'script' in favor of Unicode (which XML does natively). Isn't it still helpful to have the script information? Even if UTF-8 or UTF-16 can do everything, what harm is done by continuing to include that information? -andy On Sep 1, 2005, at 12:04 AM, Martin Thomson wrote: > Hi All, > > I haven't received any comments on the civic draft. Just in case > this got lost in the noise last week, I'd like to remind you of the > existence of this draft. > > Ta, > Martin > > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On > Behalf Of Thomson, Martin [WOLL:5500:EXCH] > Sent: Monday, 22 August 2005 1:16 PM > To: GEOPRIV > Subject: [Geopriv] Open discussion: Revised Civic LO draft > > > Hi Everyone, > > I have submitted a draft that updates the civic address format for > PIDF-LO. This includes Henning's DHCP types as well as a few more. > > http://www.ietf.org/internet-drafts/draft-thomson-revised-civic- > lo-00.txt > > If you have any comments, let fly. I'd be happy to discuss any of > the decisions that have been made. > > Cheers, > Martin > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 01 15:39:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAuuA-0007qu-Mh; Thu, 01 Sep 2005 15:39:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAuu8-0007qo-T2 for geopriv@megatron.ietf.org; Thu, 01 Sep 2005 15:39:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26067 for ; Thu, 1 Sep 2005 15:39:19 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAuw6-0002KN-O7 for geopriv@ietf.org; Thu, 01 Sep 2005 15:41:25 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 01 Sep 2005 15:39:14 -0400 id 000C7E5E.431758E2.000060BC Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <20050831170300.C673516FAB@mail.nitros9.org> References: <20050831170300.C673516FAB@mail.nitros9.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47CC96D3-7D1C-49F9-9597-94DD45A794ED@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] Re: Review of draft-ietf-geopriv-radius-lo-04.txt Date: Thu, 1 Sep 2005 15:39:14 -0400 To: GEOPRIV WG , radiusext@ops.ietf.org X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org All, I've asked Hannes to open an issue tracker for this document. If you have a particular issue with this document, please summarize it and send it to the list so that he may enter it into the issue tracker. When sending the issues, please send them in separate messages using subjects that denote the nature of the issue. -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 01 17:28:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAwbV-0002oh-A4; Thu, 01 Sep 2005 17:28:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAwbT-0002mL-6v for geopriv@megatron.ietf.org; Thu, 01 Sep 2005 17:28:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00295 for ; Thu, 1 Sep 2005 17:28:09 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAwdU-0005U7-Kt for geopriv@ietf.org; Thu, 01 Sep 2005 17:30:17 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 01 Sep 2005 17:28:06 -0400 id 000C7E71.43177266.000073F5 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_zak.ecotroph.net-29685-1125610087-0001-2" To: GEOPRIV WG Message-Id: <6FCE1004-299B-40F6-9459-B96C4604445C@hxr.us> From: Andrew Newton Date: Thu, 1 Sep 2005 17:28:08 -0400 X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Geopriv] IETF 63 GEOPRIV Session Minutes X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-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. --=_zak.ecotroph.net-29685-1125610087-0001-2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Here are the minutes for the IETF 63 GEOPRIV Session. If you have any additions or modifications, please let me know. -andy --=_zak.ecotroph.net-29685-1125610087-0001-2 Content-Type: text/plain; x-unix-mode=0644; x-mac-hide-extension=yes; name="GEOPRIV-IETF63-Minutes.txt"; charset=iso-8859-1 Content-Disposition: attachment; filename=GEOPRIV-IETF63-Minutes.txt Content-Transfer-Encoding: 7bit Minutes of the GEOPRIV Working Group at the 63nd IETF ----------------------------------------------------- Co-Chairs: Allison Mankin Randall Gellens Andrew Newton Minutes: Doug Otis 1) Agenda Andrew presented the agenda, and noted that two items had been added: a) GEOPRIV issues with SIP events, and b) draft-guenther-geopriv-saml-policy-01. No objection were given to the additions. 2) draft-winterbottom-location-uri-00 Martin Thomas presented draft-winterbottom-location-uri-00. Martin discussed the benefits of passing location information by reference vs. passing location information by value. Henning Schulzrinne objected to the points that pass-by-reference had superior privacy strengths, and Jon Peterson pointed out that pass-by-reference has better access control features whereby pass-by-value is limited to the use of cryptography. Hannes Tschofenig disagreed with this point and noted that in both cases access control needs to be configured. Henning Schulzrinne and Jon Peterson also discussed the differences between cost and environmental challenges between pass-by-value and pass-by-reference. Many participants noted that the draft seemed more like propaganda against pass-by-value and requested that it either should be toned down or provide better supporting arguments. The draft authors agreed. Ted Hardie noted that any pass-by-reference model needs to specify the access methods for reference, with URIs the set of schemes need to be specified. Jon Peterson then noted that this draft was only intended to describe a concept and not a concrete proposal. Brian Rosen noted that the description of pass-by-value being used by anybody does not correctly describe the pass-by-value deployment environments where trust is put into the channel and channel connections, especially when channel security is utilized. Jon Peterson noted that pass-by-reference does not necessarily need to rely upon cryptography, whereby pass-by-value does require cryptography. Brian Rosen noted that in the emergency case that passwords were not plausible for deployment. 3) draft-ietf-geopriv-pdif-lo-profile-01 Hannes Tshofenig presented draft-ietf-geopriv-pdif-lo-profile. Henning Schulzrinne noted that he did not see any productive outcome for continuing discussion on providing guidelines on precision or accuracy. He noted that he knew of no reasons why it would be dropped when it was given. 4) draft-winterbottom-http-location-delivery-01 Martin Thomas presented draft-winterbottom-http-location-delivery-01.txt. This document is known as HELD. John Schnizlein noted that HTTP has the capability of traversing NATs, but that HELD cannot because of its callback feature. Henning Schulzrinne noted that objects reference by HELD will have an object lifetime issue, at that at some point that a location object reference by HELD would be deleted. Martin Thomas suggested that retention requirements could be added but that they would vary depending on situation. Henning Schulzrinne expressed concern over variable retention requirements. Steve Norris also expressed concern for variable retention requirements. Hannes Tschofenig also stated that there was a state maintenance issue on top of the retention issue. Hannes Tschofenig stated that he did not understand the pseudonym in HELD and stated that there might be identity issues with HELD pseudonyms and the other identifiers in PIDF-LO. Ted Hardie stated that he believed that GEOPRIV does not currently have the policy rules defined for using On-Behalf-Of in HELD and that it would require a lot of work. John Schnizlein agreed and noted that On-Behalf-Of using IP addresses from the access networks will cause mistakes. John Schnizlein raised concerns regarding using DNS and DHCP to find HELD servers, and specifically noted that the use of DNS in the discovery mechanism of HELD does not match the normal uses of DNS. He also noted that there are often disconnects between information given out by DHCP and the domains used in DNS configuration of mobile devices. John also identified the issue that determining a location based on IP addresses may not be feasible. Martin Thomas mentioned that SLP could be used instead. 5) Followup to issues from interim meeting Hannes Tschofenig led a facilitated discussion on the issues that came from the GEOPRIV/ECRIT interim meeting held in New York. John Schnizlein questioned the need to worry about wrong locaiton information in an emergency phone call. Steve Norris noted that it is quite common in certain jurisdictions to fake incidents that require police reaction just to give neighbors a bad reputation. Stuart Goldman noted that fake location information in an emergency call could be used by terrorists to dispatch first responders to the wrong location. Randy Gellens noted that it may be easier to trust location information from a SIP proxy than from a call originator, but sophisticated attackers can stand up a SIP proxy. Andrew Newton and John Schnizlein noted that emergency call takers usually ask callers for information in addition to what they get from the network. Rohan Mahy noted that once a cryptographic signature is placed over an identity, there is then an issue of coordinating identities with users and emergency call centers. Brian Rosen noted that PSAP operators want location information to be reliable and spoof protected, but that even if the location information is incorrect a PSAP will take a call. Correct location information may be usable for call routing in high load situations. He also noted that asserted location is more important than identity. Brian Rosen also noted that the access network and signaling network may be different, and therefore it is difficult to use the access network to control aspects of the signaling. And that the two networks have different identities. Hannes Tschofenig noted that the difference between the access network and the signaling network is an issue because many solutions do not take into account these differing network architectures. Ted Hardie noted that the question that needs to be asked is about the necessity of passing the location/identity binding from the access network through the signaling network and to the emergency call end point. Rohan Mahy asked how a PSAP distinguishes between a large number of legitimate calls and a denial-of-service attack. Henning Schulzrinne asked if it is helpful to provide better bindings between location and network characteristics. Such as, would the source IP address of the call help when the location passed in the call is not known to be in that location. Steve Norris stated that multiple pieces of information given to the PSAPs will be beneficial, and so it could be useful to provide PSAPs with both the information from a network element and a information from a client. 6) GEOPRIV issues with SIP Events Rohan Mahy presented draft-mahy-geopriv-sip-loc-pkg-01.txt. Henning Schulzrinne stated that the normal PIDF-LO model uses presence subscriptions and this draft does not use presence. Rohan asked about applications that do not need presence information. Jon Peterson answered that presence requests can be filtered. Rohan noted that doing presence requests requires domain knowledge in presence even though the application is in the location domain. James Polk noted that this document solves a problem that is difficult to do in the SIP location conveyance document. Martin Thomas also agreed that the document was useful but noted that some of the GML bindings needed to be tightened up. Rohan noted that the use of GML with PIDF-LO is one of the reasons why he believed this document should be in GEOPRIV. Randy Gellens noted that the privacy requirements about location change events may be harder than anticipated because users tend to have changing needs. Rohan answered the concern by stating that such complexity could be handled by user interfaces. Andrew asked for a hum from the room regarding GEOPRIV accepting the work in the draft on the filter formatting. The room accepted the work. 7) draft-guenther-geopriv-saml-policy-01 Hannes Tschofenig gave a presentation on draft-guenther-geopriv-sampl-policy-01. Andrew asked how many participants had read the draft. Only two participants raised their hands. Andrew stated that the question of adopting this draft would have to be taken to the list since there were not enough reviewers of the draft in the room. --=_zak.ecotroph.net-29685-1125610087-0001-2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --=_zak.ecotroph.net-29685-1125610087-0001-2-- From geopriv-bounces@ietf.org Thu Sep 01 20:18:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAzGi-0005fE-M5; Thu, 01 Sep 2005 20:18:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAzGf-0005f9-He for geopriv@megatron.ietf.org; Thu, 01 Sep 2005 20:18:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08080 for ; Thu, 1 Sep 2005 20:18:49 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAzIh-0001uC-VW for geopriv@ietf.org; Thu, 01 Sep 2005 20:21:00 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j820ITB13052; Thu, 1 Sep 2005 19:18:30 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Sep 2005 10:17:10 +1000 Message-ID: From: "Martin Thomson" To: Andrew Newton , Martin Thomson Subject: RE: [Geopriv] Open discussion: Revised Civic LO draft Date: Fri, 2 Sep 2005 10:17:09 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0560573315==" Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0560573315== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5AF53.A8D2F0B0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5AF53.A8D2F0B0 Content-Type: text/plain Hi Andy, This is one that I had to do a little reading on to be sure that I was doing the right thing. Unicode and scripts are not something that I have dealt with before, so my interpretation may not be completely accurate. The way I understand it is that unicode (UTF-8, UTF-16, etc...) specifies a means of encoding characters. Every character also has an associated script (the characters that I am using are in the script called "latin" for instance). This is where the DHCP civic draft confused me, and perhaps Henning can clear this up, but I think that specifying script is redundant. That is, by specifying a particular codepoint in one of the unicode standards, you refer to a specific character, and that character has a script. The harm in including the information would be a comflict between what one scheme is telling you, and what the other says. That sort of conflict is dangerous - which one has precedent. If I specify character U+203B (japanese kome) and the cyrillic script, how does that help? The language attribute should disambiguate sufficiently (japanese kome vs. urdu paragraph separator). Cheers, Martin -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Thursday, 1 September 2005 10:06 PM To: Martin Thomson Cc: GEOPRIV Subject: Re: [Geopriv] Open discussion: Revised Civic LO draft Martin, I haven't had my morning coffee, so I'm likely not to get this right. But in Section 2.3, you mention dropping 'script' in favor of Unicode (which XML does natively). Isn't it still helpful to have the script information? Even if UTF-8 or UTF-16 can do everything, what harm is done by continuing to include that information? -andy On Sep 1, 2005, at 12:04 AM, Martin Thomson wrote: > Hi All, > > I haven't received any comments on the civic draft. Just in case > this got lost in the noise last week, I'd like to remind you of the > existence of this draft. > > Ta, > Martin > > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On > Behalf Of Thomson, Martin [WOLL:5500:EXCH] > Sent: Monday, 22 August 2005 1:16 PM > To: GEOPRIV > Subject: [Geopriv] Open discussion: Revised Civic LO draft > > > Hi Everyone, > > I have submitted a draft that updates the civic address format for > PIDF-LO. This includes Henning's DHCP types as well as a few more. > > http://www.ietf.org/internet-drafts/draft-thomson-revised-civic- > lo-00.txt > > If you have any comments, let fly. I'd be happy to discuss any of > the decisions that have been made. > > Cheers, > Martin > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > ------_=_NextPart_001_01C5AF53.A8D2F0B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Geopriv] Open discussion: Revised Civic LO draft

Hi Andy,

This is one that I had to do a little reading on to = be sure that I was doing the right thing. Unicode and scripts are = not something that I have dealt with before, so my interpretation may = not be completely accurate.

The way I understand it is that unicode (UTF-8, = UTF-16, etc...) specifies a means of encoding characters. Every = character also has an associated script (the characters that I am using = are in the script called "latin" for instance). This is = where the DHCP civic draft confused me, and perhaps Henning can clear = this up, but I think that specifying script is redundant. That = is, by specifying a particular codepoint in one of the unicode = standards, you refer to a specific character, and that character has a = script.

The harm in including the information would be a = comflict between what one scheme is telling you, and what the other = says. That sort of conflict is dangerous - which one has = precedent. If I specify character U+203B (japanese kome) and the = cyrillic script, how does that help? The language attribute = should disambiguate sufficiently (japanese kome vs. urdu paragraph = separator).

Cheers,
Martin

-----Original Message-----
From: Andrew Newton [mailto:andy@hxr.us]
Sent: Thursday, 1 September 2005 10:06 PM
To: Martin Thomson
Cc: GEOPRIV
Subject: Re: [Geopriv] Open discussion: Revised = Civic LO draft

Martin,

I haven't had my morning coffee, so I'm likely not to = get this
right. But in Section 2.3, you mention = dropping 'script' in favor of
Unicode (which XML does natively). Isn't it = still helpful to have
the script information? Even if UTF-8 or = UTF-16 can do everything,
what harm is done by continuing to include that = information?

-andy

On Sep 1, 2005, at 12:04 AM, Martin Thomson = wrote:

> Hi All,
>
> I haven't received any comments on the civic = draft. Just in case
> this got lost in the noise last week, I'd like = to remind you of the
> existence of this draft.
>
> Ta,
> Martin
>
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org= ] On
> Behalf Of Thomson, Martin = [WOLL:5500:EXCH]
> Sent: Monday, 22 August 2005 1:16 PM
> To: GEOPRIV
> Subject: [Geopriv] Open discussion: Revised = Civic LO draft
>
>
> Hi Everyone,
>
> I have submitted a draft that updates the civic = address format for
> PIDF-LO. This includes Henning's DHCP = types as well as a few more.
>
> http://www.ietf.org/internet-drafts/draft-thomson-revi= sed-civic-
> lo-00.txt
>
> If you have any comments, let fly. I'd be = happy to discuss any of
> the decisions that have been made.
>
> Cheers,
> Martin
>
> = _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>

------_=_NextPart_001_01C5AF53.A8D2F0B0-- --===============0560573315== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0560573315==-- From geopriv-bounces@ietf.org Thu Sep 01 20:51:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAzmV-00031k-Pg; Thu, 01 Sep 2005 20:51:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAzmU-00031c-MP for geopriv@megatron.ietf.org; Thu, 01 Sep 2005 20:51:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09945 for ; Thu, 1 Sep 2005 20:51:43 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAzoX-0002zv-5W for geopriv@ietf.org; Thu, 01 Sep 2005 20:53:54 -0400 Received: from [10.0.1.5] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 01 Sep 2005 20:51:34 -0400 id 000C7E72.4317A217.000016C8 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3BCA326D-3ADC-42AF-A4DA-73030507E038@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] Open discussion: Revised Civic LO draft Date: Thu, 1 Sep 2005 20:51:36 -0400 To: Martin Thomson X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org On Sep 1, 2005, at 8:17 PM, Martin Thomson wrote: > Hi Andy, > > This is one that I had to do a little reading on to be sure that I > was doing the right thing. Unicode and scripts are not something > that I have dealt with before, so my interpretation may not be > completely accurate. > > The way I understand it is that unicode (UTF-8, UTF-16, etc...) > specifies a means of encoding characters. Every character also has > an associated script (the characters that I am using are in the > script called "latin" for instance). This is where the DHCP civic > draft confused me, and perhaps Henning can clear this up, but I > think that specifying script is redundant. That is, by specifying > a particular codepoint in one of the unicode standards, you refer > to a specific character, and that character has a script. > > The harm in including the information would be a comflict between > what one scheme is telling you, and what the other says. That sort > of conflict is dangerous - which one has precedent. If I specify > character U+203B (japanese kome) and the cyrillic script, how does > that help? The language attribute should disambiguate sufficiently > (japanese kome vs. urdu paragraph separator). Perhaps my original question should have been, "So why does dhcp- civic have scipts?" Like XML, it is also using UTF-8. But that draft does have this explanation: The same civic and postal address information can often be rendered in multiple languages and scripts. For example, Korean addresses are often shown in Hangul, Latin and Kanji, while some older cities have multiple language variants (Munich, Muenchen and Monaco, for example). Since DHCPv4 and DHCPv6 do not currently support a mechanism to query for a specific script or language, the DHCP server SHOULD provide all common renderings to the client and MUST provide at least the rendering in the language and script appropriate to the location indicated. So it isn't necessarily about the UTF-8. It is about the protocol interaction between the sender and receiver. And I think that perhaps we have the same interaction with PIDF-LO, and therefore the 'scripts' out to be put back in (though in XML it is usually called 'lang' or 'language'). Do we envision a receiver of PIDF-LO asking for the Italian version of the same document after receiving the English version? I doubt it. -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 01 20:57:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAzrc-00068d-3J; Thu, 01 Sep 2005 20:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA5Mp-0002qj-W9 for geopriv@megatron.ietf.org; Tue, 30 Aug 2005 08:37:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09797 for ; Tue, 30 Aug 2005 08:37:30 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA5OM-0008Io-LM for geopriv@ietf.org; Tue, 30 Aug 2005 08:39:08 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7UCbRPE004038; Tue, 30 Aug 2005 15:37:29 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Aug 2005 15:37:28 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Aug 2005 15:37:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Aug 2005 15:37:11 +0300 Message-ID: Thread-Topic: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWq0aSH0yKv60MWTQS1Fihbq8fCXACiR64w To: , X-OriginalArrivalTime: 30 Aug 2005 12:37:12.0273 (UTC) FILETIME=[8B6EF410:01C5AD5F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 01 Sep 2005 20:57:01 -0400 Cc: geopriv@ietf.org Subject: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org Bernard Aboba wrote: > The "server-driven" approach also provides a mechanism to=20 > address RADEXT Issue 27 (Who's Location).=20 >=20 > One of the major problems with the RADIUS-GEOPRIV document is that=20 > it does not support user location determination, only NAS location.=20 Are you sure? The Location-Information attribute includes a field called "Entity", described as follows Entity (8 bits): Describes which location this attribute refers to: (0) describes the location of the user's client device (1) describes the location of the AAA client It looks like NAS could use this field to describe which location it's sending, or send two Location-Information attributes if it=20 knows both. Best regards, Pasi _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 01 20:57:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAzrc-00069A-EF; Thu, 01 Sep 2005 20:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA6SE-0001yY-8R for geopriv@megatron.ietf.org; Tue, 30 Aug 2005 09:47:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13028 for ; Tue, 30 Aug 2005 09:47:08 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA6Tl-0001fY-IQ for geopriv@ietf.org; Tue, 30 Aug 2005 09:48:47 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7UDl1WA002221; Tue, 30 Aug 2005 16:47:07 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Aug 2005 16:47:07 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Aug 2005 16:47:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Aug 2005 16:47:06 +0300 Message-ID: Thread-Topic: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWtZJNkIHh7ddaFT5aB36CeWz8F0wAAplxA To: X-OriginalArrivalTime: 30 Aug 2005 13:47:06.0515 (UTC) FILETIME=[4F657E30:01C5AD69] X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 01 Sep 2005 20:57:01 -0400 Cc: geopriv@ietf.org, radiusext@ops.ietf.org Subject: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org Bernard Aboba wrote: > > It looks like NAS could use this field to describe which location > > it's sending, or send two Location-Information attributes if it=20 > > knows both. >=20 > But the NAS isn't sending location by default. So how does=20 > the RADIUS server that requires a given kind of location indicate=20 > what it needs? Keep in mind that if the RADIUS server REQUIRES=20 > location then it may need to send an Access-Reject.=20 A simple solution would be that a NAS that knows both the NAS and=20 user location always sends both (when sending location information). (I don't think we need more fine-grained capability negotiation=20 for this.) Best regards, Pasi _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 01 20:57:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAzrc-00069Z-NM; Thu, 01 Sep 2005 20:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA6ai-0004OU-OW for geopriv@megatron.ietf.org; Tue, 30 Aug 2005 09:55:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13522 for ; Tue, 30 Aug 2005 09:55:54 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA6cG-0001wd-2e for geopriv@ietf.org; Tue, 30 Aug 2005 09:57:33 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7UDt9ih013148; Tue, 30 Aug 2005 16:55:14 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Aug 2005 16:55:52 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Aug 2005 16:55:51 +0300 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: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt Date: Tue, 30 Aug 2005 16:55:51 +0300 Message-ID: Thread-Topic: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWtaOY7LMGO4hcdSlSbJNxx23/IbgAAJLGA To: , X-OriginalArrivalTime: 30 Aug 2005 13:55:51.0295 (UTC) FILETIME=[883090F0:01C5AD6A] X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 01 Sep 2005 20:57:01 -0400 Cc: geopriv@ietf.org, radiusext@ops.ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org John Schnizlein wrote: >=20 > The inclusion of the "entity" field reintroduces the problem > we had with the initial draft, which is that no practical > mechanism has been identified through which the NAS would know > the location of the host attempting attachment. >=20 > Rather than prolong the illusion, it would be better to > eliminate this field and let the location attribute refer to > the location of the NAS. This depends on what kind of NASes you're considering. In PSTN dial-up, determining the host location probably isn't feasible, but there certainly are practical mechanisms for e.g. GSM/GPRS and IEEE 802.11 networks. Although they're not necessarily that=20 widely used, I would not call them an "illusion"... Best regards, Pasi _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 01 20:57:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAzrc-00069y-Vm; Thu, 01 Sep 2005 20:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA6pa-00087l-VM for geopriv@megatron.ietf.org; Tue, 30 Aug 2005 10:11:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14644 for ; Tue, 30 Aug 2005 10:11:16 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA6r8-0002JH-G2 for geopriv@ietf.org; Tue, 30 Aug 2005 10:12:55 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id KAA12339 for ; Tue, 30 Aug 2005 10:14:00 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma012239; Tue, 30 Aug 05 10:13:28 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 30 Aug 2005 10:10:41 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Tue, 30 Aug 2005 10:10:41 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Aug 2005 10:10:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt Date: Tue, 30 Aug 2005 10:10:40 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032553@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWtaOY7LMGO4hcdSlSbJNxx23/IbgAAJLGAAACHRcA= From: "Nelson, David" To: , X-OriginalArrivalTime: 30 Aug 2005 14:10:41.0171 (UTC) FILETIME=[9A98DE30:01C5AD6C] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:99.4056 P:95.9108 R:95.9108 S:48.5446 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 01 Sep 2005 20:57:01 -0400 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org Pasi Eronen writes... > This depends on what kind of NASes you're considering. In=20 > PSTN dial-up, determining the host location probably isn't=20 > feasible ... It's probably more accurate to say that in PSTN dial-up it isn't always possible to determine the host location accurately. Technologies such as ANI or Caller-ID provide that information. For the traditional land-line subscriber loop, it is very likely that the host is located within the premises served by the subscriber loop. This is almost always the case with residential customers. It will more often not be the case with commercial customers, who may have centralized outgoing trunk lines that can be accessed from a variety of locations. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 01 21:02:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAzx2-00077v-Fg; Thu, 01 Sep 2005 21:02:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAzx0-00077q-Ej for geopriv@megatron.ietf.org; Thu, 01 Sep 2005 21:02:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10317 for ; Thu, 1 Sep 2005 21:02:35 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAzz1-0003Hs-3t for geopriv@ietf.org; Thu, 01 Sep 2005 21:04:46 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8212Rnl029448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Sep 2005 21:02:27 -0400 (EDT) Message-ID: <4317A4A3.7010902@cs.columbia.edu> Date: Thu, 01 Sep 2005 21:02:27 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Geopriv] Open discussion: Revised Civic LO draft References: <3BCA326D-3ADC-42AF-A4DA-73030507E038@hxr.us> In-Reply-To: <3BCA326D-3ADC-42AF-A4DA-73030507E038@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: GEOPRIV , Martin Thomson X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org Andrew Newton wrote: > out to be put back in (though in XML it is usually called 'lang' or > 'language'). Do we envision a receiver of PIDF-LO asking for the > Italian version of the same document after receiving the English > version? I doubt it. This is fortunately the same thing: both use RFC 3066 language tags (see http://www.w3.org/TR/2004/REC-xml-20040204/#sec-lang-tag). [Pretty soon it will be 3066bis, judging from the discussion on the ietf mailing list...] Henning _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 01 21:08:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB02K-0001eX-Cu; Thu, 01 Sep 2005 21:08:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB02J-0001eQ-9F for geopriv@megatron.ietf.org; Thu, 01 Sep 2005 21:08:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10632 for ; Thu, 1 Sep 2005 21:08:03 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB04M-0003VQ-1Y for geopriv@ietf.org; Thu, 01 Sep 2005 21:10:15 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8217sAQ010570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Sep 2005 21:07:59 -0400 (EDT) Message-ID: <4317A5E9.6000909@cs.columbia.edu> Date: Thu, 01 Sep 2005 21:07:53 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Thomson Subject: Re: [Geopriv] Open discussion: Revised Civic LO draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: GEOPRIV , Andrew Newton X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org UTF-8 mostly specifies the script, but due to "Han unification", this isn't always true. In most cases, there would indeed be no need to include the script. Martin Thomson wrote: > The way I understand it is that unicode (UTF-8, UTF-16, etc...) > specifies a means of encoding characters. Every character also has an > associated script (the characters that I am using are in the script > called "latin" for instance). This is where the DHCP civic draft > confused me, and perhaps Henning can clear this up, but I think that > specifying script is redundant. That is, by specifying a particular > codepoint in one of the unicode standards, you refer to a specific > character, and that character has a script. > > The harm in including the information would be a comflict between what > one scheme is telling you, and what the other says. That sort of > conflict is dangerous - which one has precedent. If I specify character > U+203B (japanese kome) and the cyrillic script, how does that help? The > language attribute should disambiguate sufficiently (japanese kome vs. > urdu paragraph separator). _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 01 21:25:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB0Iv-0000sQ-12; Thu, 01 Sep 2005 21:25:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB0In-0000sI-V0 for geopriv@megatron.ietf.org; Thu, 01 Sep 2005 21:25:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11051 for ; Thu, 1 Sep 2005 21:25:06 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB0Kp-0003yX-L2 for geopriv@ietf.org; Thu, 01 Sep 2005 21:27:18 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j821OZr7018465; Thu, 1 Sep 2005 18:24:35 -0700 (PDT) Received: from [192.168.1.4] (vpn-10-50-0-95.qualcomm.com [10.50.0.95]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j821OVS3009709; Thu, 1 Sep 2005 18:24:32 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4317A5E9.6000909@cs.columbia.edu> References: <4317A5E9.6000909@cs.columbia.edu> Date: Thu, 1 Sep 2005 18:24:29 -0700 To: Henning Schulzrinne , Martin Thomson From: Ted Hardie Subject: Re: [Geopriv] Open discussion: Revised Civic LO draft Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: GEOPRIV , Andrew Newton X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org At 9:07 PM -0400 9/1/05, Henning Schulzrinne wrote: >UTF-8 mostly specifies the script, but due to "Han unification", this isn't always true. Also called the "CJK" unification, because the ideographs that are common to Chinese, Japanese, and Korean aren't repeated 3 times. This is to save space in the tables. The larger point, though, is what the real danger is in PIDF-LO document giving a code point and a surprising script association. I've been trying to think of cases where a code point being reported in a surprising script would actually influence the use made of the PIDF-LO in protocol processing. I haven't come up with any, largely because I don't see the "script, code point" pair getting used as a tuple. Am I missing some obvious case? The one concern I can see is attempting to use the script as a indicator of how to display something so that a surprising script is used to mask aspect of the PIDF-LO object in the rendering. If a user agent sees "Latin" and chooses a pretty but limited font as a result, then hits CJK characters, things might go missing that would be displayed. But this seems to be something to include in the Security Considerations rather than a strong risk. Is the risk greater here than it appears? regards, Ted Hardie _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 01 21:43:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB0aZ-00083O-0N; Thu, 01 Sep 2005 21:43:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB0aY-00083E-DE for geopriv@megatron.ietf.org; Thu, 01 Sep 2005 21:43:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11627 for ; Thu, 1 Sep 2005 21:43:26 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB0cc-0004QQ-EV for geopriv@ietf.org; Thu, 01 Sep 2005 21:45:38 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j821hEVZ026833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Sep 2005 21:43:14 -0400 (EDT) Message-ID: <4317AE2E.70206@cs.columbia.edu> Date: Thu, 01 Sep 2005 21:43:10 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Geopriv] Open discussion: Revised Civic LO draft References: <4317A5E9.6000909@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: GEOPRIV , Martin Thomson , Andrew Newton X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org Clearly, this mis-association can happen in XML with the lang (which is really a language-script) tag, and it doesn't seem to have raised any particular concerns that I have heard, although that's probably due to my fairly limited horizon in this area. Since both the DHCP draft and XML use (or will use) http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt in whole or in part, the same security considerations there would appear to apply. There is a somewhat-related paragraph: The language tag associated with a particular information item is of no consequence whatsoever in determining whether that content might contain possible homographs. The fact that a text is tagged as being in one language or using a particular script subtag provides no assurance whatsoever that it does not contain characters from scripts other than the one(s) associated with or specified by that language tag. Henning Ted Hardie wrote: > At 9:07 PM -0400 9/1/05, Henning Schulzrinne wrote: > >>UTF-8 mostly specifies the script, but due to "Han unification", this isn't always true. > > > Also called the "CJK" unification, because the ideographs that are common to > Chinese, Japanese, and Korean aren't repeated 3 times. This is to save space > in the tables. > > The larger point, though, is what the real danger is in PIDF-LO document > giving a code point and a surprising script association. I've been trying > to think of cases where a code point being reported in a surprising script > would actually influence the use made of the PIDF-LO in protocol processing. > I haven't come up with any, largely because I don't see the "script, code point" > pair getting used as a tuple. Am I missing some obvious case? > > The one concern I can see is attempting to use the script as a indicator of > how to display something so that a surprising script is used to mask aspect > of the PIDF-LO object in the rendering. If a user agent sees "Latin" and chooses > a pretty but limited font as a result, then hits CJK characters, things might go > missing that would be displayed. But this seems to be something to include > in the Security Considerations rather than a strong risk. Is the risk greater > here than it appears? > > regards, > Ted Hardie _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 03 09:49:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBYOC-0002T0-Ce; Sat, 03 Sep 2005 09:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBYOA-0002Rn-K8 for geopriv@megatron.ietf.org; Sat, 03 Sep 2005 09:48:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05961 for ; Sat, 3 Sep 2005 09:48:57 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBYQW-0001B4-9v for geopriv@ietf.org; Sat, 03 Sep 2005 09:51:25 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j83DmjI0012010 for ; Sat, 3 Sep 2005 15:48:45 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j83DmjKw006830 for ; Sat, 3 Sep 2005 15:48:45 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 3 Sep 2005 15:48:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Sep 2005 15:48:44 +0200 Message-ID: Thread-Topic: two additional place types Thread-Index: AcWwjh0gUcvE6T84Q5KfdrM3fwCcCQ== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 03 Sep 2005 13:48:45.0276 (UTC) FILETIME=[33EA39C0:01C5B08E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Subject: [Geopriv] two additional place types X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org hi all,=20 we (henning and myself) noticed that it might be useful to add two additiol place types, namely:=20 other: The entity is in a place but the place cannot be assigned to one of the registered place types. unknown: The type of place is unknown. should we add these two types?=20 ciao hannes _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 03 10:02:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBYbi-0004y3-PZ; Sat, 03 Sep 2005 10:02:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBYbh-0004xy-26 for geopriv@megatron.ietf.org; Sat, 03 Sep 2005 10:02:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06686 for ; Sat, 3 Sep 2005 10:02:55 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBYe2-0001du-U4 for geopriv@ietf.org; Sat, 03 Sep 2005 10:05:24 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j83E2kOE019172 for ; Sat, 3 Sep 2005 16:02:46 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j83E2kTp013995 for ; Sat, 3 Sep 2005 16:02:46 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 3 Sep 2005 16:02:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Sep 2005 16:02:45 +0200 Message-ID: Thread-Topic: Next steps for the 'Location Types Registry' draft Thread-Index: AcWwkCZ9wa1PnjLbTyyVqcTVW7BVGA== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 03 Sep 2005 14:02:46.0113 (UTC) FILETIME=[2917C510:01C5B090] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Subject: [Geopriv] Next steps for the 'Location Types Registry' draft X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org hi all,=20 as part of the wglc for the location types registry draft we received feedback regarding the usage of english for the different location types. i could not see a consensus with respect to this issue and i would like to see suggestions on how to move forward. =20 ciao hannes _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 03 10:23:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBYvH-0001du-QY; Sat, 03 Sep 2005 10:23:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBYvG-0001dp-9h for geopriv@megatron.ietf.org; Sat, 03 Sep 2005 10:23:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09091 for ; Sat, 3 Sep 2005 10:23:08 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBYxd-0002MC-JQ for geopriv@ietf.org; Sat, 03 Sep 2005 10:25:37 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j83EN5wT027914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Sep 2005 10:23:06 -0400 (EDT) Message-ID: <4319B1BD.1030005@cs.columbia.edu> Date: Sat, 03 Sep 2005 10:22:53 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: [Geopriv] Next steps for the 'Location Types Registry' draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org It is sometimes difficult to reach consensus on a mailing list, as peetering out of a discussion can either indicate that the proponent of a particular solution or approach has been convinced by the arguments of other solutions or that he or she has simply given up. There seem to be two somewhat separate issues: (1) Should the current initial registry use english words or some other token, such as a number. (2) Should the registry restrict future registrations to being (American) English words. I thought there was a recognition that - the token registered are not usually made directly visible to end users (*); - thus, they are protocol tokens that are, by consensus of the IETF reflected in relevant RFCs, not subject to I18N, no different from, say, the RPID XML element names or HTTP protocol header names. - numeric identifiers could be used, but would offer no significant advantages, but rather decrease readability and complicate debugging. After all, we don't use numeric header names or random letter strings in SMTP or HTTP, either. We have always assumed that implementors of IETF standards understand English - otherwise, they'd have difficulty programming in any known programming language except maybe APL or reading the RFC to begin with. This seems to argue for leaving (1) as is. For issue (2): I don't think registries of tokens and namespaces have typically specified the language to be used for future registrations. This would be handled as part of the normal review process specified for the registry. It seems likely that such a review would reject names designating the same location just in a different language and may consider whether the use of non-English names is likely to further interoperability. Given the lack of precedent and the low likelihood of having to deal with this issue in practice, it seems easiest just to punt here and not call out that facet of the registration review. Otherwise, we might have to get into whether the FCC-certified "dirty" words are allowable and who knows what other issues. (*) Even English language user interfaces may, for example, replace hyphens by space or translate single-word names into more descriptive phrases. Is this is a reasonable summary? Henning Tschofenig, Hannes wrote: > hi all, > > as part of the wglc for the location types registry draft we received > feedback regarding the usage of english for the different location > types. i could not see a consensus with respect to this issue and i > would like to see suggestions on how to move forward. > > ciao > hannes > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 03 11:44:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBaCH-0007i0-LE; Sat, 03 Sep 2005 11:44:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBaCF-0007hv-V1 for geopriv@megatron.ietf.org; Sat, 03 Sep 2005 11:44:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12240 for ; Sat, 3 Sep 2005 11:44:45 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBaEc-0004du-0u for geopriv@ietf.org; Sat, 03 Sep 2005 11:47:16 -0400 Received: from [10.0.1.5] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Sat, 03 Sep 2005 11:44:36 -0400 id 000C7E51.4319C4E4.000073E4 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] Next steps for the 'Location Types Registry' draft Date: Sat, 3 Sep 2005 11:44:30 -0400 To: "Tschofenig, Hannes" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org On Sep 3, 2005, at 10:02 AM, Tschofenig, Hannes wrote: > i could not see a consensus with respect to this issue and i > would like to see suggestions on how to move forward. Putting my co-chair hat on here: I did not see consensus around changing this draft to use numeric values nor to address the issue of the tokens being considered anything other than protocol elements (and thus not subject to additional I18N considerations). This draft will progress to the IESG using its current technical form. To accommodate the addition of the 'other' and 'unknown' place types to be placed in this draft now rather than being placed in the IANA registry separately, working group last call will be extended one additional week until 10 September 2005 in order for participants to voice any objections to these two new place types. -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 03 12:34:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBayP-0000S0-27; Sat, 03 Sep 2005 12:34:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBayO-0000Rv-CY for geopriv@megatron.ietf.org; Sat, 03 Sep 2005 12:34:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13917 for ; Sat, 3 Sep 2005 12:34:29 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBb0l-00061Q-IK for geopriv@ietf.org; Sat, 03 Sep 2005 12:37:01 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j83GY4iD002179; Sat, 3 Sep 2005 18:34:04 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j83GY4WC006934; Sat, 3 Sep 2005 18:34:04 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 3 Sep 2005 18:34:03 +0200 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: AW: [Geopriv] Next steps for the 'Location Types Registry' draft Date: Sat, 3 Sep 2005 18:34:03 +0200 Message-ID: Thread-Topic: [Geopriv] Next steps for the 'Location Types Registry' draft Thread-Index: AcWwkwty9WNi7S1FRy6MKHHfRjYHkQAEdVig From: "Tschofenig, Hannes" To: "Henning Schulzrinne" X-OriginalArrivalTime: 03 Sep 2005 16:34:03.0900 (UTC) FILETIME=[4BE023C0:01C5B0A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org hi henning,=20 thanks for your quick feedback. i fully agree with everything you wrote. nice summary.=20 ciao hannes > It is sometimes difficult to reach consensus on a mailing list, as=20 > peetering out of a discussion can either indicate that the=20 > proponent of=20 > a particular solution or approach has been convinced by the=20 > arguments of=20 > other solutions or that he or she has simply given up. >=20 > There seem to be two somewhat separate issues: >=20 > (1) Should the current initial registry use english words or=20 > some other=20 > token, such as a number. >=20 > (2) Should the registry restrict future registrations to being=20 > (American) English words. >=20 > I thought there was a recognition that >=20 > - the token registered are not usually made directly visible to end=20 > users (*); >=20 > - thus, they are protocol tokens that are, by consensus of the IETF=20 > reflected in relevant RFCs, not subject to I18N, no different=20 > from, say,=20 > the RPID XML element names or HTTP protocol header names. >=20 > - numeric identifiers could be used, but would offer no significant=20 > advantages, but rather decrease readability and complicate debugging.=20 > After all, we don't use numeric header names or random letter=20 > strings in=20 > SMTP or HTTP, either. We have always assumed that=20 > implementors of IETF=20 > standards understand English - otherwise, they'd have difficulty=20 > programming in any known programming language except maybe APL or=20 > reading the RFC to begin with. >=20 > This seems to argue for leaving (1) as is. >=20 > For issue (2): I don't think registries of tokens and namespaces have=20 > typically specified the language to be used for future registrations.=20 > This would be handled as part of the normal review process=20 > specified for=20 > the registry. It seems likely that such a review would reject names=20 > designating the same location just in a different language and may=20 > consider whether the use of non-English names is likely to further=20 > interoperability. Given the lack of precedent and the low=20 > likelihood of=20 > having to deal with this issue in practice, it seems easiest just to=20 > punt here and not call out that facet of the registration review.=20 > Otherwise, we might have to get into whether the=20 > FCC-certified "dirty"=20 > words are allowable and who knows what other issues. >=20 > (*) Even English language user interfaces may, for example, replace=20 > hyphens by space or translate single-word names into more descriptive=20 > phrases. >=20 > Is this is a reasonable summary? >=20 > Henning >=20 >=20 > Tschofenig, Hannes wrote: > > hi all,=20 > >=20 > > as part of the wglc for the location types registry draft=20 > we received > > feedback regarding the usage of english for the different location > > types. i could not see a consensus with respect to this issue and i > > would like to see suggestions on how to move forward. =20 > >=20 > > ciao > > hannes > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 03 13:32:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBbs4-0002CD-1f; Sat, 03 Sep 2005 13:32:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBbs2-0002C8-Ob for geopriv@megatron.ietf.org; Sat, 03 Sep 2005 13:32:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16432 for ; Sat, 3 Sep 2005 13:31:59 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBbuP-0007gi-Us for geopriv@ietf.org; Sat, 03 Sep 2005 13:34:31 -0400 Received: from zharhxm0.corp.nortel.com (zharhxm0.corp.nortel.com [47.165.48.148]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j83HVhJ27925; Sat, 3 Sep 2005 19:31:44 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zharhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 3 Sep 2005 18:31:43 +0100 Received: from [127.0.0.1] ([47.130.16.154] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 3 Sep 2005 13:31:41 -0400 Message-ID: <4319DDF9.5000008@nortel.com> Date: Sat, 03 Sep 2005 13:31:37 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: [Geopriv] Next steps for the 'Location Types Registry' draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Sep 2005 17:31:41.0757 (UTC) FILETIME=[58EB3ED0:01C5B0AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org I withdraw my intervention on the topic. I forgot that the content will be embedded in English-like XML headers, and it's all of a piece. Tschofenig, Hannes wrote: > hi all, > > as part of the wglc for the location types registry draft we received > feedback regarding the usage of english for the different location > types. i could not see a consensus with respect to this issue and i > would like to see suggestions on how to move forward. > > ciao > hannes > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 03 15:36:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBdoU-0005EL-Qz; Sat, 03 Sep 2005 15:36:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBdoT-0005E3-P4 for geopriv@megatron.ietf.org; Sat, 03 Sep 2005 15:36:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21450 for ; Sat, 3 Sep 2005 15:36:27 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBdqr-0002Ph-KX for geopriv@ietf.org; Sat, 03 Sep 2005 15:38:59 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j83JaCsF015446; Sat, 3 Sep 2005 21:36:12 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j83JaCBD001666; Sat, 3 Sep 2005 21:36:12 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 3 Sep 2005 21:36:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Sep 2005 21:36:11 +0200 Message-ID: Thread-Topic: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWqoGQwqccTAWBcR4+Uy5YMxb5lqwGC2F2Q From: "Tschofenig, Hannes" To: "Bernard Aboba" , , X-OriginalArrivalTime: 03 Sep 2005 19:36:12.0185 (UTC) FILETIME=[BDA41890:01C5B0BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Geopriv] AW: Review of draft-ietf-geopriv-radius-lo-04.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org hi bernard,=20 thanks for summarizing the potential options regarding this particular = issue.=20 please find my feedback inline:=20 > -----Urspr=FCngliche Nachricht----- > Von: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] Im Auftrag von Bernard Aboba > Gesendet: Samstag, 27. August 2005 02:43 > An: radiusext@ops.ietf.org; geopriv@ietf.org > Betreff: Re: Review of draft-ietf-geopriv-radius-lo-04.txt >=20 >=20 > In thinking about the problem of capabilities negotiation within the=20 > RADIUS-GEOPRIV document, it is not clear to me that it is=20 > necessary for a=20 > NAS to advertise location support.=20 the problem was the following. the nas might support=20 - civic location - geospatial location - both=20 (or nothing)=20 the radius server might also understand either civic, geospatial or = both.=20 when we tried to mandate civic location as the default that has to be = understood i was told that this is not possible in all environments. = geospatial is not possible as a default either.=20 now, the idea was include something in the first exchange from the nas = to the aaa server to allow the aaa server to determine whether he = actually understands the format that can be provided by the nas.=20 whether the desire to support this functionality justifies the = introduction of an avp is subject for discussion.=20 based on the feedback from the current mailing list thread at least you = do not seem to be in favor of it.=20 >=20 > Instead, the NAS can be set by default not to send location=20 > attributes=20 > unless the server asks for them. The problem then reduces to how the=20 > server communicates its needs to the NAS.=20 >=20 > There are several cases of interest:=20 >=20 > 1) The RADIUS server REQUIRES the NAS to provide location > in the Access-Request (e.g. it implements location-based=20 > access control). > In this case the RADIUS server can send an Access-Reject with an=20 > Error-Cause attribute with a value of "Location Required". from previous discussions i remember that this was not the best approach = particularly if many radius server want to obtain location information = from the nas.=20 =20 > Alternatively if the authentication mechanism (e.g. EAP) supports=20 > Access-Challenges, the RADIUS server can place a "Send=20 > location" attribute in the Challenge. this was the approach that was suggested to us in previous discussions.=20 sounds good to me.=20 > On receiving either of these=20 > indications, the NAS includes location attributes in the=20 > Access-Request.=20 > Note that the server's decision is not influenced by whether=20 > the client=20 > has advertised location support, only by the inclusion of location=20 > attributes in the Access-Request. i guess you would suggest to return an access reject if the the nas is = unable to understand the returned location information format.=20 >=20 > 2) The RADIUS server does not require location in the Access-Request, > but would like location attributes to be included in=20 > Accounting packets,=20 > if available. In this case, the RADIUS server sends an Access-Accept > including a "Send location" attribute, sounds good to me.=20 > perhaps specifying=20 > more details on > how location should be provided (e.g. Accounting-Stop only, interim > records, civil/geographic, etc.). this requirement hasn't be presented to me yet.=20 >=20 > Since the RADIUS server does not require location attributes,=20 > a legacy NAS=20 > can ignore the "send location" attribute with no ill effects.=20 > This is how=20 > legacy NAS implementations behave, and the "Issues and > Fixes" document indicates that this is in fact the correct behavior. > If the NAS does understand the "send location" attribute then it will > send location in the Accounting packets as requested. >=20 > Am I missing something, or is the problem really this simple?=20 i hope it is simple.=20 ciao hannes >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 03 15:36:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBdor-0005GL-1V; Sat, 03 Sep 2005 15:36:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBdoo-0005GG-W7 for geopriv@megatron.ietf.org; Sat, 03 Sep 2005 15:36:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21490 for ; Sat, 3 Sep 2005 15:36:49 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBdrE-0002Pz-Pp for geopriv@ietf.org; Sat, 03 Sep 2005 15:39:21 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j83JafAH015572; Sat, 3 Sep 2005 21:36:41 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j83Jafuf026326; Sat, 3 Sep 2005 21:36:41 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 3 Sep 2005 21:36:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Sep 2005 21:36:40 +0200 Message-ID: Thread-Topic: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWq0YRohhlW5aKLScOYqrgJc6yAswF4sVCg From: "Tschofenig, Hannes" To: "Bernard Aboba" , X-OriginalArrivalTime: 03 Sep 2005 19:36:41.0059 (UTC) FILETIME=[CED9EB30:01C5B0BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org Subject: [Geopriv] AW: Review of draft-ietf-geopriv-radius-lo-04.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org hi bernard,=20 i guess there is a misunderstand here with regard to the functionality of the radius-geopriv draft.=20 joel raised this issue and we discussed it.=20 we always supported the idea of providing location for the end host. we had a very, very long discussion about this topic when we merged the two radius-geopriv drafts. what has been changed as part of joel's issue was - the name of the avp (since it was misleading) and - the description to address joel's comments this issue has been resolved on the mailing list and i also had further off-list discussions with joel. i think you do not treat me fair with your statement that this issue has not been fixed 9 months later.=20 ciao hannes > > > > Am I missing something, or is the problem really this simple?=20 > > >=20 > > > It would appear so. >=20 > The "server-driven" approach also provides a mechanism to=20 > address RADEXT=20 > Issue 27 (Who's Location).=20 >=20 > One of the major problems with the RADIUS-GEOPRIV document is that it=20 > does not support user location determination, only NAS location.=20 >=20 > This is a problem for vendors who are shipping APs with built-in=20 > location support that enables APs to pinpint the location of=20 > associated=20 > stations. At least one RADIUS server implementation now supports=20 > "location-based access control". Why can't the RADIUS-GEOPRIV=20 > specification be used to send user as well as NAS location?=20 >=20 > This basic problem with the document was pointed out in=20 > November 2004, but=20 > has still not been fixed in August 2005, 9 months later. =20 >=20 > However, using the "server-driven" approach, the problem would =20 > not be hard to address. In the "send location" attribute=20 > included by the=20 > server, the server can specify what type of location data it=20 > is looking=20 > for - user or NAS. =20 >=20 > Note that layer 2 standards such as IEEE 802.11k already enable this=20 > distinction. In IEEE 802.11k a station can ask either for its own=20 > location or the location of the AP. =20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 03 15:38:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBdq1-0005J4-89; Sat, 03 Sep 2005 15:38:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBdpx-0005Iz-58 for geopriv@megatron.ietf.org; Sat, 03 Sep 2005 15:38:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21504 for ; Sat, 3 Sep 2005 15:37:59 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBdsL-0002Qx-W0 for geopriv@ietf.org; Sat, 03 Sep 2005 15:40:31 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j83Jbo2n015954; Sat, 3 Sep 2005 21:37:50 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j83JboMC002543; Sat, 3 Sep 2005 21:37:50 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 3 Sep 2005 21:37:49 +0200 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: AW: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt Date: Sat, 3 Sep 2005 21:37:49 +0200 Message-ID: Thread-Topic: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWtZJV34OSkDfnHQXS3f/BF2r56pADUB3QA From: "Tschofenig, Hannes" To: "Bernard Aboba" , X-OriginalArrivalTime: 03 Sep 2005 19:37:49.0938 (UTC) FILETIME=[F7E80520:01C5B0BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, radiusext@ops.ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org hi bernard,=20 please find a comment below:=20 > > Are you sure? The Location-Information attribute includes a field > > called "Entity", described as follows > >=20 > > Entity (8 bits): > > Describes which location this attribute refers to: > > (0) describes the location of the user's client device > > (1) describes the location of the AAA client > >=20 > > It looks like NAS could use this field to describe which location > > it's sending, or send two Location-Information attributes if it=20 > > knows both. >=20 > But the NAS isn't sending location by default. So how does=20 > the RADIUS=20 > server that requires a given kind of location indicate what=20 > it needs? Keep=20 > in mind that if the RADIUS server REQUIRES location then it=20 > may need to=20 > send an Access-Reject.=20 we tried to respect the fact that people indicated that there might be a scenario where the nas does not know the location of the end host. if this is the case then the nas can only send its own location information. if it can include the location information of the end host (in case it is known) then the more precise info is sent.=20 you seem to suggest that we add functionality to allow the radius server to request what information (end host vs. nas) it would like to see. we haven't yet heard this requirement and hence we haven't added it.=20 ciao hannes >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 03 15:38:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBdqt-0005OB-F8; Sat, 03 Sep 2005 15:38:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBdqs-0005O6-34 for geopriv@megatron.ietf.org; Sat, 03 Sep 2005 15:38:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21515 for ; Sat, 3 Sep 2005 15:38:56 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBdtG-0002TR-QB for geopriv@ietf.org; Sat, 03 Sep 2005 15:41:28 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j83Jckwc003886; Sat, 3 Sep 2005 21:38:46 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j83JckKE002792; Sat, 3 Sep 2005 21:38:46 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 3 Sep 2005 21:38:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Sep 2005 21:38:46 +0200 Message-ID: Thread-Topic: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWtZJNkIHh7ddaFT5aB36CeWz8F0wAAplxAANNmMbA= From: "Tschofenig, Hannes" To: , X-OriginalArrivalTime: 03 Sep 2005 19:38:46.0484 (UTC) FILETIME=[199C4140:01C5B0BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, radiusext@ops.ietf.org Subject: [Geopriv] AW: Review of draft-ietf-geopriv-radius-lo-04.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org hi pasi,=20 >=20 > Bernard Aboba wrote: >=20 > > > It looks like NAS could use this field to describe which location > > > it's sending, or send two Location-Information attributes if it=20 > > > knows both. > >=20 > > But the NAS isn't sending location by default. So how does=20 > > the RADIUS server that requires a given kind of location indicate=20 > > what it needs? Keep in mind that if the RADIUS server REQUIRES=20 > > location then it may need to send an Access-Reject.=20 >=20 > A simple solution would be that a NAS that knows both the NAS and=20 > user location always sends both (when sending location information). that's also possible and the document allows to include both information elements.=20 in a small network (such as a wlan hotspot) it might not really matter whether you provide the location of the end host or the nas since it might be almost the same (depending on the granularity of the location information). a lot depends on the deployment scenario.=20 >=20 > (I don't think we need more fine-grained capability negotiation=20 > for this.) i am not sure either.=20 ciao hannes >=20 > Best regards, > Pasi >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 03 15:41:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBdtm-0006K4-5V; Sat, 03 Sep 2005 15:41:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBdtk-0006Jz-KU for geopriv@megatron.ietf.org; Sat, 03 Sep 2005 15:41:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21681 for ; Sat, 3 Sep 2005 15:41:55 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBdwA-0002Z7-GM for geopriv@ietf.org; Sat, 03 Sep 2005 15:44:27 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j83JfkIw017793; Sat, 3 Sep 2005 21:41:47 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j83Jfk0u028645; Sat, 3 Sep 2005 21:41:46 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 3 Sep 2005 21:41:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Sep 2005 21:41:46 +0200 Message-ID: Thread-Topic: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWtd+xTBavK2/6QSFejJPbgoWdrQgDPP0yQ From: "Tschofenig, Hannes" To: "Bernard Aboba" , X-OriginalArrivalTime: 03 Sep 2005 19:41:46.0515 (UTC) FILETIME=[84EACE30:01C5B0BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, radiusext@ops.ietf.org Subject: [Geopriv] AW: Review of draft-ietf-geopriv-radius-lo-04.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org hi bernard,=20 > > A simple solution would be that a NAS that knows both the NAS and=20 > > user location always sends both (when sending location information). > >=20 > > (I don't think we need more fine-grained capability negotiation=20 > > for this.) >=20 > I agree that this would work and also agree that capability=20 > negotiation is=20 > not needed. However, I thought that the idea was not to send=20 > any location=20 > data by default.=20 location is not sent by default.=20 the aspect is similar to the civic vs. geospatial discussion. you could send both, if you have it. sometimes you just don't have civic and geospatial location information (depending on the deployment).=20 ciao hannes >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 03 15:42:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBdtx-0006Kk-J4; Sat, 03 Sep 2005 15:42:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBdtv-0006Kf-N7 for geopriv@megatron.ietf.org; Sat, 03 Sep 2005 15:42:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21687 for ; Sat, 3 Sep 2005 15:42:06 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBdwL-0002ZC-JJ for geopriv@ietf.org; Sat, 03 Sep 2005 15:44:38 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j83JfGou004850; Sat, 3 Sep 2005 21:41:16 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j83JfGr6028022; Sat, 3 Sep 2005 21:41:16 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 3 Sep 2005 21:41:15 +0200 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: AW: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt Date: Sat, 3 Sep 2005 21:41:15 +0200 Message-ID: Thread-Topic: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWtaMxWbRq6Ka7eRCSOl2uupGi3TwDTANAg From: "Tschofenig, Hannes" To: "John Schnizlein" , "Bernard Aboba" X-OriginalArrivalTime: 03 Sep 2005 19:41:15.0806 (UTC) FILETIME=[729CFBE0:01C5B0BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, Pasi.Eronen@nokia.com, radiusext@ops.ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org hi john,=20 > The inclusion of the "entity" field reintroduces the problem we had=20 > with the initial draft, which is that no practical mechanism has been=20 > identified through which the NAS would know the location of the host=20 > attempting attachment. i wonder why you believe that these mechanisms are not available today. a number of other people have already provided you with references to existing products.=20 let me add two links that explain how location determination works in a wlan environment:=20 http://www.tkn.tu-berlin.de/publications/papers/hoene_paper2.pdf=20 http://www.tkn.tu-berlin.de/publications/papers/tkn_04_16_paper3.pdf (there are certainly more papers about this subject available and i guess i do not again need to mention 3g networks.)=20 i have a question for you: you are the co-author of rfc 3825. now, consider the discussions we have in the emergency context (in geopriv & ecrit) and the idea to provide location information using dhcp to the end host for inclusion into an emergency call. do you think that there is a relationship between the location of the dhcp server/dhcp relay and the location of the end host? >=20 > Rather than prolong the illusion, it would be better to=20 > eliminate this=20 > field and let the location attribute refer to the location of the NAS. ciao hannes >=20 > John >=20 > On Aug 30, 2005, at 9:11 AM, Bernard Aboba wrote: >=20 > >> Are you sure? The Location-Information attribute includes a field > >> called "Entity", described as follows > >> > >> Entity (8 bits): > >> Describes which location this attribute refers to: > >> (0) describes the location of the user's client device > >> (1) describes the location of the AAA client > >> > >> It looks like NAS could use this field to describe which location > >> it's sending, or send two Location-Information attributes if it > >> knows both. > > > > But the NAS isn't sending location by default. So how does=20 > the RADIUS > > server that requires a given kind of location indicate what=20 > it needs?=20 > > Keep > > in mind that if the RADIUS server REQUIRES location then it=20 > may need to > > send an Access-Reject. > > >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 03 15:42:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBduk-0006MM-QG; Sat, 03 Sep 2005 15:42:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBduj-0006MH-A0 for geopriv@megatron.ietf.org; Sat, 03 Sep 2005 15:42:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21713 for ; Sat, 3 Sep 2005 15:42:55 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBdx8-0002a7-T7 for geopriv@ietf.org; Sat, 03 Sep 2005 15:45:27 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j83JglAq018089 for ; Sat, 3 Sep 2005 21:42:47 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j83Jglrl028962 for ; Sat, 3 Sep 2005 21:42:47 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 3 Sep 2005 21:42:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Sep 2005 21:42:46 +0200 Message-ID: Thread-Topic: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWo8A/km+mCKm1JQt64CuaB9FrsHgHyfydQAAFjnLA= From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 03 Sep 2005 19:42:47.0071 (UTC) FILETIME=[A902EAF0:01C5B0BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Content-Transfer-Encoding: quoted-printable Subject: [Geopriv] WG: Review of draft-ietf-geopriv-radius-lo-04.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org fyi, -----Urspr=FCngliche Nachricht----- Von: Tschofenig, Hannes=20 Gesendet: Samstag, 3. September 2005 21:42 An: 'Bernard Aboba'; radiusext@ops.ietf.org Betreff: AW: Review of draft-ietf-geopriv-radius-lo-04.txt hi bernard,=20 please find my comments below:=20 > Review of draft-ietf-geopriv-radius-lo-04.txt >=20 > The RADEXT WG Issues page discloses that 13 issues remain open against > this document: > http://www.drizzle.com/~aboba/RADEXT/ >=20 > Based on a preliminary review of the -04 version, it appears that some > of these open issues still have not been addressed. Some=20 > notes below:=20 >=20 > Section 2 >=20 > " Furthermore, the authors believe that there is a relationship > between the location of the network and the location of the entity > that triggered the network access authentication. Knowing the > location of a network (where the user or end host is attached to) > might in many networks also reveal the location of the user or end > host. In some networks it is even possible to provide a accurate > location of the user or end host. A similar assumption is=20 > also made > with regard to the location information obtained via DHCP (see for > example [4]). This information might be used by applications in > other protocols (such as SIP [12] with extensions [13]) to indicate > the location of a particular user even though the location "only" > refers to the location of the network or equipment within the > network. The assumption here is also that the location of the > network has some relationship to the location of the end host (and > subsequently to a user). This assumption might not hold in all > scenarios. Nevertheless, it seems to be reasonable." >=20 > RADEXT Issue 27 points out that this assumption is > not correct -- the location of the peer and the location of the > NAS are not the same thing. There are APs today that are capable > of providing the location of the user with a high degree of accuracy.=20 > Can those APs use this specification to provide the NAS and peer > location information independently?=20 i guess this is an issue that we could potentially discuss forever.=20 in fact we discussed this issue for a long time and this particular = paragraph was added based on joel's comments.=20 technology exists to determine the location of the end host. the draft = allows to add this location information for transmission to the radius = server. if the location of the end host cannot be determined then all = you can do is to provide information about the nas (since you don't have = anything else).=20 >=20 > Section 3.2 >=20 > RADEXT Issue 74 points out problems with the way this document uses > RFC 3576. =20 >=20 > The COA message may instruct the > access network to generate an Authorize-Only=20 > Access-Request (Access- > Request with Service-Type set to "Authorize-Only") in=20 > which case the > NAS MUST include the location infromation in this Access-Request. >=20 > This paragraph appears to retroactively update RFC 3576. =20 >=20 > Upon receiving the Authorize-Only message from the access network, > the AAA server MUST respond with either an Access-Accept message or > an Access-Reject message. >=20 > This also sounds like an update of RFC 3576. Why should RFC 3576=20 > behavior be different when location attributes are included?=20 >=20 > More fundamentally, why does RFC 3576 need to be used to=20 > obtain location=20 > information in mid-session when the same info is available in=20 > Accounting=20 > packets? Or is the issue that location data may not be included in=20 > Interim accounting information? I didn't notice a way that the RADIUS > server can configure the way the NAS sends location info=20 > (e.g. don't send=20 > in interims, send at a given interval different from the=20 > interim interval,=20 > etc.) i need to forward this issue to avi since he wrote this paragraph.=20 >=20 > Section 4 >=20 > How the network obtains the user's > location information is out of the scope of this document.=20 >=20 > See RADEXT Issue 27. Obtaining the peer location is one of the > fundamental usage scenarios for RADIUS-based location information. > If this is out of scope for this specification, a different=20 > specification will be needed to address that issue. Why not handle > both issues within the same document?=20 the technology for location determination of the end hosts location = information depends on factors that are outside the scope of this = document. manual configuration, triangulation, usage of location = protocols developed in other standardization organization, etc. are = examples.=20 it is not uncommon to treat some topic as out-of-scope if they touch a = different area.=20 >=20 > Section 8 >=20 > The capability attribute allows the RADIUS client to=20 > indicate whether > civic and/or geospatial location information can be provided to the > RADIUS server. This is useful to avoid sending location=20 > information > with every request if no further out-of-band arrangements are made > with regard to the transport of location information. The=20 > AAA server > uses the capability attribute to indicate that the AAA=20 > client has to > provide civic and/or geospatial location information as=20 > part of this > particular protocol exchange. If the AAA server does not send a > capability attribute then the AAA client MUST NOT return location > information. The user's authorization policies MUST be=20 > consulted by > the AAA server before requesting location information delivery from > the AAA client. If the AAA server encounters that the AAA client > does not support the desired location information it might respond > with an Access-Reject with the corresponding error cause attribute > (with the Location-Info-Required error code). >=20 > The above paragraph seems vague about the nature of the capability > negotiation. Terms like "might respond" imply a range of > acceptable behaviors, which could result in interoperability=20 > problems.=20 >=20 > Since Access-Requests are initiated by the NAS, there is no way > for the NAS to know beforehand whether a given RADIUS server requires > location information or not. However, a NAS might default to not > sending location information and then if the AAA server sends back > an Access-Reject with a Location-Info-Required error code, then it > could enable it. This seems to handle the case where the RADIUS > server requires location (e.g. won't grant access without it).=20 >=20 > Based on the rest of Section 8, it appears that there are other > scenarios in which the RADIUS server might like location information=20 > if available, but does not require it. In these cases, the=20 > RADIUS server could send back an Access-Accept with a request for > location information, specifying what kind of location it is > asking for (NAS or peer). If the NAS does not understand > the attribute it will ignore it. >=20 > Overall, it is not clear to me why the Capability attribute=20 > is needed, or=20 > if so, what the goal is. =20 i have read your other mails about this subject as well and i appreciate = to receive feedback about it. it is good to hear opinion from other people.=20 if people in general think that the capability exchange is not need and = other mechanisms provide similar characteristics (as discussed in other = mails) than i am happy to change it.=20 >=20 > Section 11 >=20 > Why is a capability attribute needed in an Access-Challenge? Why > is "Location-Info-Required" a new attribute rather than a value > of Error-Cause? Why are Basic-Policy-Rules, Extended-Policy-Rules, > Capability and Location-Info-Required attributes allowed in an=20 > Access-Reject? i incorporated this proposal based on the feedback i got. now, i get the = feedback i want and that's good.=20 unfortunately it turns out to be quite complicated to have two working = groups working on a single document. i wasn't even able to attend the = ietf#62 meeting where this particular issue was discussed (since it was = ironically conflicting with the geopriv meeting, if i remember it = correctly).=20 after reviewing all the mails regarding the review of = draft-ietf-geopriv-radius-lo-04.txt it appears that most issues are = refer to the capability exchange. i suspect that resolving the = capability exchange issue will resolve the main concerns.=20 ciao hannes =20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 03 15:43:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBdvX-0006R4-14; Sat, 03 Sep 2005 15:43:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBdvV-0006Qz-2q for geopriv@megatron.ietf.org; Sat, 03 Sep 2005 15:43:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21727 for ; Sat, 3 Sep 2005 15:43:43 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBdxu-0002ar-Ud for geopriv@ietf.org; Sat, 03 Sep 2005 15:46:15 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j83JhZl4018946 for ; Sat, 3 Sep 2005 21:43:35 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j83JhZVi029139 for ; Sat, 3 Sep 2005 21:43:35 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 3 Sep 2005 21:43:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Sep 2005 21:43:34 +0200 Message-ID: Thread-Topic: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWpg3Fk/j6xodwSQmq/5S0yMYbytAHIwH9QAAZSQ6A= From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 03 Sep 2005 19:43:35.0140 (UTC) FILETIME=[C5A9AA40:01C5B0BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Subject: [Geopriv] WG: Review of draft-ietf-geopriv-radius-lo-04.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org fyi, -----Urspr=FCngliche Nachricht----- Von: Tschofenig, Hannes=20 Gesendet: Samstag, 3. September 2005 21:35 An: 'Bernard Aboba'; Nelson, David Cc: radiusext@ops.ietf.org Betreff: AW: Review of draft-ietf-geopriv-radius-lo-04.txt hi bernard,=20 thanks for keeping track of the issues at your radext webpage. i had the = impression that we discussed all of these issues already on the radext = and the geopriv mailing list (around march this year).=20 based on the fact that two working groups were involved when working on = this document i wasn't quite aware of how the open issues should be = tackled (mailing list and/or issue tracker), which format is used to = submit or resolve individual issues and how is actually in charge to = add, remove or modify something on the issue tracker.=20 this might actually something to discuss next time whenever two working = groups work on a single document to avoid confusion.=20 ciao hannes > > Please post comments to the RADEXT WG in the format defined on the > > RADEXT WG Issue list: > >=20 > > http://www.drizzle.com/~aboba/RADEXT/ >=20 > It would also be helpful if the authors of the RADIUS=20 > Location document=20 > would post the resolution of the 13 issues that have already=20 > been filed,=20 > so we can figure out which ones are now closed. =20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 03 16:15:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBeQQ-0003Au-Lu; Sat, 03 Sep 2005 16:15:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBeQP-0003Ap-UC for geopriv@megatron.ietf.org; Sat, 03 Sep 2005 16:15:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22534 for ; Sat, 3 Sep 2005 16:15:39 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBeSp-0003Qt-St for geopriv@ietf.org; Sat, 03 Sep 2005 16:18:12 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j83KFVUa001008; Sat, 3 Sep 2005 22:15:31 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j83KFVT2026179; Sat, 3 Sep 2005 22:15:31 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 3 Sep 2005 22:15:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Sep 2005 22:15:30 +0200 Message-ID: Thread-Topic: Issue 86: Location Identifier in Location-Information Attribute Thread-Index: AcWwxDi+9QNkr2UBSi+l6g8ezJxG8A== From: "Tschofenig, Hannes" To: , X-OriginalArrivalTime: 03 Sep 2005 20:15:31.0475 (UTC) FILETIME=[3BE32E30:01C5B0C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Geopriv] Issue 86: Location Identifier in Location-Information Attribute X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org hi all,=20 months ago lionel morand asked whether a 'location ID' (i.e., a reference to location information) should be added to the radius-geopriv draft. this issue is described at:=20 http://www.drizzle.com/~aboba/RADEXT/#Issue%2086 we rejected the request since there was no need to include a reference since we provide the location itself. in his example the 'location id' value refers to a list of predefined values for some operators. we can easily provide the same functionality with a few more bits. reduction of a few bits was not seen as very important for this particular use case only. no other person cared for this particular issue and asked for providing this feature.=20 now, in a private mail i was pointed to the same issue again.=20 here is a link to a document that shows how the location id (or actually numbering plan) looks like=20 http://www.itu.int/ITU-T/inr/forms/files/mnc_0605e.pdf i still think that we don't need this. ciao hannes _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 03 20:48:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBigS-0008NV-Aa; Sat, 03 Sep 2005 20:48:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBigP-0008Mf-U1 for geopriv@megatron.ietf.org; Sat, 03 Sep 2005 20:48:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02608 for ; Sat, 3 Sep 2005 20:48:27 -0400 (EDT) From: jouni.korhonen@teliasonera.com Received: from ceiling.dave.sonera.fi ([131.177.130.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBiir-0001wg-0E for geopriv@ietf.org; Sat, 03 Sep 2005 20:51:02 -0400 Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id j840mJLa028352 for ; Sun, 4 Sep 2005 03:48:19 +0300 (EEST) Received: from FITMS201MB.tcad.telia.se (fitms201cb.tcad.telia.se [131.177.121.204]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id j840mI5a028348; Sun, 4 Sep 2005 03:48:18 +0300 (EEST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6617.27 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 4 Sep 2005 03:48:16 +0300 Message-ID: <07B14A720C46C344AC96AAA64F5D6A3101491934@FITMS201MB.tcad.telia.se> Thread-Topic: Issue 86: Location Identifier in Location-Information Attribute Thread-Index: AcWwxDi+9QNkr2UBSi+l6g8ezJxG8AAIAvBg To: , , X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Geopriv] RE: Issue 86: Location Identifier in Location-Information Attribute X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org Hi Hannes,=20 The proposed Location-Id 'feature' could actually be useful e.g. with UMA and 3GPP GAN services -- helping operators to differentiate service areas between WLAN hotspots and such. However, I still think one can exploit e.g. existing civic location TLVs such as LOC for the same purpose. =20 Cheers, Jouni > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Tschofenig, Hannes > Sent: 3. syyskuuta 2005 23:16 > To: geopriv@ietf.org; radiusext@ops.ietf.org > Subject: Issue 86: Location Identifier in=20 > Location-Information Attribute >=20 > hi all,=20 >=20 > months ago lionel morand asked whether a 'location ID' (i.e., a > reference to location information) should be added to the=20 > radius-geopriv > draft. this issue is described at:=20 > http://www.drizzle.com/~aboba/RADEXT/#Issue%2086 >=20 > we rejected the request since there was no need to include a reference > since we provide the location itself. in his example the 'location id' > value refers to a list of predefined values for some operators. we can > easily provide the same functionality with a few more bits.=20 > reduction of > a few bits was not seen as very important for this particular use case > only. no other person cared for this particular issue and asked for > providing this feature.=20 >=20 > now, in a private mail i was pointed to the same issue again.=20 >=20 > here is a link to a document that shows how the location id=20 > (or actually > numbering plan) looks like=20 > http://www.itu.int/ITU-T/inr/forms/files/mnc_0605e.pdf >=20 > i still think that we don't need this. >=20 > ciao > hannes >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 03 22:00:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBjoN-0001wn-FI; Sat, 03 Sep 2005 22:00:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBjoL-0001wi-KF for geopriv@megatron.ietf.org; Sat, 03 Sep 2005 22:00:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04133 for ; Sat, 3 Sep 2005 22:00:43 -0400 (EDT) Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBjqn-0003Qr-TZ for geopriv@ietf.org; Sat, 03 Sep 2005 22:03:19 -0400 Received: from [70.104.227.167] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12172920; Sat, 03 Sep 2005 22:00:18 -0400 Message-Id: <6.2.1.2.0.20050903215931.02db3138@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 03 Sep 2005 22:00:14 -0400 To: "Tschofenig, Hannes" , "Bernard Aboba" , From: "Joel M. Halpern" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: geopriv@ietf.org Subject: [Geopriv] Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: geopriv-bounces@ietf.org Errors-To: geopriv-bounces@ietf.org I certainly felt (and still feel) that this issue had been resolved in a fair and clear fashion. Yours, Joel At 03:36 PM 9/3/2005, Tschofenig, Hannes wrote: >hi bernard, > >i guess there is a misunderstand here with regard to the functionality >of the radius-geopriv draft. >joel raised this issue and we discussed it. > >we always supported the idea of providing location for the end host. we >had a very, very long discussion about this topic when we merged the two >radius-geopriv drafts. > >what has been changed as part of joel's issue was >- the name of the avp (since it was misleading) and >- the description to address joel's comments > >this issue has been resolved on the mailing list and i also had further >off-list discussions with joel. > >i think you do not treat me fair with your statement that this issue has >not been fixed 9 months later. > >ciao >hannes > > > > > > Am I missing something, or is the problem really this simple? > > > > > > > > It would appear so. > > > > The "server-driven" approach also provides a mechanism to > > address RADEXT > > Issue 27 (Who's Location). > > > > One of the major problems with the RADIUS-GEOPRIV document is that it > > does not support user location determination, only NAS location. > > > > This is a problem for vendors who are shipping APs with built-in > > location support that enables APs to pinpint the location of > > associated > > stations. At least one RADIUS server implementation now supports > > "location-based access control". Why can't the RADIUS-GEOPRIV > > specification be used to send user as well as NAS location? > > > > This basic problem with the document was pointed out in > > November 2004, but > > has still not been fixed in August 2005, 9 months later. > > > > However, using the "server-driven" approach, the problem would > > not be hard to address. In the "send location" attribute > > included by the > > server, the server can specify what type of location data it > > is looking > > for - user or NAS. > > > > Note that layer 2 standards such as IEEE 802.11k already enable this > > distinction. In IEEE 802.11k a station can ask either for its own > > location or the location of the AP. > > > > -- > > to unsubscribe send a message to radiusext-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > >-- >to unsubscribe send a message to radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Sep 04 01:14:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBmpV-0007oW-AP; Sun, 04 Sep 2005 01:14:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBmpT-0007o0-2g for geopriv@megatron.ietf.org; Sun, 04 Sep 2005 01:14:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08936 for ; Sun, 4 Sep 2005 01:14:06 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBmrw-0007hb-VQ for geopriv@ietf.org; Sun, 04 Sep 2005 01:16:42 -0400 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1EBmpK-000LDo-2B; Sun, 04 Sep 2005 01:13:58 -0400 Received: by internaut.com (Postfix, from userid 1000) id 28CDB21663; Sat, 3 Sep 2005 22:13:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 1BFAF2165E; Sat, 3 Sep 2005 22:13:57 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Sat, 3 Sep 2005 22:13:57 -0700 (PDT) From: Bernard Aboba