From bernard_aboba@hotmail.com Sun Jan 2 08:51:13 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE8A28B797 for ; Sun, 2 Jan 2011 08:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+-RqOs1YR3S for ; Sun, 2 Jan 2011 08:51:11 -0800 (PST) Received: from blu0-omc1-s31.blu0.hotmail.com (blu0-omc1-s31.blu0.hotmail.com [65.55.116.42]) by core3.amsl.com (Postfix) with ESMTP id 7ACB73A6924 for ; Sun, 2 Jan 2011 08:51:11 -0800 (PST) Received: from BLU152-DS19 ([65.55.116.9]) by blu0-omc1-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 2 Jan 2011 08:53:18 -0800 X-Originating-IP: [98.203.198.61] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: Date: Sun, 2 Jan 2011 08:53:19 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0349_01CBAA5A.81061870" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuqnY7fi+SPPNsoSpuB4rW4oqs3nw== Content-Language: en-us X-OriginalArrivalTime: 02 Jan 2011 16:53:18.0479 (UTC) FILETIME=[8E5629F0:01CBAA9D] Cc: 'Ralph Droms' Subject: Re: [Geopriv] Options for Resolution of DISCUSS comments on RFC 3825bis X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 16:51:14 -0000 ------=_NextPart_000_0349_01CBAA5A.81061870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Martin -- If a new DHCP Option Code were to be allocated for RFC 3825bis, would we still keep the material in the document relating to version 0? Note that even if version 0 is removed from the document, it might still make sense to keep the format as it is (including the version field). This is because the option may be processed in "upper layers" who may not see the option code (or in the case of IEEE 802.11, there may not be an option code). So it would be useful to have the "version" embedded in the option, so that the "upper layer" would know how to process it. However it's not clear to me that there would ever be a reason for a server to send a version 0 with a new option code (or for a client to support receiving it). If a new option code were to be allocated, then I'd assume that version 1 would be made mandatory to implement with the new option code (both on client and server). Would there ever be a situation where you'd send both the old option (version 0) as well as the new option (also with version 0)? It seems to me that if both options were sent, the new option would need to be version 1. If there isn't a situation where a client would ever want to receive version 0 with the new option code, and the server wouldn't want to send it, then this begs the question of how much material on version 0 is useful in the document. Martin Thompson said: > Martin - sorry, but I'm not clear on your response. What is the "it" > you refer to as "Isn't it only a problem..."? "it" being the backwards compatibility problem. Do we have to assume that deprecating 3825 leads to IEEE (for example) using the new RFC? Or do they keep their existing interpretation of the fields until they update their specifications. > Isn't the interpretation of the resolution/uncertainty field different > between versions 0 and 1? Yes, it's different. However, there is some doubt over whether a v0 resolution field can be reliably created. > I have a concern that v0 clients won't be able to request the v0 > option or report that it is unable to use the v1 [??] option. Your concern is a valid one. I'm not debating that. I'm simply suggesting that maybe it doesn't matter due to there being very few v0 clients. > It seems that reusing the option code at least introduces some > unnecessary complexity. I recommend using a new option code to avoid > that overhead. A new code is OK with me. It might be a little over cautious, but then it probably won't hurt either. ====================================== As noted in the tracker, several IESG members have raised the question of whether it makes sense to revise the original RFC 3825 DHCP option or just to create a new DHCP option with a new code point. Here are the potential choices for moving forward: a. Continue to use a single option code for both versions 0 and 1. In this approach the document would be left more or less as it is, but additional material would be added to the discussion of backward compatibility in Section 2.2.1 to explain why the WG took this approach. b. Allocate a new option code for the version 1 format, leave material on the original option in the document. In this approach, the document would continue to revise RFC 3825, but would also define new DHCPv4 and DHCPv6 options. While this approach would be consistent with the GEOPRIV WG charter (which describes the goal of the work item as "to obsolete 3825"), it is not clear whether there would be enough clarifications/revisions to RFC 3825 material to justify keeping that material in it. c. Allocate new DHCPv4 and DHCPv6 option codes for the new format, but remove material relating to the original RFC 3825 format. This approach would define new option codes, but would remove discussion of option code 123. Such a document would probably be quite a bit shorter, since material relating to backward compatibility could be removed. One question relating to this approach would be whether the new document would obsolete RFC 3825 or not. Since the GEOPRIV WG charter lists the work item as "Submit an draft for DHCP geodetic location to the IESG for publication as PS to obsolete 3825" if the new document did not obsolete RFC 3825 then a charter change would seem to be required. ------=_NextPart_000_0349_01CBAA5A.81061870 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Martin = --

 

If a new DHCP Option Code were to be allocated for RFC = 3825bis, would we still keep the material in the document relating to = version 0?

 

Note that even if version 0 is removed from the = document, it might still make sense to keep the format as it is = (including the version field).

 

This is = because the option may be processed in "upper layers" who may = not see the option code (or in the case of IEEE 802.11, there may not be = an option code).   

 

So it would = be useful to have the "version" embedded in the option, so = that the "upper layer" would know how to process it. =

 

However it's not clear to me that there would ever be = a reason for a server to send a version 0 with a new option code (or for = a client to support receiving it).

 

If a new = option code were to be allocated, then I'd assume that version 1 would = be made mandatory to implement with the new option code (both on client = and server).

 

Would there ever be a situation where you'd send both = the old option (version 0) as well as the new option (also with version = 0)?   It seems to me that if both options were sent, the new = option would need to be version 1.

 

If there = isn't a situation where a client would ever want to receive version 0 = with the new option code, and the server wouldn't want to send it, then = this begs the question of how much material on version 0 is useful in = the document.

 

 

Martin = Thompson said:

 

> = Martin - sorry, but I'm not clear on your response. What is the = "it"

> you refer to = as "Isn't it only a problem..."?

 

"it" being the backwards compatibility = problem.  Do we have to assume that deprecating 3825 leads to IEEE = (for example) using the new RFC?  Or do they keep their existing = interpretation of the fields until they update their = specifications.

> Isn't the interpretation of the = resolution/uncertainty field different

> between versions 0 and 1?

 

Yes, = it's different.  However, there is some doubt over whether a v0 = resolution field can be reliably created.

 

> I = have a concern that v0 clients won't be able to request the v0 =

> option or report that it is = unable to use the v1 [??] option.

 

Your = concern is a valid one.  I'm not debating that.  I'm simply = suggesting that maybe it doesn't matter due to there being very few v0 = clients.

> It seems that reusing the option code at least = introduces some

> unnecessary = complexity.  I recommend using a new option code to avoid =

> that = overhead.

 

A new code is OK with me.  It might be a = little over cautious, but then it probably won't hurt = either.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= p class=3DMsoNormal>As noted in the tracker, several IESG members have = raised the question of whether it makes sense to revise the original RFC = 3825 DHCP option or just to create a new DHCP option with a new code = point. 

Here are the potential choices for moving = forward:

a. Continue to use a single option code for both = versions 0 and 1.  In this approach the document would be left more = or less as it is, but additional material would be added to the = discussion of backward compatibility in Section 2.2.1 to explain why the = WG took this approach.

b. Allocate a new option code for the = version 1 format, leave material on the original option in the = document.  In this approach, the document would continue to revise = RFC 3825, but would also define new DHCPv4 and DHCPv6 options.  = While this approach would be consistent with the GEOPRIV WG charter = (which describes the goal of the work item as "to obsolete = 3825"), it is not clear whether there would be enough = clarifications/revisions to RFC 3825 material to justify keeping that = material in it. 

c. Allocate new DHCPv4 and DHCPv6 option = codes for the new format, but remove material relating to the original = RFC 3825 format.  This approach would define new option codes, but = would remove discussion of option code 123.  Such a document would = probably be quite a bit shorter, since material relating to backward = compatibility could be removed. 

One question relating to = this approach would be whether the new document would obsolete RFC 3825 = or not.  Since the GEOPRIV WG charter lists the work item as = "Submit an draft for DHCP geodetic location to the IESG for = publication as PS to obsolete 3825"  if the new document did = not obsolete RFC 3825 then a charter change would seem to be = required.

------=_NextPart_000_0349_01CBAA5A.81061870-- From jmpolk@cisco.com Mon Jan 3 09:22:27 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2961D3A68C9 for ; Mon, 3 Jan 2011 09:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.51 X-Spam-Level: X-Spam-Status: No, score=-110.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ql2TT-rYXpg0 for ; Mon, 3 Jan 2011 09:22:24 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B62F23A67C0 for ; Mon, 3 Jan 2011 09:22:24 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,267,1291593600"; d="scan'208";a="395685457" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 03 Jan 2011 17:24:32 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p03HOVxW029784; Mon, 3 Jan 2011 17:24:31 GMT Message-Id: <201101031724.p03HOVxW029784@sj-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 03 Jan 2011 11:24:30 -0600 To: Bernard Aboba , From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: 'Ralph Droms' Subject: Re: [Geopriv] Options for Resolution of DISCUSS comments on RFC 3825bis X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 17:22:27 -0000 Bernard in-line At 10:53 AM 1/2/2011, Bernard Aboba wrote: >Content-Type: multipart/alternative; > boundary="----=_NextPart_000_0349_01CBAA5A.81061870" >Content-Language: en-us > >Martin -- > >If a new DHCP Option Code were to be allocated for RFC 3825bis, >would we still keep the material in the document relating to version 0? > >Note that even if version 0 is removed from the document, it might >still make sense to keep the format as it is (including the version field). > >This is because the option may be processed in "upper layers" who >may not see the option code (or in the case of IEEE 802.11, there >may not be an option code). > >So it would be useful to have the "version" embedded in the option, >so that the "upper layer" would know how to process it. > >However it's not clear to me that there would ever be a reason for a >server to send a version 0 with a new option code (or for a client >to support receiving it). If I understand this correctly, we would have the following scenario: - version 0 servers would send Option 123 - version 1 servers would send Option 500 (or whatever new code is assigned) Under this scenario, Option 500 servers wouldn't *ever* send Option 123 (i.e., version 0), but would (normatively) point to RFC 3825 for those wanting to send Option 123 (i.e., version 0). > >If a new option code were to be allocated, then I'd assume that >version 1 would be made mandatory to implement with the new option >code (both on client and server). I would assume that too. > >Would there ever be a situation where you'd send both the old option >(version 0) as well as the new option (also with version 0)? If there ever was this desire, then both Options 123 and 500 would be included in either the DHCP request or reply message - as I believe I see a clear separation between v0 and v1 at this point. >It seems to me that if both options were sent, the new option would >need to be version 1. Specifically, I believe the two Options (123 and 500) would be enough of a separation. Pragmatically, for readers, I believe stating that Option 500 is version 1 would make more sense to make sure to remove another level of confusion that could occur. > >If there isn't a situation where a client would ever want to receive >version 0 with the new option code, and the server wouldn't want to >send it, then this begs the question of how much material on version >0 is useful in the document. Are you suggesting 3825bis as written is completely scrapped? This would take us back to the individual -00 stage, because nothing that's going to be written in that new ID will have been accepted by the WG. That seems like a lot of work and time that's not as necessary as it needs to be. If we go down this path, knowing if we make the change to remove the "implement version 0 this way" from the text - it's headed back to the WG regardless, we take the easier route and just modify out the existing version 0 text, and instead point normatively to RFC 3825 for those interested in version 0, and keep as much of the version 1 text as possible. This should result in a single new rev for WGLC confirmation and get this back to the IESG for their consideration. James > > >Martin Thompson said: > > > Martin - sorry, but I'm not clear on your response. What is the "it" > > you refer to as "Isn't it only a problem..."? > >"it" being the backwards compatibility problem. Do we have to >assume that deprecating 3825 leads to IEEE (for example) using the >new RFC? Or do they keep their existing interpretation of the >fields until they update their specifications. > > Isn't the interpretation of the resolution/uncertainty field different > > between versions 0 and 1? > >Yes, it's different. However, there is some doubt over whether a v0 >resolution field can be reliably created. > > > I have a concern that v0 clients won't be able to request the v0 > > option or report that it is unable to use the v1 [??] option. > >Your concern is a valid one. I'm not debating that. I'm simply >suggesting that maybe it doesn't matter due to there being very few v0 clients. > > It seems that reusing the option code at least introduces some > > unnecessary complexity. I recommend using a new option code to avoid > > that overhead. > >A new code is OK with me. It might be a little over cautious, but >then it probably won't hurt either. > >====================================== >As noted in the tracker, several IESG members have raised the >question of whether it makes sense to revise the original RFC 3825 >DHCP option or just to create a new DHCP option with a new code point. > >Here are the potential choices for moving forward: > >a. Continue to use a single option code for both versions 0 and >1. In this approach the document would be left more or less as it >is, but additional material would be added to the discussion of >backward compatibility in Section 2.2.1 to explain why the WG took >this approach. > >b. Allocate a new option code for the version 1 format, leave >material on the original option in the document. In this approach, >the document would continue to revise RFC 3825, but would also >define new DHCPv4 and DHCPv6 options. While this approach would be >consistent with the GEOPRIV WG charter (which describes the goal of >the work item as "to obsolete 3825"), it is not clear whether there >would be enough clarifications/revisions to RFC 3825 material to >justify keeping that material in it. > >c. Allocate new DHCPv4 and DHCPv6 option codes for the new format, >but remove material relating to the original RFC 3825 format. This >approach would define new option codes, but would remove discussion >of option code 123. Such a document would probably be quite a bit >shorter, since material relating to backward compatibility could be removed. > >One question relating to this approach would be whether the new >document would obsolete RFC 3825 or not. Since the GEOPRIV WG >charter lists the work item as "Submit an draft for DHCP geodetic >location to the IESG for publication as PS to obsolete 3825" if the >new document did not obsolete RFC 3825 then a charter change would >seem to be required. >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www.ietf.org/mailman/listinfo/geopriv From creed@opengeospatial.org Mon Jan 3 09:50:08 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5CA13A69D2 for ; Mon, 3 Jan 2011 09:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.806 X-Spam-Level: * X-Spam-Status: No, score=1.806 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_40=-0.185, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-xTbx8kYeVF for ; Mon, 3 Jan 2011 09:50:07 -0800 (PST) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by core3.amsl.com (Postfix) with ESMTP id BE9703A69BC for ; Mon, 3 Jan 2011 09:50:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id AE48D5A15F for ; Mon, 3 Jan 2011 12:52:10 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (mail.opengeospatial.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8jUF68XUn7y for ; Mon, 3 Jan 2011 12:52:09 -0500 (EST) Received: from CarlandSusieOf (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id B74665A156 for ; Mon, 3 Jan 2011 12:52:09 -0500 (EST) Message-ID: <98372483D9F84A60A75AF144BFA542BB@CarlandSusieOf> From: "Carl Reed" To: Date: Mon, 3 Jan 2011 10:28:05 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0535_01CBAB30.E86F9DC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Subject: [Geopriv] FYI: Perhaps Germane of interest for this group - privacy and location X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 17:50:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0535_01CBAB30.E86F9DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.directionsmag.com/pressreleases/privacy-push-will-impact-geolo= cation-sector-attorney-says/148920 Carl Reed, PhD CTO and Executive Director Specification Program Open Geospatial Consortium www.opengeospatial.org The OGC: Making Location Count! --------------------- This communication, including attachments, is for the exclusive use of = addressee and may contain proprietary, confidential or privileged = information. If you are not the intended recipient, any use, copying, = disclosure, dissemination or distribution is strictly prohibited. If you = are not the intended recipient, please notify the sender immediately by = return email and delete this communication and destroy all copies. "The important thing is not to stop questioning." -- Albert Einstein=20 "Security is mostly a superstition. It does not exist in nature. Life is = either a daring adventure or nothing." -- Helen Keller ------=_NextPart_000_0535_01CBAB30.E86F9DC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.directionsmag.com/= pressreleases/privacy-push-will-impact-geolocation-sector-attorney-says/1= 48920
 
Carl Reed, PhD
CTO and Executive Director Specification = Program
Open=20 Geospatial Consortium
www.opengeospatial.org
 
The OGC: Making Location Count!
 
---------------------
 
This communication, including attachments, is for the exclusive use = of=20 addressee and may contain proprietary, confidential or privileged = information.=20 If you are not the intended recipient, any use, copying, disclosure,=20 dissemination or distribution is strictly prohibited. If you are not the = intended recipient, please notify the sender  immediately by return = email=20 and delete this communication and destroy all copies.
 
"The important thing is not to stop questioning." -- Albert = Einstein=20
"Security is mostly a superstition. It does not exist in nature. = Life is=20 either a daring adventure or nothing." -- Helen Keller =
------=_NextPart_000_0535_01CBAB30.E86F9DC0-- From bernard_aboba@hotmail.com Mon Jan 3 10:55:39 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF9CE3A6AAF for ; Mon, 3 Jan 2011 10:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8a8hVkYvQ7c for ; Mon, 3 Jan 2011 10:55:38 -0800 (PST) Received: from blu0-omc1-s8.blu0.hotmail.com (blu0-omc1-s8.blu0.hotmail.com [65.55.116.19]) by core3.amsl.com (Postfix) with ESMTP id 764F13A6AAB for ; Mon, 3 Jan 2011 10:55:38 -0800 (PST) Received: from BLU152-W53 ([65.55.116.8]) by blu0-omc1-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Jan 2011 10:57:45 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_f9f80053-4d9f-4079-af60-bab7d2ac594e_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: , Date: Mon, 3 Jan 2011 10:57:45 -0800 Importance: Normal In-Reply-To: <201101031724.p03HOVxW029784@sj-core-5.cisco.com> References: , <201101031724.p03HOVxW029784@sj-core-5.cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jan 2011 18:57:45.0869 (UTC) FILETIME=[1BA933D0:01CBAB78] Cc: rdroms@cisco.com Subject: Re: [Geopriv] Options for Resolution of DISCUSS comments on RFC 3825bis X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 18:55:39 -0000 --_f9f80053-4d9f-4079-af60-bab7d2ac594e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable James Polk said:=20 > If I understand this correctly=2C we would have the following scenario: >=20 > - version 0 servers would send Option 123 > - version 1 servers would send Option 500 (or whatever new code is assign= ed) >=20 > Under this scenario=2C Option 500 servers wouldn't *ever* send Option=20 > 123 (i.e.=2C version 0)=2C but would (normatively) point to RFC 3825 for= =20 > those wanting to send Option 123 (i.e.=2C version 0). [BA] A DHCP client could indicate its preference based on option code no?=20 So a client could request Option 123 or Option 500=2C or both=2C and a DHCP server could respond based on that.=20 Having a server always send Option 500 (even to a client that only supports Option 123) seems like a bad idea (and doesn't solve the backward compatibi= lity problem).=20 > >Would there ever be a situation where you'd send both the old option=20 > >(version 0) as well as the new option (also with version 0)? >=20 > If there ever was this desire=2C then both Options 123 and 500 would be=20 > included in either the DHCP request or reply message - as I believe I=20 > see a clear separation between v0 and v1 at this point. [BA] Right. So each option corresponds to only one version.=20 =20 > >It seems to me that if both options were sent=2C the new option would=20 > >need to be version 1. >=20 > Specifically=2C I believe the two Options (123 and 500) would be enough=20 > of a separation. Pragmatically=2C for readers=2C I believe stating that=20 > Option 500 is version 1 would make more sense to make sure to remove=20 > another level of confusion that could occur. [BA] Right. So we could keep the "Ver" field=2C but state that the field MUST be 1 for Option 500.=20 > If we go down this path=2C knowing if we make the change to remove the=20 > "implement version 0 this way" from the text - it's headed back to=20 > the WG regardless=2C we take the easier route and just modify out the=20 > existing version 0 text=2C and instead point normatively to RFC 3825=20 > for those interested in version 0=2C and keep as much of the version 1=20 > text as possible. This should result in a single new rev for WGLC=20 > confirmation and get this back to the IESG for their consideration. [BA] Agree that modifying/removing "version 0" material would require the document to go back to the WG. Also agree that we should keep (and leave alone) the version 1 material. As for pointing normatively to RFC 3825=2C there seems to be some material in RFC 3825bis that attempts to "clarify" RFC 3825. So it seems like we h= ave the following choices: a. Have RFC 3825bis define both Options 123 (IPv4 only) and Option 500 (IP= v4 and IPv6).=20 In this case=2C RFC 3825bis would "Obsolete: RFC 3825".=20 b. Have RFC 3825bis define only Option 500 (IPv4 and IPv6). In this case=2C RFC 3825bis might "Update: RFC 3825" (or maybe not).=20 It would appear to me that the GEOPRIV WG charter seems to imply Approach A= :=20 Sep =20 =20 =20 2009 =20 =20 Submit an draft for DHCP geodetic location to the IESG for publication = as PS to obsolete 3825 =20 = --_f9f80053-4d9f-4079-af60-bab7d2ac594e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable James Polk said:

>=3B If I understand this correctly=2C we would = have the following scenario:
>=3B
>=3B - version 0 servers would= send Option 123
>=3B - version 1 servers would send Option 500 (or wh= atever new code is assigned)
>=3B
>=3B Under this scenario=2C Op= tion 500 servers wouldn't *ever* send Option
>=3B 123 (i.e.=2C versio= n 0)=2C but would (normatively) point to RFC 3825 for
>=3B those want= ing to send Option 123 (i.e.=2C version 0).

[BA] A DHCP client could= indicate its preference based on option code no?
So a client could req= uest Option 123 or Option 500=2C or both=2C and a DHCP
server could resp= ond based on that.

Having a server always send Option 500 (even to = a client that only supports
Option 123) seems like a bad idea (and doesn= 't solve the backward compatibility problem).

>=3B >=3BWould th= ere ever be a situation where you'd send both the old option
>=3B >= =3B(version 0) as well as the new option (also with version 0)?
>=3B <= br>>=3B If there ever was this desire=2C then both Options 123 and 500 wo= uld be
>=3B included in either the DHCP request or reply message - as= I believe I
>=3B see a clear separation between v0 and v1 at this po= int.

[BA] Right. =3B So each option corresponds to only one vers= ion.
 =3B
>=3B >=3BIt seems to me that if both options were = sent=2C the new option would
>=3B >=3Bneed to be version 1.
>= =3B
>=3B Specifically=2C I believe the two Options (123 and 500) woul= d be enough
>=3B of a separation. Pragmatically=2C for readers=2C I b= elieve stating that
>=3B Option 500 is version 1 would make more sens= e to make sure to remove
>=3B another level of confusion that could o= ccur.

[BA] Right. =3B So we could keep the "Ver" field=2C but st= ate that the field
MUST be 1 for Option 500.

>=3B If we go dow= n this path=2C knowing if we make the change to remove the
>=3B "impl= ement version 0 this way" from the text - it's headed back to
>=3B th= e WG regardless=2C we take the easier route and just modify out the
>= =3B existing version 0 text=2C and instead point normatively to RFC 3825 >=3B for those interested in version 0=2C and keep as much of the versi= on 1
>=3B text as possible. This should result in a single new rev fo= r WGLC
>=3B confirmation and get this back to the IESG for their cons= ideration.

[BA] Agree that modifying/removing "version 0" material w= ould require
the document to go back to the WG. =3B =3B Also agr= ee that we should keep
(and leave alone) the version 1 material.

= As for pointing normatively to RFC 3825=2C there seems to be some material<= br>in RFC 3825bis that attempts to "clarify" RFC 3825. =3B =3B So i= t seems like we have
the following choices:

a. =3B Have RFC 3= 825bis define both Options 123 (IPv4 only) and Option 500 (IPv4 and IPv6). =
In this case=2C RFC 3825bis would "Obsolete: RFC 3825".

b. Have= RFC 3825bis define only Option 500 (IPv4 and IPv6).
In this case=2C RFC= 3825bis might "Update: RFC 3825" (or maybe not).

It would appear t= o me that the GEOPRIV WG charter seems to imply Approach A:

Sep =20 =20 =20 2009 =20 =20 Submit an draft for DHCP geodetic location to the IESG for publication = as PS to obsolete 3825


= --_f9f80053-4d9f-4079-af60-bab7d2ac594e_-- From jmpolk@cisco.com Mon Jan 3 12:11:32 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE62C3A6A1D for ; Mon, 3 Jan 2011 12:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSeaBoT+a2QU for ; Mon, 3 Jan 2011 12:11:31 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C87C33A6AB9 for ; Mon, 3 Jan 2011 12:11:31 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 03 Jan 2011 20:06:10 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p03K69H4010150; Mon, 3 Jan 2011 20:06:09 GMT Message-Id: <201101032006.p03K69H4010150@sj-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 03 Jan 2011 14:06:07 -0600 To: Bernard Aboba , , From: "James M. Polk" In-Reply-To: References: <201101031724.p03HOVxW029784@sj-core-5.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: rdroms@cisco.com Subject: Re: [Geopriv] Options for Resolution of DISCUSS comments on RFC 3825bis X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 20:11:33 -0000 Bernard in-line At 12:57 PM 1/3/2011, Bernard Aboba wrote: >James Polk said: > > > If I understand this correctly, we would have the following scenario: > > > > - version 0 servers would send Option 123 > > - version 1 servers would send Option 500 (or whatever new code > is assigned) > > > > Under this scenario, Option 500 servers wouldn't *ever* send Option > > 123 (i.e., version 0), but would (normatively) point to RFC 3825 for > > those wanting to send Option 123 (i.e., version 0). > >[BA] A DHCP client could indicate its preference based on option code no? [JMP] yes, but including either Option code or include both >So a client could request Option 123 or Option 500, or both, and a DHCP >server could respond based on that. > >Having a server always send Option 500 (even to a client that only supports >Option 123) seems like a bad idea (and doesn't solve the backward >compatibility problem). [JMP] I believe DHCP clients that receive Options they don't understand simply ignore them, so if a client receives an Option 500, it should be ignored and therefore not cause backwards compatibility issues, right? That said - this RFC-to-be needs to state somewhere something like: If a client requests only Option 123 [RFC3825], the server SHOULD NOT transmit an Option 500 (defined within this document) because it could lead to interoperability issues. Because the two Options would look so much alike, we shouldn't chance sending the new Option to the clients who only support the old version from 3825. I could be over doing this problem, as the SHOULD NOT should cover this new doc. > > >Would there ever be a situation where you'd send both the old option > > >(version 0) as well as the new option (also with version 0)? > > > > If there ever was this desire, then both Options 123 and 500 would be > > included in either the DHCP request or reply message - as I believe I > > see a clear separation between v0 and v1 at this point. > >[BA] Right. So each option corresponds to only one version. > > > >It seems to me that if both options were sent, the new option would > > >need to be version 1. > > > > Specifically, I believe the two Options (123 and 500) would be enough > > of a separation. Pragmatically, for readers, I believe stating that > > Option 500 is version 1 would make more sense to make sure to remove > > another level of confusion that could occur. > >[BA] Right. So we could keep the "Ver" field, but state that the field >MUST be 1 for Option 500. [JMP] I think introducing the VER field in Option 500 creates the ability for a future version 2, which is probably a good thing, so I think it ought to stay. > > If we go down this path, knowing if we make the change to remove the > > "implement version 0 this way" from the text - it's headed back to > > the WG regardless, we take the easier route and just modify out the > > existing version 0 text, and instead point normatively to RFC 3825 > > for those interested in version 0, and keep as much of the version 1 > > text as possible. This should result in a single new rev for WGLC > > confirmation and get this back to the IESG for their consideration. > >[BA] Agree that modifying/removing "version 0" material would require >the document to go back to the WG. Also agree that we should keep >(and leave alone) the version 1 material. [JMP] agreed >As for pointing normatively to RFC 3825, there seems to be some material >in RFC 3825bis that attempts to "clarify" RFC 3825. So it seems like we have >the following choices: > >a. Have RFC 3825bis define both Options 123 (IPv4 only) and Option >500 (IPv4 and IPv6). >In this case, RFC 3825bis would "Obsolete: RFC 3825". > >b. Have RFC 3825bis define only Option 500 (IPv4 and IPv6). >In this case, RFC 3825bis might "Update: RFC 3825" (or maybe not). [JMP] I think you have an option 'b' and 'c' in your above option 'b.'. The difference being whether or not you have 3825bis update 3825 (new option b), or leave it alone (which becomes option c). IMO - within this context, the new option b is the one to go with, because of the clarifying text >It would appear to me that the GEOPRIV WG charter seems to imply Approach A: > >Sep 2009 Submit an draft for DHCP geodetic location to the IESG for >publication as PS to obsolete 3825 [JMP] I agree as well, and this is a bit of a sticking point James From Martin.Thomson@andrew.com Tue Jan 4 15:59:13 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F243A6DCD for ; Tue, 4 Jan 2011 15:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojjpyrwvu61e for ; Tue, 4 Jan 2011 15:59:12 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id C7A173A6DAA for ; Tue, 4 Jan 2011 15:59:12 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:64412 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S511776Ab1AEABT (ORCPT ); Tue, 4 Jan 2011 18:01:19 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Tue, 4 Jan 2011 18:01:18 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 5 Jan 2011 08:01:14 +0800 From: "Thomson, Martin" To: "James M. Polk" , Bernard Aboba , "geopriv@ietf.org" Date: Wed, 5 Jan 2011 08:01:13 +0800 Thread-Topic: [Geopriv] Options for Resolution of DISCUSS comments on RFC 3825bis Thread-Index: AcurgrkOC9k55IawSjqIbkjnz+2OUAA4/MUQ Message-ID: <8B0A9FCBB9832F43971E38010638454F03F50ED4FE@SISPE7MB1.commscope.com> References: <201101031724.p03HOVxW029784@sj-core-5.cisco.com> <201101032006.p03K69H4010150@sj-core-5.cisco.com> In-Reply-To: <201101032006.p03K69H4010150@sj-core-5.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "rdroms@cisco.com" Subject: Re: [Geopriv] Options for Resolution of DISCUSS comments on RFC 3825bis X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 23:59:14 -0000 SXQgbG9va3MgbGlrZSB3ZSBzaG91bGQgdGFrZSBhbm90aGVyIHBhc3MgYXQgdGhpcyBpbiB0aGUg d29ya2luZyBncm91cC4NCg0KTGV0J3Mgbm90IGNoYW5nZSB0b28gbXVjaCBpbiB0aGUgcHJvY2Vz cyBpbiB0aGUgaW50ZXJlc3RzIG9mIGdldHRpbmcgdGhpcyBkb25lIHF1aWNrbHkuDQoNCk1vcmUg aW5saW5lLi4uDQoNCk9uIDIwMTEtMDEtMDQgYXQgMDc6MDY6MDcsIEphbWVzIE0uIFBvbGsgd3Jv dGU6DQo+ID5bQkFdIEEgREhDUCBjbGllbnQgY291bGQgaW5kaWNhdGUgaXRzIHByZWZlcmVuY2Ug YmFzZWQgb24gb3B0aW9uIGNvZGUNCj4gbm8/DQo+IA0KPiBbSk1QXSB5ZXMsIGJ1dCBpbmNsdWRp bmcgZWl0aGVyIE9wdGlvbiBjb2RlIG9yIGluY2x1ZGUgYm90aA0KDQpbTVRdIE9wdGlvbiA1NSAo YW5kIGVxdWl2YWxlbnQgREhDUHY2KSB3b3VsZCBiZSB0aGUgd2F5IHRoaXMgaXMgZG9uZSwgdGhl IGNsaWVudCBjYW4gbGlzdCBpdHMgcHJlZmVycmVkIG9wdGlvbiBudW1iZXIuICBBIG5vdGUgb24g aG93IHRoaXMgd29ya3MgZm9yIHZlcnNpb25pbmcgcHVycG9zZXMgd291bGQgYmUgbmljZS4NCg0K W01UXSBLZWVwIGluIG1pbmQgdGhhdCBhZHZpY2UgaW4gUkZDIDQ3NzYgc3VnZ2VzdHMgdGhhdCBh IHNlcnZlciBzaG91bGQgbmV2ZXIgc2VuZCB0aGlzIGluZm9ybWF0aW9uIHVuc29saWNpdGVkLiAg SWYgd2UgbWFpbnRhaW4gdGhhdCBhZHZpY2UsIHRoZW4gdGhlcmUgc2hvdWxkIGJlIG5vIHByb2Js ZW0uICANCg0KPiBbSk1QXSBJIGJlbGlldmUgREhDUCBjbGllbnRzIHRoYXQgcmVjZWl2ZSBPcHRp b25zIHRoZXkgZG9uJ3QNCj4gdW5kZXJzdGFuZCBzaW1wbHkgaWdub3JlIHRoZW0sIHNvIGlmIGEg Y2xpZW50IHJlY2VpdmVzIGFuIE9wdGlvbiA1MDAsDQo+IGl0IHNob3VsZCBiZSBpZ25vcmVkIGFu ZCB0aGVyZWZvcmUgbm90IGNhdXNlIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5DQo+IGlzc3Vlcywg cmlnaHQ/DQoNCltNVF0gIFRoYXQncyB0aGUgd2F5IGl0IHdvcmtzLiAgQSBsb3Qgb2YgREhDUCBz ZXJ2ZXJzIHByb3ZpZGUgT3B0aW9ucyB0aGF0IGFyZW4ndCB1c2VkLg0KDQo+IFRoYXQgc2FpZCAt IHRoaXMgUkZDLXRvLWJlIG5lZWRzIHRvIHN0YXRlIHNvbWV3aGVyZSBzb21ldGhpbmcgbGlrZToN Cj4gDQo+ICAgICBJZiBhIGNsaWVudCByZXF1ZXN0cyBvbmx5IE9wdGlvbiAxMjMgW1JGQzM4MjVd LCB0aGUgc2VydmVyIFNIT1VMRA0KPiBOT1QNCj4gICAgIHRyYW5zbWl0IGFuIE9wdGlvbiA1MDAg KGRlZmluZWQgd2l0aGluIHRoaXMgZG9jdW1lbnQpIGJlY2F1c2UgaXQNCj4gY291bGQNCj4gICAg IGxlYWQgdG8gaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMuDQoNCltNVF0gVGhlIGFkdmljZSBvbiAi ZG9uJ3QgcHJvdmlkZSB1bmxlc3MgZXhwbGljaXRseSByZXF1ZXN0ZWQiIHNob3VsZCBiZSBzdWZm aWNpZW50Lg0KDQo+ID4gPiA+SXQgc2VlbXMgdG8gbWUgdGhhdCBpZiBib3RoIG9wdGlvbnMgd2Vy ZSBzZW50LCB0aGUgbmV3IG9wdGlvbg0KPiB3b3VsZA0KPiA+ID4gPm5lZWQgdG8gYmUgdmVyc2lv biAxLg0KPiA+ID4NCj4gPiA+IFNwZWNpZmljYWxseSwgSSBiZWxpZXZlIHRoZSB0d28gT3B0aW9u cyAoMTIzIGFuZCA1MDApIHdvdWxkIGJlDQo+IGVub3VnaA0KPiA+ID4gb2YgYSBzZXBhcmF0aW9u LiBQcmFnbWF0aWNhbGx5LCBmb3IgcmVhZGVycywgSSBiZWxpZXZlIHN0YXRpbmcgdGhhdA0KPiA+ ID4gT3B0aW9uIDUwMCBpcyB2ZXJzaW9uIDEgd291bGQgbWFrZSBtb3JlIHNlbnNlIHRvIG1ha2Ug c3VyZSB0bw0KPiByZW1vdmUNCj4gPiA+IGFub3RoZXIgbGV2ZWwgb2YgY29uZnVzaW9uIHRoYXQg Y291bGQgb2NjdXIuDQo+ID4NCj4gPltCQV0gUmlnaHQuICBTbyB3ZSBjb3VsZCBrZWVwIHRoZSAi VmVyIiBmaWVsZCwgYnV0IHN0YXRlIHRoYXQgdGhlDQo+IGZpZWxkDQo+ID5NVVNUIGJlIDEgZm9y IE9wdGlvbiA1MDAuDQo+IA0KPiBbSk1QXSBJIHRoaW5rIGludHJvZHVjaW5nIHRoZSBWRVIgZmll bGQgaW4gT3B0aW9uIDUwMCBjcmVhdGVzIHRoZQ0KPiBhYmlsaXR5IGZvciBhIGZ1dHVyZSB2ZXJz aW9uIDIsIHdoaWNoIGlzIHByb2JhYmx5IGEgZ29vZCB0aGluZywgc28gSQ0KPiB0aGluayBpdCBv dWdodCB0byBzdGF5Lg0KDQpbTVRdIFNvdW5kcyByZWFzb25hYmxlLiAgVGhlIGh5cG90aGV0aWNh bCBPcHRpb24gNTAwIGNvdWxkIHNldCAiVmVyIiB0byAwLCBidXQgdGhhdCdzIG5vdCByZWFsbHkg Z29pbmcgdG8gaGVscC4NCg0KDQo+ID5bQkFdIEFncmVlIHRoYXQgbW9kaWZ5aW5nL3JlbW92aW5n ICJ2ZXJzaW9uIDAiIG1hdGVyaWFsIHdvdWxkIHJlcXVpcmUNCj4gPnRoZSBkb2N1bWVudCB0byBn byBiYWNrIHRvIHRoZSBXRy4gICBBbHNvIGFncmVlIHRoYXQgd2Ugc2hvdWxkIGtlZXANCj4gPihh bmQgbGVhdmUgYWxvbmUpIHRoZSB2ZXJzaW9uIDEgbWF0ZXJpYWwuDQo+IA0KPiBbSk1QXSBhZ3Jl ZWQNCg0KW01UXSBXb3JrcyBmb3IgbWUuDQogDQo+ID5BcyBmb3IgcG9pbnRpbmcgbm9ybWF0aXZl bHkgdG8gUkZDIDM4MjUsIHRoZXJlIHNlZW1zIHRvIGJlIHNvbWUNCj4gbWF0ZXJpYWwNCj4gPmlu IFJGQyAzODI1YmlzIHRoYXQgYXR0ZW1wdHMgdG8gImNsYXJpZnkiIFJGQyAzODI1LiAgIFNvIGl0 IHNlZW1zIGxpa2UNCj4gd2UgaGF2ZQ0KPiA+dGhlIGZvbGxvd2luZyBjaG9pY2VzOg0KPiA+DQo+ ID5hLiAgSGF2ZSBSRkMgMzgyNWJpcyBkZWZpbmUgYm90aCBPcHRpb25zIDEyMyAoSVB2NCBvbmx5 KSBhbmQgT3B0aW9uDQo+ID41MDAgKElQdjQgYW5kIElQdjYpLg0KPiA+SW4gdGhpcyBjYXNlLCBS RkMgMzgyNWJpcyB3b3VsZCAiT2Jzb2xldGU6IFJGQyAzODI1Ii4NCj4gPg0KPiA+Yi4gSGF2ZSBS RkMgMzgyNWJpcyBkZWZpbmUgb25seSBPcHRpb24gNTAwIChJUHY0IGFuZCBJUHY2KS4NCj4gPklu IHRoaXMgY2FzZSwgUkZDIDM4MjViaXMgbWlnaHQgIlVwZGF0ZTogUkZDIDM4MjUiIChvciBtYXli ZSBub3QpLg0KPiANCj4gW0pNUF0gSSB0aGluayB5b3UgaGF2ZSBhbiBvcHRpb24gJ2InIGFuZCAn YycgaW4geW91ciBhYm92ZSBvcHRpb24NCj4gJ2IuJy4gVGhlIGRpZmZlcmVuY2UgYmVpbmcgd2hl dGhlciBvciBub3QgeW91IGhhdmUgMzgyNWJpcyB1cGRhdGUNCj4gMzgyNSAobmV3IG9wdGlvbiBi KSwgb3IgbGVhdmUgaXQgYWxvbmUgKHdoaWNoIGJlY29tZXMgb3B0aW9uIGMpLg0KPiANCj4gSU1P IC0gd2l0aGluIHRoaXMgY29udGV4dCwgdGhlIG5ldyBvcHRpb24gYiBpcyB0aGUgb25lIHRvIGdv IHdpdGgsDQo+IGJlY2F1c2Ugb2YgdGhlIGNsYXJpZnlpbmcgdGV4dA0KDQpbTVRdICBJJ2QgcHJl ZmVyIHRoYXQgdG9vLiAgTm8gcG9pbnQgaW4gZGlzY2FyZGluZyBhbGwgdGhhdCB3b3JrIHRoYXQg d2UndmUgZG9uZSBpbiBjbGFyaWZ5aW5nIGV2ZXJ5dGhpbmcuDQoNCj4gPlNlcCAyMDA5IFN1Ym1p dCBhbiBkcmFmdCBmb3IgREhDUCBnZW9kZXRpYyBsb2NhdGlvbiB0byB0aGUgSUVTRyBmb3INCj4g PnB1YmxpY2F0aW9uIGFzIFBTIHRvIG9ic29sZXRlIDM4MjUNCj4gDQo+IFtKTVBdIEkgYWdyZWUg YXMgd2VsbCwgYW5kIHRoaXMgaXMgYSBiaXQgb2YgYSBzdGlja2luZyBwb2ludA0KDQpbTVRdIEkg Y2FuJ3Qgc2VlIHRoaXMgYmVpbmcgYSBtYWpvciBvYnN0YWNsZSBpZiB3ZSBkZWNpZGUgdGhhdCB0 aGlzIGlzIHRoZSByaWdodCB3YXkgdG8gcHJvY2VlZC4NCg0K From bernard_aboba@hotmail.com Tue Jan 4 22:01:35 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92C93A6A77 for ; Tue, 4 Jan 2011 22:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytJ-NXPCvc8r for ; Tue, 4 Jan 2011 22:01:34 -0800 (PST) Received: from blu0-omc3-s18.blu0.hotmail.com (blu0-omc3-s18.blu0.hotmail.com [65.55.116.93]) by core3.amsl.com (Postfix) with ESMTP id 426143A6A5E for ; Tue, 4 Jan 2011 22:01:34 -0800 (PST) Received: from BLU152-DS5 ([65.55.116.74]) by blu0-omc3-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Jan 2011 22:03:41 -0800 X-Originating-IP: [98.203.198.61] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Thomson, Martin'" , "'James M. Polk'" , References: <201101031724.p03HOVxW029784@sj-core-5.cisco.com> <201101032006.p03K69H4010150@sj-core-5.cisco.com> <8B0A9FCBB9832F43971E38010638454F03F50ED4FE@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F50ED4FE@SISPE7MB1.commscope.com> Date: Tue, 4 Jan 2011 22:03:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcurgrkOC9k55IawSjqIbkjnz+2OUAA4/MUQAA3LxRA= Content-Language: en-us X-OriginalArrivalTime: 05 Jan 2011 06:03:41.0074 (UTC) FILETIME=[4D3B6720:01CBAC9E] Cc: rdroms@cisco.com Subject: Re: [Geopriv] Options for Resolution of DISCUSS comments on RFC 3825bis X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 06:01:36 -0000 I've gone through the document and made changes to define a new DHCPv4 = option.=20 A strawman is available here: http://www.drizzle.com/~aboba/GEOPRIV/draft-ietf-geopriv-rfc3825bis-15.tx= t -----Original Message----- From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=20 Sent: Tuesday, January 04, 2011 4:01 PM To: James M. Polk; Bernard Aboba; geopriv@ietf.org Cc: rdroms@cisco.com Subject: RE: [Geopriv] Options for Resolution of DISCUSS comments on RFC = 3825bis It looks like we should take another pass at this in the working group. Let's not change too much in the process in the interests of getting = this done quickly. More inline... On 2011-01-04 at 07:06:07, James M. Polk wrote: > >[BA] A DHCP client could indicate its preference based on option code > no? >=20 > [JMP] yes, but including either Option code or include both [MT] Option 55 (and equivalent DHCPv6) would be the way this is done, = the client can list its preferred option number. A note on how this = works for versioning purposes would be nice. [MT] Keep in mind that advice in RFC 4776 suggests that a server should = never send this information unsolicited. If we maintain that advice, = then there should be no problem. =20 > [JMP] I believe DHCP clients that receive Options they don't > understand simply ignore them, so if a client receives an Option 500, > it should be ignored and therefore not cause backwards compatibility > issues, right? [MT] That's the way it works. A lot of DHCP servers provide Options = that aren't used. > That said - this RFC-to-be needs to state somewhere something like: >=20 > If a client requests only Option 123 [RFC3825], the server SHOULD > NOT > transmit an Option 500 (defined within this document) because it > could > lead to interoperability issues. [MT] The advice on "don't provide unless explicitly requested" should be = sufficient. > > > >It seems to me that if both options were sent, the new option > would > > > >need to be version 1. > > > > > > Specifically, I believe the two Options (123 and 500) would be > enough > > > of a separation. Pragmatically, for readers, I believe stating = that > > > Option 500 is version 1 would make more sense to make sure to > remove > > > another level of confusion that could occur. > > > >[BA] Right. So we could keep the "Ver" field, but state that the > field > >MUST be 1 for Option 500. >=20 > [JMP] I think introducing the VER field in Option 500 creates the > ability for a future version 2, which is probably a good thing, so I > think it ought to stay. [MT] Sounds reasonable. The hypothetical Option 500 could set "Ver" to = 0, but that's not really going to help. > >[BA] Agree that modifying/removing "version 0" material would require > >the document to go back to the WG. Also agree that we should keep > >(and leave alone) the version 1 material. >=20 > [JMP] agreed [MT] Works for me. =20 > >As for pointing normatively to RFC 3825, there seems to be some > material > >in RFC 3825bis that attempts to "clarify" RFC 3825. So it seems = like > we have > >the following choices: > > > >a. Have RFC 3825bis define both Options 123 (IPv4 only) and Option > >500 (IPv4 and IPv6). > >In this case, RFC 3825bis would "Obsolete: RFC 3825". > > > >b. Have RFC 3825bis define only Option 500 (IPv4 and IPv6). > >In this case, RFC 3825bis might "Update: RFC 3825" (or maybe not). >=20 > [JMP] I think you have an option 'b' and 'c' in your above option > 'b.'. The difference being whether or not you have 3825bis update > 3825 (new option b), or leave it alone (which becomes option c). >=20 > IMO - within this context, the new option b is the one to go with, > because of the clarifying text [MT] I'd prefer that too. No point in discarding all that work that = we've done in clarifying everything. > >Sep 2009 Submit an draft for DHCP geodetic location to the IESG for > >publication as PS to obsolete 3825 >=20 > [JMP] I agree as well, and this is a bit of a sticking point [MT] I can't see this being a major obstacle if we decide that this is = the right way to proceed. From rbarnes@bbn.com Wed Jan 5 10:11:34 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFD543A6BE9 for ; Wed, 5 Jan 2011 10:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.866 X-Spam-Level: X-Spam-Status: No, score=-102.866 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAuS0Ta9i+vD for ; Wed, 5 Jan 2011 10:11:33 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 330013A6C17 for ; Wed, 5 Jan 2011 10:11:33 -0800 (PST) Received: from [192.1.255.181] (port=50011 helo=col-raltmann-l1.nira.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PaXrf-0000I5-JB for geopriv@ietf.org; Wed, 05 Jan 2011 13:13:39 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: "Richard L. Barnes" In-Reply-To: Date: Wed, 5 Jan 2011 13:13:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9D11F264-564A-49E2-8E1B-E5290A1FCC0E@bbn.com> References: <201101031724.p03HOVxW029784@sj-core-5.cisco.com> <201101032006.p03K69H4010150@sj-core-5.cisco.com> <8B0A9FCBB9832F43971E38010638454F03F50ED4FE@SISPE7MB1.commscope.com> To: geopriv@ietf.org X-Mailer: Apple Mail (2.1082) Subject: [Geopriv] Consensus call: DHCP option numbers X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 18:11:34 -0000 Dear working group, In order to get some sort of gauge of consensus, please take a look at = Bernard's draft document and indicate whether these changes are OK with = you. A diff can be found here: Please send responses to the list no later than Wednesday, 12 Jan 2011. Thanks, --Richard On Jan 5, 2011, at 1:03 AM, Bernard Aboba wrote: > I've gone through the document and made changes to define a new DHCPv4 = option.=20 >=20 > A strawman is available here: > = http://www.drizzle.com/~aboba/GEOPRIV/draft-ietf-geopriv-rfc3825bis-15.txt= >=20 >=20 > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=20 > Sent: Tuesday, January 04, 2011 4:01 PM > To: James M. Polk; Bernard Aboba; geopriv@ietf.org > Cc: rdroms@cisco.com > Subject: RE: [Geopriv] Options for Resolution of DISCUSS comments on = RFC 3825bis >=20 > It looks like we should take another pass at this in the working = group. >=20 > Let's not change too much in the process in the interests of getting = this done quickly. >=20 > More inline... >=20 > On 2011-01-04 at 07:06:07, James M. Polk wrote: >>> [BA] A DHCP client could indicate its preference based on option = code >> no? >>=20 >> [JMP] yes, but including either Option code or include both >=20 > [MT] Option 55 (and equivalent DHCPv6) would be the way this is done, = the client can list its preferred option number. A note on how this = works for versioning purposes would be nice. >=20 > [MT] Keep in mind that advice in RFC 4776 suggests that a server = should never send this information unsolicited. If we maintain that = advice, then there should be no problem. =20 >=20 >> [JMP] I believe DHCP clients that receive Options they don't >> understand simply ignore them, so if a client receives an Option 500, >> it should be ignored and therefore not cause backwards compatibility >> issues, right? >=20 > [MT] That's the way it works. A lot of DHCP servers provide Options = that aren't used. >=20 >> That said - this RFC-to-be needs to state somewhere something like: >>=20 >> If a client requests only Option 123 [RFC3825], the server SHOULD >> NOT >> transmit an Option 500 (defined within this document) because it >> could >> lead to interoperability issues. >=20 > [MT] The advice on "don't provide unless explicitly requested" should = be sufficient. >=20 >>>>> It seems to me that if both options were sent, the new option >> would >>>>> need to be version 1. >>>>=20 >>>> Specifically, I believe the two Options (123 and 500) would be >> enough >>>> of a separation. Pragmatically, for readers, I believe stating that >>>> Option 500 is version 1 would make more sense to make sure to >> remove >>>> another level of confusion that could occur. >>>=20 >>> [BA] Right. So we could keep the "Ver" field, but state that the >> field >>> MUST be 1 for Option 500. >>=20 >> [JMP] I think introducing the VER field in Option 500 creates the >> ability for a future version 2, which is probably a good thing, so I >> think it ought to stay. >=20 > [MT] Sounds reasonable. The hypothetical Option 500 could set "Ver" = to 0, but that's not really going to help. >=20 >=20 >>> [BA] Agree that modifying/removing "version 0" material would = require >>> the document to go back to the WG. Also agree that we should keep >>> (and leave alone) the version 1 material. >>=20 >> [JMP] agreed >=20 > [MT] Works for me. >=20 >>> As for pointing normatively to RFC 3825, there seems to be some >> material >>> in RFC 3825bis that attempts to "clarify" RFC 3825. So it seems = like >> we have >>> the following choices: >>>=20 >>> a. Have RFC 3825bis define both Options 123 (IPv4 only) and Option >>> 500 (IPv4 and IPv6). >>> In this case, RFC 3825bis would "Obsolete: RFC 3825". >>>=20 >>> b. Have RFC 3825bis define only Option 500 (IPv4 and IPv6). >>> In this case, RFC 3825bis might "Update: RFC 3825" (or maybe not). >>=20 >> [JMP] I think you have an option 'b' and 'c' in your above option >> 'b.'. The difference being whether or not you have 3825bis update >> 3825 (new option b), or leave it alone (which becomes option c). >>=20 >> IMO - within this context, the new option b is the one to go with, >> because of the clarifying text >=20 > [MT] I'd prefer that too. No point in discarding all that work that = we've done in clarifying everything. >=20 >>> Sep 2009 Submit an draft for DHCP geodetic location to the IESG for >>> publication as PS to obsolete 3825 >>=20 >> [JMP] I agree as well, and this is a bit of a sticking point >=20 > [MT] I can't see this being a major obstacle if we decide that this is = the right way to proceed. >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From rbarnes@bbn.com Wed Jan 5 10:14:33 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0313A6C17 for ; Wed, 5 Jan 2011 10:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3dvXP5iznCW for ; Wed, 5 Jan 2011 10:14:32 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3ECC03A681C for ; Wed, 5 Jan 2011 10:14:32 -0800 (PST) Received: from [192.1.255.181] (port=50400 helo=col-raltmann-l1.nira.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PaXuY-0000MG-Tv; Wed, 05 Jan 2011 13:16:39 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <9D11F264-564A-49E2-8E1B-E5290A1FCC0E@bbn.com> Date: Wed, 5 Jan 2011 13:16:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201101031724.p03HOVxW029784@sj-core-5.cisco.com> <201101032006.p03K69H4010150@sj-core-5.cisco.com> <8B0A9FCBB9832F43971E38010638454F03F50ED4FE@SISPE7MB1.commscope.com> <9D11F264-564A-49E2-8E1B-E5290A1FCC0E@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1082) Cc: geopriv@ietf.org Subject: Re: [Geopriv] Consensus call: DHCP option numbers X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 18:14:33 -0000 I have reviewed the changes in Bernard's draft text, and they look good = to me. --Richard=20 On Jan 5, 2011, at 1:13 PM, Richard L. Barnes wrote: > Dear working group, >=20 > In order to get some sort of gauge of consensus, please take a look at = Bernard's draft document and indicate whether these changes are OK with = you. >=20 > A diff can be found here: > >=20 > Please send responses to the list no later than Wednesday, 12 Jan = 2011. >=20 > Thanks, > --Richard >=20 >=20 >=20 >=20 > On Jan 5, 2011, at 1:03 AM, Bernard Aboba wrote: >=20 >> I've gone through the document and made changes to define a new = DHCPv4 option.=20 >>=20 >> A strawman is available here: >> = http://www.drizzle.com/~aboba/GEOPRIV/draft-ietf-geopriv-rfc3825bis-15.txt= >>=20 >>=20 >> -----Original Message----- >> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=20 >> Sent: Tuesday, January 04, 2011 4:01 PM >> To: James M. Polk; Bernard Aboba; geopriv@ietf.org >> Cc: rdroms@cisco.com >> Subject: RE: [Geopriv] Options for Resolution of DISCUSS comments on = RFC 3825bis >>=20 >> It looks like we should take another pass at this in the working = group. >>=20 >> Let's not change too much in the process in the interests of getting = this done quickly. >>=20 >> More inline... >>=20 >> On 2011-01-04 at 07:06:07, James M. Polk wrote: >>>> [BA] A DHCP client could indicate its preference based on option = code >>> no? >>>=20 >>> [JMP] yes, but including either Option code or include both >>=20 >> [MT] Option 55 (and equivalent DHCPv6) would be the way this is done, = the client can list its preferred option number. A note on how this = works for versioning purposes would be nice. >>=20 >> [MT] Keep in mind that advice in RFC 4776 suggests that a server = should never send this information unsolicited. If we maintain that = advice, then there should be no problem. =20 >>=20 >>> [JMP] I believe DHCP clients that receive Options they don't >>> understand simply ignore them, so if a client receives an Option = 500, >>> it should be ignored and therefore not cause backwards compatibility >>> issues, right? >>=20 >> [MT] That's the way it works. A lot of DHCP servers provide Options = that aren't used. >>=20 >>> That said - this RFC-to-be needs to state somewhere something like: >>>=20 >>> If a client requests only Option 123 [RFC3825], the server SHOULD >>> NOT >>> transmit an Option 500 (defined within this document) because it >>> could >>> lead to interoperability issues. >>=20 >> [MT] The advice on "don't provide unless explicitly requested" should = be sufficient. >>=20 >>>>>> It seems to me that if both options were sent, the new option >>> would >>>>>> need to be version 1. >>>>>=20 >>>>> Specifically, I believe the two Options (123 and 500) would be >>> enough >>>>> of a separation. Pragmatically, for readers, I believe stating = that >>>>> Option 500 is version 1 would make more sense to make sure to >>> remove >>>>> another level of confusion that could occur. >>>>=20 >>>> [BA] Right. So we could keep the "Ver" field, but state that the >>> field >>>> MUST be 1 for Option 500. >>>=20 >>> [JMP] I think introducing the VER field in Option 500 creates the >>> ability for a future version 2, which is probably a good thing, so I >>> think it ought to stay. >>=20 >> [MT] Sounds reasonable. The hypothetical Option 500 could set "Ver" = to 0, but that's not really going to help. >>=20 >>=20 >>>> [BA] Agree that modifying/removing "version 0" material would = require >>>> the document to go back to the WG. Also agree that we should keep >>>> (and leave alone) the version 1 material. >>>=20 >>> [JMP] agreed >>=20 >> [MT] Works for me. >>=20 >>>> As for pointing normatively to RFC 3825, there seems to be some >>> material >>>> in RFC 3825bis that attempts to "clarify" RFC 3825. So it seems = like >>> we have >>>> the following choices: >>>>=20 >>>> a. Have RFC 3825bis define both Options 123 (IPv4 only) and Option >>>> 500 (IPv4 and IPv6). >>>> In this case, RFC 3825bis would "Obsolete: RFC 3825". >>>>=20 >>>> b. Have RFC 3825bis define only Option 500 (IPv4 and IPv6). >>>> In this case, RFC 3825bis might "Update: RFC 3825" (or maybe not). >>>=20 >>> [JMP] I think you have an option 'b' and 'c' in your above option >>> 'b.'. The difference being whether or not you have 3825bis update >>> 3825 (new option b), or leave it alone (which becomes option c). >>>=20 >>> IMO - within this context, the new option b is the one to go with, >>> because of the clarifying text >>=20 >> [MT] I'd prefer that too. No point in discarding all that work that = we've done in clarifying everything. >>=20 >>>> Sep 2009 Submit an draft for DHCP geodetic location to the IESG for >>>> publication as PS to obsolete 3825 >>>=20 >>> [JMP] I agree as well, and this is a bit of a sticking point >>=20 >> [MT] I can't see this being a major obstacle if we decide that this = is the right way to proceed. >>=20 >>=20 >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From Martin.Thomson@andrew.com Wed Jan 5 14:10:18 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3ABA3A6D02 for ; Wed, 5 Jan 2011 14:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPUQjoJ7pNaS for ; Wed, 5 Jan 2011 14:10:17 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 687873A6BB4 for ; Wed, 5 Jan 2011 14:10:17 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:6600 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S527279Ab1AEWMY (ORCPT ); Wed, 5 Jan 2011 16:12:24 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Wed, 5 Jan 2011 16:12:23 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 6 Jan 2011 06:12:21 +0800 From: "Thomson, Martin" To: "Richard L. Barnes" Date: Thu, 6 Jan 2011 06:12:17 +0800 Thread-Topic: [Geopriv] Consensus call: DHCP option numbers Thread-Index: AcutBMvBkZCS2H8NScy8IBOsLPZ0zwAIKheA Message-ID: <8B0A9FCBB9832F43971E38010638454F03F50ED650@SISPE7MB1.commscope.com> References: <201101031724.p03HOVxW029784@sj-core-5.cisco.com> <201101032006.p03K69H4010150@sj-core-5.cisco.com> <8B0A9FCBB9832F43971E38010638454F03F50ED4FE@SISPE7MB1.commscope.com> <9D11F264-564A-49E2-8E1B-E5290A1FCC0E@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "geopriv@ietf.org" Subject: Re: [Geopriv] Consensus call: DHCP option numbers X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 22:10:19 -0000 SSBoYXZlIGFsc28gcmV2aWV3ZWQgdGhlIHByb3Bvc2VkIGNoYW5nZXMuICBUaGV5IGxvb2sgZ29v ZC4NCg0KT3V0c3RhbmRpbmcgam9iIEJlcm5hcmQuDQoNCkNoZWVycywNCk1hcnRpbg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZ2VvcHJpdi1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86Z2VvcHJpdi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmljaGFyZCBMLiBC YXJuZXMNClNlbnQ6IFRodXJzZGF5LCA2IEphbnVhcnkgMjAxMSA1OjE3IEFNDQpUbzogUmljaGFy ZCBMLiBCYXJuZXMNCkNjOiBnZW9wcml2QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0dlb3ByaXZd IENvbnNlbnN1cyBjYWxsOiBESENQIG9wdGlvbiBudW1iZXJzDQoNCjxoYXQgdHlwZT0iaW5kaXZp ZHVhbCIvPg0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhlIGNoYW5nZXMgaW4gQmVybmFyZCdzIGRyYWZ0 IHRleHQsIGFuZCB0aGV5IGxvb2sgZ29vZCB0byBtZS4NCi0tUmljaGFyZCANCg0KDQoNCk9uIEph biA1LCAyMDExLCBhdCAxOjEzIFBNLCBSaWNoYXJkIEwuIEJhcm5lcyB3cm90ZToNCg0KPiBEZWFy IHdvcmtpbmcgZ3JvdXAsDQo+IA0KPiBJbiBvcmRlciB0byBnZXQgc29tZSBzb3J0IG9mIGdhdWdl IG9mIGNvbnNlbnN1cywgcGxlYXNlIHRha2UgYSBsb29rIGF0IEJlcm5hcmQncyBkcmFmdCBkb2N1 bWVudCBhbmQgaW5kaWNhdGUgd2hldGhlciB0aGVzZSBjaGFuZ2VzIGFyZSBPSyB3aXRoIHlvdS4N Cj4gDQo+IEEgZGlmZiBjYW4gYmUgZm91bmQgaGVyZToNCj4gPGh0dHA6Ly9nb28uZ2wvRU4xZW0+ DQo+IA0KPiBQbGVhc2Ugc2VuZCByZXNwb25zZXMgdG8gdGhlIGxpc3Qgbm8gbGF0ZXIgdGhhbiBX ZWRuZXNkYXksIDEyIEphbiAyMDExLg0KPiANCj4gVGhhbmtzLA0KPiAtLVJpY2hhcmQNCj4gDQo+ IA0KPiANCj4gDQo+IE9uIEphbiA1LCAyMDExLCBhdCAxOjAzIEFNLCBCZXJuYXJkIEFib2JhIHdy b3RlOg0KPiANCj4+IEkndmUgZ29uZSB0aHJvdWdoIHRoZSBkb2N1bWVudCBhbmQgbWFkZSBjaGFu Z2VzIHRvIGRlZmluZSBhIG5ldyBESENQdjQgb3B0aW9uLiANCj4+IA0KPj4gQSBzdHJhd21hbiBp cyBhdmFpbGFibGUgaGVyZToNCj4+IGh0dHA6Ly93d3cuZHJpenpsZS5jb20vfmFib2JhL0dFT1BS SVYvZHJhZnQtaWV0Zi1nZW9wcml2LXJmYzM4MjViaXMtMTUudHh0DQo+PiANCj4+IA0KPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFRob21zb24sIE1hcnRpbiBbbWFpbHRv Ok1hcnRpbi5UaG9tc29uQGFuZHJldy5jb21dIA0KPj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAw NCwgMjAxMSA0OjAxIFBNDQo+PiBUbzogSmFtZXMgTS4gUG9sazsgQmVybmFyZCBBYm9iYTsgZ2Vv cHJpdkBpZXRmLm9yZw0KPj4gQ2M6IHJkcm9tc0BjaXNjby5jb20NCj4+IFN1YmplY3Q6IFJFOiBb R2VvcHJpdl0gT3B0aW9ucyBmb3IgUmVzb2x1dGlvbiBvZiBESVNDVVNTIGNvbW1lbnRzIG9uIFJG QyAzODI1YmlzDQo+PiANCj4+IEl0IGxvb2tzIGxpa2Ugd2Ugc2hvdWxkIHRha2UgYW5vdGhlciBw YXNzIGF0IHRoaXMgaW4gdGhlIHdvcmtpbmcgZ3JvdXAuDQo+PiANCj4+IExldCdzIG5vdCBjaGFu Z2UgdG9vIG11Y2ggaW4gdGhlIHByb2Nlc3MgaW4gdGhlIGludGVyZXN0cyBvZiBnZXR0aW5nIHRo aXMgZG9uZSBxdWlja2x5Lg0KPj4gDQo+PiBNb3JlIGlubGluZS4uLg0KPj4gDQo+PiBPbiAyMDEx LTAxLTA0IGF0IDA3OjA2OjA3LCBKYW1lcyBNLiBQb2xrIHdyb3RlOg0KPj4+PiBbQkFdIEEgREhD UCBjbGllbnQgY291bGQgaW5kaWNhdGUgaXRzIHByZWZlcmVuY2UgYmFzZWQgb24gb3B0aW9uIGNv ZGUNCj4+PiBubz8NCj4+PiANCj4+PiBbSk1QXSB5ZXMsIGJ1dCBpbmNsdWRpbmcgZWl0aGVyIE9w dGlvbiBjb2RlIG9yIGluY2x1ZGUgYm90aA0KPj4gDQo+PiBbTVRdIE9wdGlvbiA1NSAoYW5kIGVx dWl2YWxlbnQgREhDUHY2KSB3b3VsZCBiZSB0aGUgd2F5IHRoaXMgaXMgZG9uZSwgdGhlIGNsaWVu dCBjYW4gbGlzdCBpdHMgcHJlZmVycmVkIG9wdGlvbiBudW1iZXIuICBBIG5vdGUgb24gaG93IHRo aXMgd29ya3MgZm9yIHZlcnNpb25pbmcgcHVycG9zZXMgd291bGQgYmUgbmljZS4NCj4+IA0KPj4g W01UXSBLZWVwIGluIG1pbmQgdGhhdCBhZHZpY2UgaW4gUkZDIDQ3NzYgc3VnZ2VzdHMgdGhhdCBh IHNlcnZlciBzaG91bGQgbmV2ZXIgc2VuZCB0aGlzIGluZm9ybWF0aW9uIHVuc29saWNpdGVkLiAg SWYgd2UgbWFpbnRhaW4gdGhhdCBhZHZpY2UsIHRoZW4gdGhlcmUgc2hvdWxkIGJlIG5vIHByb2Js ZW0uICANCj4+IA0KPj4+IFtKTVBdIEkgYmVsaWV2ZSBESENQIGNsaWVudHMgdGhhdCByZWNlaXZl IE9wdGlvbnMgdGhleSBkb24ndA0KPj4+IHVuZGVyc3RhbmQgc2ltcGx5IGlnbm9yZSB0aGVtLCBz byBpZiBhIGNsaWVudCByZWNlaXZlcyBhbiBPcHRpb24gNTAwLA0KPj4+IGl0IHNob3VsZCBiZSBp Z25vcmVkIGFuZCB0aGVyZWZvcmUgbm90IGNhdXNlIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5DQo+ Pj4gaXNzdWVzLCByaWdodD8NCj4+IA0KPj4gW01UXSAgVGhhdCdzIHRoZSB3YXkgaXQgd29ya3Mu ICBBIGxvdCBvZiBESENQIHNlcnZlcnMgcHJvdmlkZSBPcHRpb25zIHRoYXQgYXJlbid0IHVzZWQu DQo+PiANCj4+PiBUaGF0IHNhaWQgLSB0aGlzIFJGQy10by1iZSBuZWVkcyB0byBzdGF0ZSBzb21l d2hlcmUgc29tZXRoaW5nIGxpa2U6DQo+Pj4gDQo+Pj4gICBJZiBhIGNsaWVudCByZXF1ZXN0cyBv bmx5IE9wdGlvbiAxMjMgW1JGQzM4MjVdLCB0aGUgc2VydmVyIFNIT1VMRA0KPj4+IE5PVA0KPj4+ ICAgdHJhbnNtaXQgYW4gT3B0aW9uIDUwMCAoZGVmaW5lZCB3aXRoaW4gdGhpcyBkb2N1bWVudCkg YmVjYXVzZSBpdA0KPj4+IGNvdWxkDQo+Pj4gICBsZWFkIHRvIGludGVyb3BlcmFiaWxpdHkgaXNz dWVzLg0KPj4gDQo+PiBbTVRdIFRoZSBhZHZpY2Ugb24gImRvbid0IHByb3ZpZGUgdW5sZXNzIGV4 cGxpY2l0bHkgcmVxdWVzdGVkIiBzaG91bGQgYmUgc3VmZmljaWVudC4NCj4+IA0KPj4+Pj4+IEl0 IHNlZW1zIHRvIG1lIHRoYXQgaWYgYm90aCBvcHRpb25zIHdlcmUgc2VudCwgdGhlIG5ldyBvcHRp b24NCj4+PiB3b3VsZA0KPj4+Pj4+IG5lZWQgdG8gYmUgdmVyc2lvbiAxLg0KPj4+Pj4gDQo+Pj4+ PiBTcGVjaWZpY2FsbHksIEkgYmVsaWV2ZSB0aGUgdHdvIE9wdGlvbnMgKDEyMyBhbmQgNTAwKSB3 b3VsZCBiZQ0KPj4+IGVub3VnaA0KPj4+Pj4gb2YgYSBzZXBhcmF0aW9uLiBQcmFnbWF0aWNhbGx5 LCBmb3IgcmVhZGVycywgSSBiZWxpZXZlIHN0YXRpbmcgdGhhdA0KPj4+Pj4gT3B0aW9uIDUwMCBp cyB2ZXJzaW9uIDEgd291bGQgbWFrZSBtb3JlIHNlbnNlIHRvIG1ha2Ugc3VyZSB0bw0KPj4+IHJl bW92ZQ0KPj4+Pj4gYW5vdGhlciBsZXZlbCBvZiBjb25mdXNpb24gdGhhdCBjb3VsZCBvY2N1ci4N Cj4+Pj4gDQo+Pj4+IFtCQV0gUmlnaHQuICBTbyB3ZSBjb3VsZCBrZWVwIHRoZSAiVmVyIiBmaWVs ZCwgYnV0IHN0YXRlIHRoYXQgdGhlDQo+Pj4gZmllbGQNCj4+Pj4gTVVTVCBiZSAxIGZvciBPcHRp b24gNTAwLg0KPj4+IA0KPj4+IFtKTVBdIEkgdGhpbmsgaW50cm9kdWNpbmcgdGhlIFZFUiBmaWVs ZCBpbiBPcHRpb24gNTAwIGNyZWF0ZXMgdGhlDQo+Pj4gYWJpbGl0eSBmb3IgYSBmdXR1cmUgdmVy c2lvbiAyLCB3aGljaCBpcyBwcm9iYWJseSBhIGdvb2QgdGhpbmcsIHNvIEkNCj4+PiB0aGluayBp dCBvdWdodCB0byBzdGF5Lg0KPj4gDQo+PiBbTVRdIFNvdW5kcyByZWFzb25hYmxlLiAgVGhlIGh5 cG90aGV0aWNhbCBPcHRpb24gNTAwIGNvdWxkIHNldCAiVmVyIiB0byAwLCBidXQgdGhhdCdzIG5v dCByZWFsbHkgZ29pbmcgdG8gaGVscC4NCj4+IA0KPj4gDQo+Pj4+IFtCQV0gQWdyZWUgdGhhdCBt b2RpZnlpbmcvcmVtb3ZpbmcgInZlcnNpb24gMCIgbWF0ZXJpYWwgd291bGQgcmVxdWlyZQ0KPj4+ PiB0aGUgZG9jdW1lbnQgdG8gZ28gYmFjayB0byB0aGUgV0cuICAgQWxzbyBhZ3JlZSB0aGF0IHdl IHNob3VsZCBrZWVwDQo+Pj4+IChhbmQgbGVhdmUgYWxvbmUpIHRoZSB2ZXJzaW9uIDEgbWF0ZXJp YWwuDQo+Pj4gDQo+Pj4gW0pNUF0gYWdyZWVkDQo+PiANCj4+IFtNVF0gV29ya3MgZm9yIG1lLg0K Pj4gDQo+Pj4+IEFzIGZvciBwb2ludGluZyBub3JtYXRpdmVseSB0byBSRkMgMzgyNSwgdGhlcmUg c2VlbXMgdG8gYmUgc29tZQ0KPj4+IG1hdGVyaWFsDQo+Pj4+IGluIFJGQyAzODI1YmlzIHRoYXQg YXR0ZW1wdHMgdG8gImNsYXJpZnkiIFJGQyAzODI1LiAgIFNvIGl0IHNlZW1zIGxpa2UNCj4+PiB3 ZSBoYXZlDQo+Pj4+IHRoZSBmb2xsb3dpbmcgY2hvaWNlczoNCj4+Pj4gDQo+Pj4+IGEuICBIYXZl IFJGQyAzODI1YmlzIGRlZmluZSBib3RoIE9wdGlvbnMgMTIzIChJUHY0IG9ubHkpIGFuZCBPcHRp b24NCj4+Pj4gNTAwIChJUHY0IGFuZCBJUHY2KS4NCj4+Pj4gSW4gdGhpcyBjYXNlLCBSRkMgMzgy NWJpcyB3b3VsZCAiT2Jzb2xldGU6IFJGQyAzODI1Ii4NCj4+Pj4gDQo+Pj4+IGIuIEhhdmUgUkZD IDM4MjViaXMgZGVmaW5lIG9ubHkgT3B0aW9uIDUwMCAoSVB2NCBhbmQgSVB2NikuDQo+Pj4+IElu IHRoaXMgY2FzZSwgUkZDIDM4MjViaXMgbWlnaHQgIlVwZGF0ZTogUkZDIDM4MjUiIChvciBtYXli ZSBub3QpLg0KPj4+IA0KPj4+IFtKTVBdIEkgdGhpbmsgeW91IGhhdmUgYW4gb3B0aW9uICdiJyBh bmQgJ2MnIGluIHlvdXIgYWJvdmUgb3B0aW9uDQo+Pj4gJ2IuJy4gVGhlIGRpZmZlcmVuY2UgYmVp bmcgd2hldGhlciBvciBub3QgeW91IGhhdmUgMzgyNWJpcyB1cGRhdGUNCj4+PiAzODI1IChuZXcg b3B0aW9uIGIpLCBvciBsZWF2ZSBpdCBhbG9uZSAod2hpY2ggYmVjb21lcyBvcHRpb24gYykuDQo+ Pj4gDQo+Pj4gSU1PIC0gd2l0aGluIHRoaXMgY29udGV4dCwgdGhlIG5ldyBvcHRpb24gYiBpcyB0 aGUgb25lIHRvIGdvIHdpdGgsDQo+Pj4gYmVjYXVzZSBvZiB0aGUgY2xhcmlmeWluZyB0ZXh0DQo+ PiANCj4+IFtNVF0gIEknZCBwcmVmZXIgdGhhdCB0b28uICBObyBwb2ludCBpbiBkaXNjYXJkaW5n IGFsbCB0aGF0IHdvcmsgdGhhdCB3ZSd2ZSBkb25lIGluIGNsYXJpZnlpbmcgZXZlcnl0aGluZy4N Cj4+IA0KPj4+PiBTZXAgMjAwOSBTdWJtaXQgYW4gZHJhZnQgZm9yIERIQ1AgZ2VvZGV0aWMgbG9j YXRpb24gdG8gdGhlIElFU0cgZm9yDQo+Pj4+IHB1YmxpY2F0aW9uIGFzIFBTIHRvIG9ic29sZXRl IDM4MjUNCj4+PiANCj4+PiBbSk1QXSBJIGFncmVlIGFzIHdlbGwsIGFuZCB0aGlzIGlzIGEgYml0 IG9mIGEgc3RpY2tpbmcgcG9pbnQNCj4+IA0KPj4gW01UXSBJIGNhbid0IHNlZSB0aGlzIGJlaW5n IGEgbWFqb3Igb2JzdGFjbGUgaWYgd2UgZGVjaWRlIHRoYXQgdGhpcyBpcyB0aGUgcmlnaHQgd2F5 IHRvIHByb2NlZWQuDQo+PiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IEdlb3ByaXYgbWFpbGluZyBsaXN0DQo+PiBHZW9wcml2QGll dGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dlb3ByaXYN Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IEdlb3ByaXYgbWFpbGluZyBsaXN0DQo+IEdlb3ByaXZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9wcml2DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpHZW9wcml2IG1haWxpbmcgbGlzdA0KR2VvcHJp dkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9wcml2 DQo= From Martin.Thomson@andrew.com Thu Jan 6 14:35:06 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D51F93A6F67 for ; Thu, 6 Jan 2011 14:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55GvKqXfGJeP for ; Thu, 6 Jan 2011 14:35:04 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 2E4163A6F63 for ; Thu, 6 Jan 2011 14:35:03 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:50245 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S505589Ab1AFWhJ (ORCPT ); Thu, 6 Jan 2011 16:37:09 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 6 Jan 2011 16:37:09 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 7 Jan 2011 06:37:07 +0800 From: "Thomson, Martin" To: "geopriv@ietf.org" Date: Fri, 7 Jan 2011 06:37:05 +0800 Thread-Topic: Civic extensions draft Thread-Index: AcudpQKey19cne7xRxejazlHvugCzQQTHV+Q Message-ID: <8B0A9FCBB9832F43971E38010638454F03F5258CE0@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03F34FB187@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F34FB187@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Geopriv] Civic extensions draft X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 22:35:06 -0000 SGF2ZSBmb2xrcyBoYWQgdGltZSB0byBjb25zaWRlciB0aGVpciBvcGluaW9ucyBvbiB0aGlzIGRy YWZ0Pw0KDQpUaGVyZSBpcyBhIGxpdHRsZSBwcmVzc3VyZSBmcm9tIHRoZSBMT0MgZ3JvdXAgaW4g dGhlIE9NQSB0byBnZXQgdGhpcyBpc3N1ZSBjbG9zZWQuICBUaGV5IGhhdmUgZXh0ZW5zaW9ucyB0 aGF0IHRoZXkgd2FudCB0byBkZWZpbmUuICBUaGV5IGFscmVhZHkgdXNlIHRoZSBYTUwgZm9ybWF0 IGluIExPQ1NJUDsgdGhleSBhbHNvIGludGVuZCB0byB1c2UgUkZDIDQ3NzYgLSBvciBzb21ldGhp bmcgdmVyeSBjbG9zZSB0byBpdCAtIGluIExQUGUuDQoNCi0tTWFydGluDQoNCk9uIDIwMTAtMTIt MTcgYXQgMTU6NDM6NTUsIFRob21zb24sIE1hcnRpbiB3cm90ZToNCj4gSSd2ZSBqdXN0IHBvc3Rl ZCBhIHJldmlzaW9uIHRvIHRoZSAtbG9jYWwtY2l2aWMgZHJhZnQgdGhhdCBjYXB0dXJlcw0KPiBz b21lIG9mIHRoZSBwcm9ncmVzcyBpbiB0aGUgY2l2aWMgYWRkcmVzcyBleHRlbnNpb24gZGlzY3Vz c2lvbnMgd2UndmUNCj4gYmVlbiBoYXZpbmcuDQo+IA0KPiAgICBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC13aW50ZXJib3R0b20tZ2VvcHJpdi1sb2NhbC1jaXZpYy0wNA0KPiANCj4g VGhlIGNoYW5nZXMgYXJlIGJhc2VkIG9uIHRoZSBkaXNjdXNzaW9ucyB0aGF0DQo+IEJyaWFuLCBS aWNoYXJkLCBKYW1lc1cgYW5kIEkgaGF2ZSBoYWQgYm90aCBvbiBhbmQgb2ZmIGxpc3QuDQo+IA0K PiBUaGlzIGlzbid0IHRoZSBlbmQgb2YgdGhlIGRpc2N1c3Npb24uICBXZSBoYXZlbid0IGNvbXBs ZXRlbHkgZmluaXNoZWQNCj4gaXJvbmluZyBvdXQgYWxsIHRoZSBkZXRhaWxzLCBidXQgd2UndmUg bWFkZSBzb21lIGZhaXJseSBzaWduaWZpY2FudA0KPiBwcm9ncmVzcy4NCj4gDQo+IFRoZSBoaWdo IHBvaW50czoNCj4gDQo+ICAtIHByb2JsZW06IHRoZXJlIGFyZSB0d28gZm9ybWF0cywgYW5kIGN1 cnJlbnRseSB0d28gcGxhY2VzIHRoYXQNCj4gZXh0ZW5zaW9ucyB0byB0aG9zZSBmb3JtYXRzIGNh biBvcmlnaW5hdGUNCj4gDQo+ICAtIHNvbHV0aW9uOiB0aGUgZHJhZnQgbWFrZXMgdGhlIFhNTCBm b3JtYXQgdGhlIG9ubHkgcGxhY2UgYW4gZXh0ZW5zaW9uDQo+IGNhbiBvcmlnaW5hdGUNCj4gDQo+ ICAtIGNvbnNlcXVlbmNlOiBvbmUgZmluYWwgQ0F0eXBlIGlzIGRlZmluZWQgZm9yIGNhcnJ5aW5n IGFuIFhNTC0NCj4gb3JpZ2luYXRpbmcgZXh0ZW5zaW9uDQo+IA0KPiAgLSBjb25zZXF1ZW5jZTog dGhlIENBdHlwZSByZWdpc3RyeSBpcyByZXZpc2VkIHRvIHJlZmxlY3QgdGhpcw0KPiANCj4gDQo+ IEkgdGhpbmsgdGhhdCB0aGlzIGlzIHNpbXBsZSwgcHJhZ21hdGljIGFuZCBiYWNrd2FyZCBjb21w YXRpYmxlLg0KPiANCj4gLS1NYXJ0aW4NCj4gDQo+IHAucy4gT24gbGVhdmUgdW50aWwgSmFudWFy eS4gIEFwb2xvZ2llcyBpZiByZXNwb25zZXMgYXJlIGEgbGl0dGxlIHNsb3cuDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEdlb3ByaXYgbWFpbGlu ZyBsaXN0DQo+IEdlb3ByaXZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9nZW9wcml2DQoNCg0K From jari.urpalainen@nokia.com Tue Jan 11 22:27:31 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B72C63A698F for ; Tue, 11 Jan 2011 22:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdxdwiIz+FG3 for ; Tue, 11 Jan 2011 22:27:30 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id C96873A67A3 for ; Tue, 11 Jan 2011 22:27:29 -0800 (PST) Received: from [172.21.21.80] (helruo-dhcp02180.ntc.nokia.com [172.21.21.80]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0C6Tlu3014235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Jan 2011 08:29:47 +0200 From: jari urpalainen To: geopriv@ietf.org Content-Type: text/plain; charset="UTF-8" Date: Wed, 12 Jan 2011 08:29:53 +0200 Message-ID: <1294813793.19168.211.camel@urpalain-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Nokia-AV: Clean Subject: [Geopriv] empty conditions element in common policy (rfc4745) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 06:27:32 -0000 Hi ! A clarification question: an empty conditions element without any child elements evaluates to FALSE or TRUE ? Section 10.1 says: "A rule matches if all conditions contained as child elements in the element of a rule evaluate to TRUE", which imo implies FALSE for the "empty" case. The schema allows "empty" , and e.g. not understood conditions evaluate to FALSE. My personal programmatic interpretation goes for FALSE, but what's the correct one ? br, Jari From acooper@cdt.org Wed Jan 12 06:15:48 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F8E28C0EE for ; Wed, 12 Jan 2011 06:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajYFDfJLGmXQ for ; Wed, 12 Jan 2011 06:15:47 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 4794A28C0EF for ; Wed, 12 Jan 2011 06:15:47 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for geopriv@ietf.org; Wed, 12 Jan 2011 09:18:05 -0500 Message-Id: <020BBF4F-8D14-4EC1-831D-C6246D410045@cdt.org> From: Alissa Cooper To: geopriv@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 12 Jan 2011 14:18:02 +0000 X-Mailer: Apple Mail (2.936) Subject: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 14:15:48 -0000 Now that we have a milestone to "submit recommendations for LIS discovery conducted by hosts behind residential gateways as Informational," I'd like to call for WG adoption of draft-thomson- geopriv-res-gw-lis-discovery-04. Please respond to the list by January 19, 2011 about adopting this document as a WG item. Thanks, Alissa From rbarnes@bbn.com Wed Jan 12 07:11:45 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD70128C11C for ; Wed, 12 Jan 2011 07:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuDQe2XeQRjt for ; Wed, 12 Jan 2011 07:11:45 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 0047E28C107 for ; Wed, 12 Jan 2011 07:11:44 -0800 (PST) Received: from [128.89.254.26] (port=49400 helo=[10.45.1.166]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pd2Oi-000Ojf-A8; Wed, 12 Jan 2011 10:14:04 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <1294813793.19168.211.camel@urpalain-desktop> Date: Wed, 12 Jan 2011 10:14:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <576032AB-A98A-4BB7-AC42-914B5911EBF4@bbn.com> References: <1294813793.19168.211.camel@urpalain-desktop> To: jari urpalainen X-Mailer: Apple Mail (2.1082) Cc: geopriv@ietf.org Subject: Re: [Geopriv] empty conditions element in common policy (rfc4745) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 15:11:45 -0000 Good question! Here's my opinion, by no means authoritative: Short answer: TRUE. =20 Mathematical answer:=20 As one of my university math professors used to say, "Anything is true = for every member of the empty set". What the element does = logically is specify a set of propositions for which the conjunction = (AND) must be true in order to grant permission. So ... is the same as the formal proposition P1 && P2 && ... Then you can note that TRUE && X =3D=3D X for any X, in which case the = above becomes: TRUE && P1 && P2 && ... So when you take all the individual propositions out of the = element, you're left with: TRUE Linguistic answer: The element specifies "conditions" on the grant of = permission described in the elements, in the = sense that it limits the scope of that permission. So a permission with = an empty element grants "unconditional" access. Practical answer: A rule with a element that always evaluates to FALSE would = be useless. You might as well delete it. (If you want a way to = temporarily invalidate a rule, you could, for instance, insert a = validity time in the past.) --Richard On Jan 12, 2011, at 1:29 AM, jari urpalainen wrote: > Hi ! >=20 > A clarification question: an empty conditions element without any = child > elements evaluates to FALSE or TRUE ? >=20 > Section 10.1 says: "A rule matches if all conditions contained as = child > elements in the element of a rule evaluate to TRUE", = which > imo implies FALSE for the "empty" case. The schema allows "empty" > , and e.g. not understood conditions evaluate to FALSE. = My > personal programmatic interpretation goes for FALSE, but what's the > correct one ? >=20 > br, Jari >=20 >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From Internet-Drafts@ietf.org Wed Jan 12 07:15:02 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED12128C146; Wed, 12 Jan 2011 07:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZ7Bwh+s0vd0; Wed, 12 Jan 2011 07:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38E9D28C12E; Wed, 12 Jan 2011 07:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110112151502.2666.30845.idtracker@localhost> Date: Wed, 12 Jan 2011 07:15:02 -0800 Cc: geopriv@ietf.org Subject: [Geopriv] I-D Action:draft-ietf-geopriv-policy-uri-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 15:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Geographic Location/Privacy Working Group of the IETF. Title : Location Configuration Extensions for Policy Management Author(s) : R. Barnes, et al. Filename : draft-ietf-geopriv-policy-uri-00.txt Pages : 16 Date : 2011-01-12 Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI, so that the host can view or set these rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-uri-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-geopriv-policy-uri-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-12070416.I-D@ietf.org> --NextPart-- From Martin.Dawson@andrew.com Wed Jan 12 16:04:48 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BF7F3A6784 for ; Wed, 12 Jan 2011 16:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsqdKIJSEaqv for ; Wed, 12 Jan 2011 16:04:47 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 1632E3A657C for ; Wed, 12 Jan 2011 16:04:47 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:29559 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S534464Ab1AMAHH convert rfc822-to-8bit (ORCPT ); Wed, 12 Jan 2011 18:07:07 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Wed, 12 Jan 2011 18:06:25 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 13 Jan 2011 08:06:23 +0800 From: "Dawson, Martin" To: Alissa Cooper , "geopriv@ietf.org" Date: Thu, 13 Jan 2011 08:06:18 +0800 Thread-Topic: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04 Thread-Index: AcuyY74lZAWfd23rSuudX6SRLfX2JgAUejbQ Message-ID: <8B0A9FCBB9832F43971E38010638454F03F525932D@SISPE7MB1.commscope.com> References: <020BBF4F-8D14-4EC1-831D-C6246D410045@cdt.org> In-Reply-To: <020BBF4F-8D14-4EC1-831D-C6246D410045@cdt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Subject: Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 00:04:48 -0000 I support its adoption as a WG item. Best Regards, Martin Dawson -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Alissa Cooper Sent: Thursday, 13 January 2011 1:18 AM To: geopriv@ietf.org Subject: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04 Now that we have a milestone to "submit recommendations for LIS discovery conducted by hosts behind residential gateways as Informational," I'd like to call for WG adoption of draft-thomson- geopriv-res-gw-lis-discovery-04. Please respond to the list by January 19, 2011 about adopting this document as a WG item. Thanks, Alissa _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv From James.Winterbottom@andrew.com Wed Jan 12 16:54:03 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CFBD3A6778 for ; Wed, 12 Jan 2011 16:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbtTvEkZK3aJ for ; Wed, 12 Jan 2011 16:54:02 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 266A63A65A6 for ; Wed, 12 Jan 2011 16:54:02 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:48731 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S41238864Ab1AMA4X convert rfc822-to-8bit (ORCPT ); Wed, 12 Jan 2011 18:56:23 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Wed, 12 Jan 2011 18:55:40 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 13 Jan 2011 08:55:37 +0800 From: "Winterbottom, James" To: Alissa Cooper , "geopriv@ietf.org" Date: Thu, 13 Jan 2011 08:55:25 +0800 Thread-Topic: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04 Thread-Index: AcuyY74lZAWfd23rSuudX6SRLfX2JgAWNH/t Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120F437CCB7@SISPE7MB1.commscope.com> References: <020BBF4F-8D14-4EC1-831D-C6246D410045@cdt.org> In-Reply-To: <020BBF4F-8D14-4EC1-831D-C6246D410045@cdt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 00:54:03 -0000 I support the adoption of this document. ________________________________________ From: geopriv-bounces@ietf.org [geopriv-bounces@ietf.org] On Behalf Of Alissa Cooper [acooper@cdt.org] Sent: Wednesday, January 12, 2011 8:18 AM To: geopriv@ietf.org Subject: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04 Now that we have a milestone to "submit recommendations for LIS discovery conducted by hosts behind residential gateways as Informational," I'd like to call for WG adoption of draft-thomson- geopriv-res-gw-lis-discovery-04. Please respond to the list by January 19, 2011 about adopting this document as a WG item. Thanks, Alissa _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv From rbarnes@bbn.com Wed Jan 12 19:40:30 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 682153A6822 for ; Wed, 12 Jan 2011 19:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92vHkBCHQadK for ; Wed, 12 Jan 2011 19:40:29 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 9A8CF3A67AD for ; Wed, 12 Jan 2011 19:40:29 -0800 (PST) Received: from [128.89.253.126] (port=55666 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PdE5K-0004JL-Am; Wed, 12 Jan 2011 22:42:50 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120F437CCB7@SISPE7MB1.commscope.com> Date: Wed, 12 Jan 2011 22:42:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <020BBF4F-8D14-4EC1-831D-C6246D410045@cdt.org> <5A55A45AE77F5941B18E5457ECAC81880120F437CCB7@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1082) Cc: "geopriv@ietf.org" Subject: Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 03:40:30 -0000 +1 On Jan 12, 2011, at 7:55 PM, Winterbottom, James wrote: > I support the adoption of this document. >=20 > ________________________________________ > From: geopriv-bounces@ietf.org [geopriv-bounces@ietf.org] On Behalf Of = Alissa Cooper [acooper@cdt.org] > Sent: Wednesday, January 12, 2011 8:18 AM > To: geopriv@ietf.org > Subject: [Geopriv] Consensus call: Adoption of = draft-thomson-geopriv-res-gw-lis-discovery-04 >=20 > Now that we have a milestone to "submit recommendations for LIS > discovery conducted by hosts behind residential gateways as > Informational," I'd like to call for WG adoption of draft-thomson- > geopriv-res-gw-lis-discovery-04. Please respond to the list by January > 19, 2011 about adopting this document as a WG item. >=20 > Thanks, > Alissa >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From jari.urpalainen@nokia.com Wed Jan 12 23:32:46 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DA223A69B5 for ; Wed, 12 Jan 2011 23:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQH6lq9bPYUG for ; Wed, 12 Jan 2011 23:32:45 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 982C53A68A8 for ; Wed, 12 Jan 2011 23:32:44 -0800 (PST) Received: from [172.21.21.80] (helruo-dhcp02180.ntc.nokia.com [172.21.21.80]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0D7YqOi030552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jan 2011 09:34:52 +0200 From: Jari Urpalainen To: "ext Richard L. Barnes" In-Reply-To: <576032AB-A98A-4BB7-AC42-914B5911EBF4@bbn.com> References: <1294813793.19168.211.camel@urpalain-desktop> <576032AB-A98A-4BB7-AC42-914B5911EBF4@bbn.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 13 Jan 2011 09:34:49 +0200 Message-ID: <1294904089.23241.87.camel@urpalain-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Nokia-AV: Clean Cc: geopriv@ietf.org Subject: Re: [Geopriv] empty conditions element in common policy (rfc4745) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 07:32:46 -0000 Thanks Richard, On Wed, 2011-01-12 at 10:14 -0500, ext Richard L. Barnes wrote: > Good question! Here's my opinion, by no means authoritative: > for me, you are authoritative enough... > Short answer: TRUE. > agreed, clearly the better option. > Mathematical answer: > As one of my university math professors used to say, "Anything is true for every member of the empty set". What the element does logically is specify a set of propositions for which the conjunction (AND) must be true in order to grant permission. So > ... > is the same as the formal proposition > P1 && P2 && ... > Then you can note that TRUE && X == X for any X, in which case the above becomes: > TRUE && P1 && P2 && ... > So when you take all the individual propositions out of the element, you're left with: > TRUE > ok, i don't recall anymore if my prof tried to teach this sort of math ;-) But a programmatic way, if m means matching: m = TRUE if (P1 != TRUE || P2 != TRUE ...) m = FALSE if (m) And the alternative simpler interpretation: if (P1 == TRUE || P2 == TRUE ...) would lead to no match with empty set. But I'm perfectly fine with the "default" being TRUE. And since the schema also allows to leave out element altogether, this same unconditional TRUE match also applies then, i suppose. > Linguistic answer: > The element specifies "conditions" on the grant of permission described in the elements, in the sense that it limits the scope of that permission. So a permission with an empty element grants "unconditional" access. > > Practical answer: > A rule with a element that always evaluates to FALSE would be useless. You might as well delete it. (If you want a way to temporarily invalidate a rule, you could, for instance, insert a validity time in the past.) > > --Richard > Right, FALSE default would be no-op. TRUE is a simple way of giving default policy which applies always (though it can easily be done e.g. with constraint) I still re-read the spec, and couldn't digest this "self-evident" rule. So after the sentence in section 6: "If all of the expressions evaluate to TRUE, then the rule is applicable to this request." "If there are no expression constraints, i.e. the element is missing or it has no child elements, the rule is also applicable to this request." or something similar. It might be good to add this as errdata since i'm pretty certain this can be seen in iop tests. thanks, Jari From rbarnes@bbn.com Thu Jan 13 07:48:06 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18DEA3A6BB2 for ; Thu, 13 Jan 2011 07:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu3eukfpof9Z for ; Thu, 13 Jan 2011 07:48:05 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 483AF3A6BA8 for ; Thu, 13 Jan 2011 07:48:05 -0800 (PST) Received: from dhcp89-089-064.bbn.com ([128.89.89.64]:55972) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PdPRT-000BV0-Pn; Thu, 13 Jan 2011 10:50:27 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <1294904089.23241.87.camel@urpalain-desktop> Date: Thu, 13 Jan 2011 10:50:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <81A73BF6-4382-41BC-B04C-A4F5C797A47A@bbn.com> References: <1294813793.19168.211.camel@urpalain-desktop> <576032AB-A98A-4BB7-AC42-914B5911EBF4@bbn.com> <1294904089.23241.87.camel@urpalain-desktop> To: Jari Urpalainen X-Mailer: Apple Mail (2.1082) Cc: geopriv@ietf.org Subject: Re: [Geopriv] empty conditions element in common policy (rfc4745) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 15:48:06 -0000 > But a programmatic way, if m means matching: ... Actually, I was thinking of something like the following: bool m =3D true; for (int i=3D0; i or something similar. It might be good to add this as errdata since = i'm > pretty certain this can be seen in iop tests. I'm not familiar enough with the erratum process to say whether this is = appropriate, but I agree that this seems like a good thing to clarify. = It might make sense to write a brief I-D with clarifications to RFC = 4745, especially if there are other interop issues. --Richard From Martin.Thomson@andrew.com Thu Jan 13 13:51:58 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B4913A6BDE for ; Thu, 13 Jan 2011 13:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zj8CRrfmsPWN for ; Thu, 13 Jan 2011 13:51:57 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 90FCE3A687E for ; Thu, 13 Jan 2011 13:51:57 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:16806 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S41278975Ab1AMVyU (ORCPT ); Thu, 13 Jan 2011 15:54:20 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 13 Jan 2011 15:54:20 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 14 Jan 2011 05:54:18 +0800 From: "Thomson, Martin" To: "Richard L. Barnes" , "Winterbottom, James" Date: Fri, 14 Jan 2011 05:54:15 +0800 Thread-Topic: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04 Thread-Index: Acuy0/fK4pcaUSMiSfObpRA9GJ3VPAAmF/QA Message-ID: <8B0A9FCBB9832F43971E38010638454F03F5259471@SISPE7MB1.commscope.com> References: <020BBF4F-8D14-4EC1-831D-C6246D410045@cdt.org> <5A55A45AE77F5941B18E5457ECAC81880120F437CCB7@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "geopriv@ietf.org" Subject: Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 21:51:58 -0000 RGl0dG8uDQoNCk9uIDIwMTEtMDEtMTMgYXQgMTQ6NDI6NDgsIFJpY2hhcmQgTC4gQmFybmVzIHdy b3RlOg0KPiArMQ0KPiANCj4gT24gSmFuIDEyLCAyMDExLCBhdCA3OjU1IFBNLCBXaW50ZXJib3R0 b20sIEphbWVzIHdyb3RlOg0KPiANCj4gPiBJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMg ZG9jdW1lbnQuDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gRnJvbTogZ2VvcHJpdi1ib3VuY2VzQGlldGYub3JnIFtnZW9wcml2LWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBBbGlzc2EgQ29vcGVyIFthY29vcGVyQGNkdC5vcmdd DQo+ID4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDEyLCAyMDExIDg6MTggQU0NCj4gPiBUbzog Z2VvcHJpdkBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFtHZW9wcml2XSBDb25zZW5zdXMgY2FsbDog QWRvcHRpb24gb2YgIGRyYWZ0LXRob21zb24tDQo+IGdlb3ByaXYtcmVzLWd3LWxpcy1kaXNjb3Zl cnktMDQNCj4gPg0KPiA+IE5vdyB0aGF0IHdlIGhhdmUgYSBtaWxlc3RvbmUgdG8gInN1Ym1pdCBy ZWNvbW1lbmRhdGlvbnMgZm9yIExJUw0KPiA+IGRpc2NvdmVyeSBjb25kdWN0ZWQgYnkgaG9zdHMg YmVoaW5kIHJlc2lkZW50aWFsIGdhdGV3YXlzIGFzDQo+ID4gSW5mb3JtYXRpb25hbCwiIEknZCBs aWtlIHRvIGNhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXRob21zb24tDQo+ID4gZ2VvcHJp di1yZXMtZ3ctbGlzLWRpc2NvdmVyeS0wNC4gUGxlYXNlIHJlc3BvbmQgdG8gdGhlIGxpc3QgYnkN Cj4gSmFudWFyeQ0KPiA+IDE5LCAyMDExIGFib3V0IGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQgYXMg YSBXRyBpdGVtLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IEFsaXNzYQ0K From creed@opengeospatial.org Thu Jan 13 17:38:13 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B999A3A65A6 for ; Thu, 13 Jan 2011 17:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGT5bHZOxWf1 for ; Thu, 13 Jan 2011 17:38:13 -0800 (PST) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by core3.amsl.com (Postfix) with ESMTP id 105873A672F for ; Thu, 13 Jan 2011 17:38:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id A06235A117; Thu, 13 Jan 2011 20:40:36 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (mail.opengeospatial.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8s-93OXqVoP; Thu, 13 Jan 2011 20:40:36 -0500 (EST) Received: from mail.opengeospatial.org (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 0B0C85A10F; Thu, 13 Jan 2011 20:40:36 -0500 (EST) Received: from 97.122.244.7 (SquirrelMail authenticated user creed) by mail.opengeospatial.org with HTTP; Thu, 13 Jan 2011 20:40:36 -0500 (EST) Message-ID: <810a6dd859297c1e8df3fd74db09b59e.squirrel@mail.opengeospatial.org> In-Reply-To: <020BBF4F-8D14-4EC1-831D-C6246D410045@cdt.org> References: <020BBF4F-8D14-4EC1-831D-C6246D410045@cdt.org> Date: Thu, 13 Jan 2011 20:40:36 -0500 (EST) From: creed@opengeospatial.org To: "Alissa Cooper" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: geopriv@ietf.org Subject: Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 01:38:13 -0000 +1 Carl > Now that we have a milestone to "submit recommendations for LIS > discovery conducted by hosts behind residential gateways as > Informational," I'd like to call for WG adoption of draft-thomson- > geopriv-res-gw-lis-discovery-04. Please respond to the list by January > 19, 2011 about adopting this document as a WG item. > > Thanks, > Alissa > > > > > > > > > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > From rbarnes@bbn.com Thu Jan 13 20:43:01 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8FB03A686B for ; Thu, 13 Jan 2011 20:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFTZ8YJF87Zo for ; Thu, 13 Jan 2011 20:43:00 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id C3D3A3A6C4E for ; Thu, 13 Jan 2011 20:43:00 -0800 (PST) Received: from [128.89.253.213] (port=58751 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PdbXQ-000Mc6-7o for geopriv@ietf.org; Thu, 13 Jan 2011 23:45:24 -0500 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jan 2011 23:45:19 -0500 Message-Id: To: geopriv@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Geopriv] LIS discovery implementation thoughts X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 04:43:02 -0000 Hey all, Just wanted to share some impressions of the LIS discovery process, = including NAT traversal, based on our experience implementing this = function in the igtk project [1]. (Note: The techniques here haven't = yet been merged into the sourceforge version.) The basic flow-chart in RFC 5986 is pretty easy to implement, although = it wasn't really clear what to do for step (3), "Check URI", beyond = verifying that it's a well-formed URI. In pseudo-code, we ended up with = something like this: foreach (NetworkInterface iface) { DomainIterator it(iface); while (it.hasNext()) { string lisUri =3D performDdds(it.next()); if (valid(lisUri)) { return lisUri; } } } Here the DomainIterator supplies the following domains, if they are = available: 1. Option 213 [NB: Not DHCPv6 capable] 2. Option 15 The DomainIterator construct also allows us to easily extend the process = to support NAT traversal. If neither of the above options works, the = DomainIterator looks at the IP address for the interface, and if it's = private (any of the IANA reserved ranges [2]), then it does a STUN = request to find a public address. Using either the interface address or = the STUN address, it then provides the following domains: 3. The reverse domain 4. The reverse domain with the first label dropped 5. The reverse domain with the first two labels dropped=20 The entire LIS discovery service, which listens for network interface = changes and emits alerts when it finds a new LIS URI, required 584 lines = of C++. A very basic STUN client was another 293. So in a nutshell, extending a client from RFC 5986 to = draft-thomson-geopriv-res-gw-lis-discovery was pretty trivial, just a = matter of adding a few domains to the search list. We hope to have the = code posted to the igtk site soon; if you're interested in an advance = copy, let me know and I can send you an interim snapshot. --Richard [1] [2] = = From rbarnes@bbn.com Thu Jan 13 20:45:41 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC283A6C4C for ; Thu, 13 Jan 2011 20:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRzY4EwH3EaU for ; Thu, 13 Jan 2011 20:45:38 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 798253A6C48 for ; Thu, 13 Jan 2011 20:45:38 -0800 (PST) Received: from [128.89.253.213] (port=58754 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PdbZy-000McS-FE; Thu, 13 Jan 2011 23:48:02 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Thu, 13 Jan 2011 23:47:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5125204A-95F5-42E3-9EE5-DEAC5F3273A1@bbn.com> References: To: Richard L. Barnes X-Mailer: Apple Mail (2.1082) Cc: geopriv@ietf.org Subject: Re: [Geopriv] LIS discovery implementation thoughts X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 04:45:41 -0000 One additional note: Our client is not technically compliant with RFC = 5986, since it doesn't validate the URI with a HELD request: " A Device that discovers a LIS URI MUST attempt to verify that the LIS is able to provide location information. For the HELD protocol, the Device verifies the URI by making a location request to the LIS. =20 " --Richard On Jan 13, 2011, at 11:45 PM, Richard L. Barnes wrote: > Hey all, >=20 > Just wanted to share some impressions of the LIS discovery process, = including NAT traversal, based on our experience implementing this = function in the igtk project [1]. (Note: The techniques here haven't = yet been merged into the sourceforge version.) >=20 > The basic flow-chart in RFC 5986 is pretty easy to implement, although = it wasn't really clear what to do for step (3), "Check URI", beyond = verifying that it's a well-formed URI. In pseudo-code, we ended up with = something like this: >=20 > foreach (NetworkInterface iface) { > DomainIterator it(iface); > while (it.hasNext()) { > string lisUri =3D performDdds(it.next()); > if (valid(lisUri)) { return lisUri; } > } > } >=20 > Here the DomainIterator supplies the following domains, if they are = available: > 1. Option 213 [NB: Not DHCPv6 capable] > 2. Option 15 >=20 > The DomainIterator construct also allows us to easily extend the = process to support NAT traversal. If neither of the above options = works, the DomainIterator looks at the IP address for the interface, and = if it's private (any of the IANA reserved ranges [2]), then it does a = STUN request to find a public address. Using either the interface = address or the STUN address, it then provides the following domains: > 3. The reverse domain > 4. The reverse domain with the first label dropped > 5. The reverse domain with the first two labels dropped=20 >=20 > The entire LIS discovery service, which listens for network interface = changes and emits alerts when it finds a new LIS URI, required 584 lines = of C++. A very basic STUN client was another 293. >=20 > So in a nutshell, extending a client from RFC 5986 to = draft-thomson-geopriv-res-gw-lis-discovery was pretty trivial, just a = matter of adding a few domains to the search list. We hope to have the = code posted to the igtk site soon; if you're interested in an advance = copy, let me know and I can send you an interim snapshot. >=20 > --Richard >=20 >=20 > [1] > [2] = > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From Martin.Thomson@andrew.com Thu Jan 13 22:05:00 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C7A3A6C4C for ; Thu, 13 Jan 2011 22:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKXFbzKVpI0g for ; Thu, 13 Jan 2011 22:04:57 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id DA3DB3A6A91 for ; Thu, 13 Jan 2011 22:04:56 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:7055 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S41279771Ab1ANGHV (ORCPT ); Fri, 14 Jan 2011 00:07:21 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Fri, 14 Jan 2011 00:07:21 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 14 Jan 2011 14:07:17 +0800 From: "Thomson, Martin" To: "geopriv@ietf.org" Date: Fri, 14 Jan 2011 14:07:14 +0800 Thread-Topic: New Version Notification for draft-thomson-geopriv-location-obscuring-02 Thread-Index: Acuzq9KnM3A7xSrMR1myBa3kY+lWQAAAHa2Q Message-ID: <8B0A9FCBB9832F43971E38010638454F03F5259507@SISPE7MB1.commscope.com> References: <20110114052538.873A23A68BA@core3.amsl.com> In-Reply-To: <20110114052538.873A23A68BA@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: [Geopriv] FW: New Version Notification for draft-thomson-geopriv-location-obscuring-02 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 06:05:00 -0000 SSd2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgbG9jYXRpb24gb2JzY3VyaW5nIGRy YWZ0Lg0KDQpDaGFuZ2VzIGluY2x1ZGU6DQoNCiAtIEFkZGVkIGFuIGltcHJvdmVkIG1ldGhvZCBm b3IgZ2VuZXJhdGluZyByYW5kb20gdmVjdG9ycyB0aGF0IGFsbG93cyBmb3IgbGVzcyB2YXJpYXRp b24gZHVyaW5nIGludGVycG9sYXRpb24uICBUaGlzIG1lYW5zIHRoYXQgdGhlIHJlY29tbWVuZGVk IGdyaWQgc2l6ZSBjYW4gYmUgbWFkZSBtdWNoIHNtYWxsZXIgKG5vdyA4IHRpbWVzIHRoZSBvYnNj dXJpbmcgZGlzdGFuY2UsIGRvd24gZnJvbSAyMCkuDQogLSBSZWZpbmVkIHRoZSBjYWxjdWxhdGlv bnMgYXJvdW5kIHdoYXQgZ3JpZCBzaXplIHdhcyBuZWNlc3NhcnkgYW5kIHRoZSBlZmZlY3QgdGhh dCBjaGFuZ2luZyB0aGUgb2Zmc2V0IHZlY3RvciBoYXMgb24gd29yc3QtY2FzZSBhYmlsaXR5IHRv IHJlZHVjZSB1bmNlcnRhaW50eSBhcmVhLg0KIC0gQWRkZWQgYW4gZXhhbXBsZS4NCiAtIFdvcmRp bmcgYW5kIHRoZSB1c3VhbCBlZGl0b3JpYWwgY2xlYW51cCBzdHVmZi4NCg0KTXkgZGVtb25zdHJh dGlvbiBwYWdlIGlzIG5vdyBsaXZlIGhlcmUsIHVzaW5nIHRoZSB1cGRhdGVkIG1ldGhvZDoNCg0K ICA8aHR0cDovL2hlbGQtbG9jYXRpb24uc291cmNlZm9yZ2UubmV0L2pzX2dlb3NoYXBlL21hcHRl c3QuaHRtbD4NCg0KLS0NCg0KSSd2ZSBhbHNvIGRldmVsb3BlZCBhIGZldyB0b29scyBmb3Igdmlz dWFsaXppbmcgdGhlIGludGVycG9sYXRpb24gcHJvY2VzcyB1c2luZyBQcm9jZXNzaW5nLiAgVGhl IGZvbGxvd2luZyBhcmUgcHJvYmFibHkgb2YgbW9zdCBpbnRlcmVzdDoNCg0KUmFuZG9tIHZlY3Rv ciBncmlkIHZpc3VhbGl6YXRpb24gDQogICA8aHR0cDovL2hlbGQtbG9jYXRpb24uc291cmNlZm9y Z2UubmV0L3JhbmRvbVZlY3RvckdyaWQvcmFuZG9tVmVjdG9yR3JpZC5qYXI+DQpTaG93cyBob3cg cmFuZG9tIHZlY3RvcnMgYXJlIGNob3NlbiBhbmQgaW50ZXJwb2xhdGVkLiAgQ29tcGFyZXMgYm90 aCBpbnRlcnBvbGF0aW9uIG1ldGhvZHMuDQoNClNxdWFyZSBwZWcgaW50ZXJwb2xhdGlvbiB2aXN1 YWxpemF0aW9uDQogICA8aHR0cDovL2hlbGQtbG9jYXRpb24uc291cmNlZm9yZ2UubmV0L2ludGVy cG9sYXRpb24vaW50ZXJwLmphcj4NClNob3dzIGhvdyBpbnRlcnBvbGF0aW9uIGlzIHVzZWQgYmV0 d2VlbiB0d28gZGlmZmVyZW50IHBvaW50cyBpbiB0aGUgY2lyY2xlLiAgQ29tcGFyZXMgaW50ZXJw b2xhdGlvbiBtZXRob2RzIGFuZCBkZW1vbnN0cmF0ZXMgaG93IHRoZSBzcXVhcmUgcGVnIG1ldGhv ZCBpcyB1c2VkLiAgSSBmb3VuZCB0aGUgbG9vcHMgdGhhdCBmb3JtIHRvIGJlIGludGVyZXN0aW5n Lg0KDQotLU1hcnRpbg0KDQpwLnMuIEknZCBsaW5rIHRvIHRoZSBhcHBsZXRzIGRpcmVjdGx5LCBi dXQgSSBjb3VsZG4ndCBiZSBzdXJlIHRoYXQgdGhleSBhcmUgc2FmZSAtIHRoZSBhcHBsZXRzIGNh dXNlZCBldmVyeSBicm93c2VyIEkgaGF2ZSB0byBkaWUgaG9ycmlibHkuICBJdCBzZWVtcyBsaWtl IGEgSmF2YSBwcm9ibGVtLiAgU3RyaXAgdGhlIGxhc3QgcGFydCBvZiB0aGUgcGF0aCBvZmYgaWYg eW91IGFyZSBnYW1lLg0KDQpPbiAyMDExLTAxLTE0IGF0IDE2OjI1OjM4LCBJRVRGIEktRCBTdWJt aXNzaW9uIFRvb2wgd3JvdGU6DQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10aG9tc29u LWdlb3ByaXYtbG9jYXRpb24tb2JzY3VyaW5nLTAyLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IE1hcnRpbiBUaG9tc29uIGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYg cmVwb3NpdG9yeS4NCg== From jari.urpalainen@nokia.com Fri Jan 14 00:27:48 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81FA53A6C5A for ; Fri, 14 Jan 2011 00:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPE5zW6NK9qp for ; Fri, 14 Jan 2011 00:27:47 -0800 (PST) Received: from mgw-da02.nokia.com (mgw-da02.ext.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id B8E8A3A6C54 for ; Fri, 14 Jan 2011 00:27:47 -0800 (PST) Received: from [172.21.21.80] (helruo-dhcp02180.ntc.nokia.com [172.21.21.80]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0E8Tvpg001375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Jan 2011 10:29:59 +0200 From: Jari Urpalainen To: "ext Richard L. Barnes" In-Reply-To: <81A73BF6-4382-41BC-B04C-A4F5C797A47A@bbn.com> References: <1294813793.19168.211.camel@urpalain-desktop> <576032AB-A98A-4BB7-AC42-914B5911EBF4@bbn.com> <1294904089.23241.87.camel@urpalain-desktop> <81A73BF6-4382-41BC-B04C-A4F5C797A47A@bbn.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 14 Jan 2011 10:29:50 +0200 Message-ID: <1294993790.7365.43.camel@urpalain-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Nokia-AV: Clean Cc: geopriv@ietf.org Subject: Re: [Geopriv] empty conditions element in common policy (rfc4745) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 08:27:48 -0000 On Thu, 2011-01-13 at 10:50 -0500, ext Richard L. Barnes wrote: > > or something similar. It might be good to add this as errdata since i'm > > pretty certain this can be seen in iop tests. > > I'm not familiar enough with the erratum process to say whether this is appropriate, but I agree that this seems like a good thing to clarify. It might make sense to write a brief I-D with clarifications to RFC 4745, especially if there are other interop issues. > > --Richard > The errdata process is imo just enough, since this is a pretty minor clarification where a one liner fix will make the intended behavior unambiguous. I don't mind if someone wants to make a bigger stab on this, but certainly, i'm _not_ proposing that. Imo, for implementors, errdata is authoritative and fast enough (instead of referring to some mailing list thread discussion). The rfc authors have been silent though... br Jari From Ray.Bellis@nominet.org.uk Fri Jan 14 00:32:04 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C183C3A6C5A for ; Fri, 14 Jan 2011 00:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZ81-8wlDpWn for ; Fri, 14 Jan 2011 00:32:04 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id C2D743A6AB9 for ; Fri, 14 Jan 2011 00:32:03 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=eMyrZlDii0b5xGuPnjlHSU/UxwEhLi4sSwtGyXlnQMTybqpqx08AGZVC c2+Ez6n8+GiVe2HLYTdps9pxsenO7zkHq+b94Apv2D91sNWSkjyq6U051 xRwpyhZxhSIWSUu; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1294994069; x=1326530069; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[Geopriv]=20Consensus=20call:=09Adoptio n=09of=0D=0A=09draft-thomson-geopriv-res-gw-lis-discovery -04|Date:=20Fri,=2014=20Jan=202011=2008:34:25=20+0000 |Message-ID:=20<37EA0EDD-9ED4-4637-937E-09EE0C10CAE5@nomi net.org.uk>|To:=20"geopriv@ietf.org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20<77b06bc4-95ec-4de6-9283-5bf216cf 7f40>|In-Reply-To:=20<8B0A9FCBB9832F43971E38010638454F03F 5259471@SISPE7MB1.commscope.com>|References:=20<020BBF4F- 8D14-4EC1-831D-C6246D410045@cdt.org>=0D=0A=20<5A55A45AE77 F5941B18E5457ECAC81880120F437CCB7@SISPE7MB1.commscope.com >=0D=0A=20 =0D=0A=20<8B0A9FCBB9832F43971E38010638454F03F5259471@SISP E7MB1.commscope.com>; bh=IZao1canhohpGL5jAukrriIKET3ljtUdZoN8YPAs1V8=; b=WgXxzl7d4YKgokov2gfZIKtHSCiw/ITnrragKtYQrvuFuKEek0Y2OQxo Z7nig5aPmlZVoj3UMerG1HjjYKXYTeewY3UqSTfszu34J/QuqGQ1Egxx2 PBXVWJVQ7oKnP+p; X-IronPort-AV: E=Sophos;i="4.60,322,1291593600"; d="scan'208";a="23985234" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 14 Jan 2011 08:34:27 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Fri, 14 Jan 2011 08:34:27 +0000 From: Ray Bellis To: "geopriv@ietf.org" Thread-Topic: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04 Thread-Index: AQHLs2xzdxZUi2LrJ0unSi28fJruIJPQJNqA Date: Fri, 14 Jan 2011 08:34:25 +0000 Message-ID: <37EA0EDD-9ED4-4637-937E-09EE0C10CAE5@nominet.org.uk> References: <020BBF4F-8D14-4EC1-831D-C6246D410045@cdt.org> <5A55A45AE77F5941B18E5457ECAC81880120F437CCB7@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03F5259471@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F5259471@SISPE7MB1.commscope.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <77b06bc4-95ec-4de6-9283-5bf216cf7f40> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 08:32:04 -0000 On 13 Jan 2011, at 21:54, Thomson, Martin wrote: > Ditto. And I support it too, of course :) Ray From dmarnold@verizon.net Thu Jan 13 07:34:28 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF7D3A6BA4; Thu, 13 Jan 2011 07:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdIVdHGYp6-k; Thu, 13 Jan 2011 07:34:25 -0800 (PST) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by core3.amsl.com (Postfix) with ESMTP id 2E2E93A69B9; Thu, 13 Jan 2011 07:34:25 -0800 (PST) Received: from ArmstrongLaptop3786f509e ([unknown] [173.65.80.75]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LEY00IRAWP7EQK4@vms173005.mailsrvcs.net>; Thu, 13 Jan 2011 09:36:45 -0600 (CST) From: "Delaine M Arnold ENP" To: "Delaine M Arnold ENP" Date: Thu, 13 Jan 2011 10:36:42 -0500 Message-id: <004a01cbb337$ae70eac0$0b52c040$@net> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_004B_01CBB30D.C59AE2C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcuzN5dVDQm5Y51wSByKs12YIGsSZw== Content-language: en-us X-Mailman-Approved-At: Fri, 14 Jan 2011 01:34:45 -0800 Subject: [Geopriv] NENA ICE 4: Call Routing Based on LoST Hierarchy X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dmarnold@verizon.net List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 15:34:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_004B_01CBB30D.C59AE2C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The NG9-1-1 Industry Collaboration Events Steering Committee is pleased to announce that Jason Horning, Chair, and Bill Mertka, Vice Chair, will lead NENA's ICE 4 Planning Committee. ICE 4 will test call routing based on LoST hierarchy. For more information about how to join the ICE 4 Planning Committee and learn about NENA NG9-1-1 Industry Collaboration Events click here or contact Delaine Arnold. Thank you, Delaine --------------------------------------- Delaine M. Arnold, ENP NENA Industry Collaboration Event (ICE) Testing Coordination Manager Chair, NENA Data Technical Committee Voice: 813-960-1698 Cell: 813-928-1692 Email: dmarnold@verizon.net "Life is not measured by the breaths we take, but by the moments that take our breath away." ------=_NextPart_000_004B_01CBB30D.C59AE2C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The NG9-1-1 Industry Collaboration Events = Steering Committee is pleased to announce that Jason Horning, Chair, and = Bill Mertka, Vice Chair, will lead NENA’s ICE 4 Planning = Committee. ICE 4 will test call routing based on LoST hierarchy. = For more information about how to join the ICE 4 Planning Committee = and learn about NENA NG9-1-1 Industry Collaboration Events click here or contact Delaine = Arnold

 

Thank = you,

Delaine

---------------------------------------=

Delaine M. Arnold, ENP

NENA Industry Collaboration Event (ICE) Testing Coordination Manager

Chair, NENA Data Technical Committee

Voice:  813-960-1698

Cell:     813-928-1692

Email:  dmarnold@verizon.net

 

"Life = is not measured by the breaths we take, but by the moments that = take our breath away." 

 

 

 

------=_NextPart_000_004B_01CBB30D.C59AE2C0-- From dworley@avaya.com Thu Jan 13 11:01:03 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018893A6A64 for ; Thu, 13 Jan 2011 11:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPL-gT8wy-og for ; Thu, 13 Jan 2011 11:01:02 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 6354A3A6BCF for ; Thu, 13 Jan 2011 11:01:01 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG7bLk2HCzI1/2dsb2JhbACkS3OnAwKWJoVMBIRoiWQ X-IronPort-AV: E=Sophos;i="4.60,318,1291611600"; d="scan'208";a="227418274" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Jan 2011 14:03:23 -0500 X-IronPort-AV: E=Sophos;i="4.60,318,1291611600"; d="scan'208";a="582013820" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Jan 2011 14:03:22 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.160]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 13 Jan 2011 14:03:21 -0500 From: "Worley, Dale R (Dale)" To: Robert Sparks , "geopriv@ietf.org" Date: Thu, 13 Jan 2011 14:01:33 -0500 Thread-Topic: Errata report on erratum 2066 to RFC5774 ("Considerations for Civic Addresses in the PIDF-LO") and errata 2521 and 2522 to RFC 5986 ("Discovering the Local Location Information Server") Thread-Index: AQHLs1SLyjw2c39/ckWWr9xh4kG+hQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 14 Jan 2011 01:34:45 -0800 Subject: [Geopriv] Errata report on erratum 2066 to RFC5774 ("Considerations for Civic Addresses in the PIDF-LO") and errata 2521 and 2522 to RFC 5986 ("Discovering the Local Location Information Server") X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 19:01:03 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC5774, "Considerations for Civic Addresses in the PIDF-LO: Guidelines and IANA Registry Definition", Source of RFC: geopriv (rai) Errata ID: 2066 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2010-03-05 Section 1, 6th para says: Section 3.4 of [RFC4776] also contains instructions on the creation | of civic address considerations documents on page 8. This document updates that section and replaces said instructions with Sections 4 and 5 of this memo. It should say: Section 3.4 of [RFC4776] also contains instructions on the creation | of civic address considerations documents on page 9. This document updates that section and replaces said instructions with Sections 4 and 5 of this memo. Notes: Rationale: This indeed refers to the second paragraph on page _9_ of RFC 4776. ---------------------------------------------------------------------- Recommended status: (correct) Hold for document update =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC5986, "Discovering the Local Location Information Server (LIS)" Source of RFC: geopriv (rai) Errata ID: 2521 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2010-09-15 Section 3.4,3rd para says: DHCPv4 option 15 [RFC2132] provides an indication of the domain name | that a host uses when resolving hostnames in DNS. This option is used when the DHCPv4 access domain name is not available. It should say: DHCPv4 option 15 [RFC2132] provides an indication of the domain name | that a host uses when resolving hostnames in the DNS. This option is used when the DHCPv4 access domain name is not available. Notes: Rationale: missing article ---------------------------------------------------------------------- Recommended status: (correct) Hold for document update This erratum is difficult to assess absolutely; the terms "DNS" and "the DNS" are both used with this meaning. RFC 5986 uses "the DNS" twice and "DNS" once, making it difficult to state which convention it uses, and therefore, which uses are incorrect. In any case, the editor of the revised document can resolve it. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC5986, "Discovering the Local Location Information Server (LIS)" Source of RFC: geopriv (rai) Errata ID: 2522 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2010-09-15 Section 5, pg.12 says: | The domain name that used to authenticate the LIS is the domain name input to the U-NAPTR process, not the output of that process [RFC3958], [RFC4848]. As a result, the results of DNS queries do not need integrity protection. It should say: | The domain name that is used to authenticate the LIS is the domain name input to the U-NAPTR process, not the output of that process [RFC3958], [RFC4848]. As a result, the results of DNS queries do not need integrity protection. Notes: Rationale: missing verb: "is" ---------------------------------------------------------------------- Recommended status: (correct) Hold for document update Either "is" should be inserted (to give "The domain name that is used to ...") or "that" should be removed (to give "The domain name used to ...". In any case, the editor of the revised document can resolve it. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dale From Internet-Drafts@ietf.org Fri Jan 14 20:00:04 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF883A6C3E; Fri, 14 Jan 2011 20:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdZ92sZuCn3N; Fri, 14 Jan 2011 20:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78FD23A680E; Fri, 14 Jan 2011 20:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110115040002.8557.88180.idtracker@localhost> Date: Fri, 14 Jan 2011 20:00:02 -0800 Cc: geopriv@ietf.org Subject: [Geopriv] I-D Action:draft-ietf-geopriv-rfc3825bis-15.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 04:00:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Geographic Location/Privacy Working Group of the IETF. Title : Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information Author(s) : J. Polk, et al. Filename : draft-ietf-geopriv-rfc3825bis-15.txt Pages : 33 Date : 2011-01-14 This document specifies Dynamic Host Configuration Protocol Options (both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes Latitude, Longitude, and Altitude, with resolution or uncertainty indicators for each. Separate parameters indicate the reference datum for each of these values. This document obsoletes RFC 3825. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-rfc3825bis-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-geopriv-rfc3825bis-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-14194810.I-D@ietf.org> --NextPart-- From bernard.aboba@gmail.com Wed Jan 19 08:48:04 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3D5F3A7178 for ; Wed, 19 Jan 2011 08:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-BLbtPC4pay for ; Wed, 19 Jan 2011 08:48:03 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id C19FF3A7170 for ; Wed, 19 Jan 2011 08:48:02 -0800 (PST) Received: by bwz12 with SMTP id 12so1024267bwz.31 for ; Wed, 19 Jan 2011 08:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=/vSHc5/E62jxoZ+vNRi2p5qBEf1qDqYI8Q4uN/AICtw=; b=gxHaRY3rOEsufXBgHCbSwmFqqUaOTF+xCivYeHutWDKXJNjVox5+VJEWfH5iZCdLuE lUYJBl1vk4tMBpWO926ObioEfakzOGcOYNNCx5ANDdasnQuf+Ax0BBQAPZNf8Ll6SHpk sIO7iBVmKOACCKtLDwZldpoYhhPmk+XCWcM2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=aa/k2faWKsApOxEFjvWEjS3sHcibhlvi9Do/xesltZK4CpwWsbKYregXZJTqW8r20m 92KRocZn9Nb2nkucbhzbyvbkuckb6Wd2fuCGuX07LvRcisHmFF4DIDfss3OSeLsNbPuu CaFG2Un7wJ8jwRjRL7PvpmX1AJ5VC5tP+Tnf0= Received: by 10.227.157.73 with SMTP id a9mr1055853wbx.154.1295455842105; Wed, 19 Jan 2011 08:50:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.27.21 with HTTP; Wed, 19 Jan 2011 08:50:15 -0800 (PST) From: Bernard Aboba Date: Wed, 19 Jan 2011 08:50:15 -0800 Message-ID: To: geopriv@ietf.org Content-Type: multipart/alternative; boundary=0016e65b620a4a822f049a35d16c Subject: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC 3825bis) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 16:48:04 -0000 --0016e65b620a4a822f049a35d16c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ari Ker=E4nen's review (see below) included a comment on issues arising fro= m clamping of latitude/longitude values outside the range. Comments? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2.3. Latitude and Longitude Fields Latitude values encoded by the DHCP server MUST be constrained to the range from -90 to +90 degrees. Location consumers MUST be prepared to normalize values outside this range. Values outside the range are normalized by clamping [...] If the values MUST be within those boundaries, doesn't it mean that a value that is out of the range is somewhat likely completely wrong (due to a broken implementation) and thus it would make sense to ignore it rather than try to normalize the value and make it appear as if it was valid? I'm not sure if I'd like to be liberal in what I accept when it comes to information that could literally be a matter of life and death. --0016e65b620a4a822f049a35d16c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Ari Ker=E4nen's review (see below) included a comment on issues arising fro= m clamping of
latitude/longitude values outside the range.=A0

Comments?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
2.3. Latitude and Longitude Fields

Latitude values encoded by the DHCP server MUST be constrained to the
range from -90 to +90 degrees. Location consumers MUST be prepared
to normalize values outside this range. Values outside the range are
normalized by clamping [...]

If the values MUST be within those boundaries, doesn't it mean that a
value that is out of the range is somewhat likely completely wrong (due to a broken implementation) and thus it would make sense to ignore it
rather than try to normalize the value and make it appear as if it was
valid? I'm not sure if I'd like to be liberal in what I accept when= it
comes to information that could literally be a matter of life and death.

--0016e65b620a4a822f049a35d16c-- From rbarnes@bbn.com Wed Jan 19 08:55:09 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2CA3A7170 for ; Wed, 19 Jan 2011 08:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.715 X-Spam-Level: X-Spam-Status: No, score=-102.715 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7o7CYpxkkbDd for ; Wed, 19 Jan 2011 08:55:08 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6D5A23A703D for ; Wed, 19 Jan 2011 08:55:08 -0800 (PST) Received: from [192.1.255.181] (port=50034 helo=col-raltmann-l1.nira.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PfbLw-000Mso-3k; Wed, 19 Jan 2011 11:57:48 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: "Richard L. Barnes" In-Reply-To: Date: Wed, 19 Jan 2011 11:57:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <70BAF42D-A172-4B64-BCA5-BD59BBEEED7E@bbn.com> References: To: Bernard Aboba X-Mailer: Apple Mail (2.1082) Cc: geopriv@ietf.org Subject: Re: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC 3825bis) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 16:55:09 -0000 It seems like things are likely to be wrong in either case, assuming = you're not at a pole. So I don't see any difference between one flavor = of wrong and the other, at that level. At least clamping is less likely = to cause problems at higher layers. --Richard On Jan 19, 2011, at 11:50 AM, Bernard Aboba wrote: > Ari Ker=E4nen's review (see below) included a comment on issues = arising from clamping of > latitude/longitude values outside the range. =20 >=20 > Comments? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 2.3. Latitude and Longitude Fields >=20 > Latitude values encoded by the DHCP server MUST be constrained to the > range from -90 to +90 degrees. Location consumers MUST be prepared > to normalize values outside this range. Values outside the range are > normalized by clamping [...] >=20 > If the values MUST be within those boundaries, doesn't it mean that a=20= > value that is out of the range is somewhat likely completely wrong = (due=20 > to a broken implementation) and thus it would make sense to ignore it=20= > rather than try to normalize the value and make it appear as if it was=20= > valid? I'm not sure if I'd like to be liberal in what I accept when it=20= > comes to information that could literally be a matter of life and = death. >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From bernard.aboba@gmail.com Wed Jan 19 10:16:02 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691A03A7039 for ; Wed, 19 Jan 2011 10:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2om1nJCxDM3j for ; Wed, 19 Jan 2011 10:16:00 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 3A3343A6FBA for ; Wed, 19 Jan 2011 10:16:00 -0800 (PST) Received: by yxt33 with SMTP id 33so448241yxt.31 for ; Wed, 19 Jan 2011 10:18:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=vG6N/CmRh1/Kw9sfbEV9fZ8m/kr1aUz5U/kDeOA9ZrQ=; b=IyRg6k+szDY7q4ISthHE+z+d5JgNEaLiz5gpWzZBKIxIa5oOOKWAX7pD0E8/qXPtrV TW78SKPfsQJll4iU3jOridroLmyFS549Pt3kF5X6IqUzUc8oMI3ZqRxq+h/qCx4nmIRb zyarpNFAcMPaBOcaomHKSQ4UiYK7o7FMaVK1U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=oVg5h0+D/rtx4y2z3kwPg4nxMR+alnDpzBsj9RLM4E2l3aHhxNmaTRXXfyPAdpMzUO dPODNsWu99cawpIjdjh24xHBQ6Mw6CCR3meOUt6Xl6fnIkm7RVc7jQW25ro924aXgmsK 7dcWigsknhQKWn2AKJC8laefEYIticpNer3HM= Received: by 10.216.186.196 with SMTP id w46mr931057wem.105.1295461120202; Wed, 19 Jan 2011 10:18:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.27.21 with HTTP; Wed, 19 Jan 2011 10:18:20 -0800 (PST) In-Reply-To: <70BAF42D-A172-4B64-BCA5-BD59BBEEED7E@bbn.com> References: <70BAF42D-A172-4B64-BCA5-BD59BBEEED7E@bbn.com> From: Bernard Aboba Date: Wed, 19 Jan 2011 10:18:20 -0800 Message-ID: To: "Richard L. Barnes" , geopriv Content-Type: multipart/alternative; boundary=0016e649daeae3d889049a370b97 Subject: Re: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC 3825bis) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 18:16:02 -0000 --0016e649daeae3d889049a370b97 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In reality, wouldn't the decision be made at higher layers anyway? The DHC= P client typically would not be the place to execute the clamping (or discard= ) logic, the LCI Option would be passed up to other components (e.g. location provider or application) where the decision would be made. Given this, advocating that the DHCP client make a discard decision which relies on detailed knowledge of the option format doesn't make sense to me. It seems more likely that a decision on discard would be made by the application which has available the full range of information relating to location determination (e.g. local policies, whether other more accurate location values are available, whether manual override has occurred, etc.). On Wed, Jan 19, 2011 at 8:57 AM, Richard L. Barnes wrote: > It seems like things are likely to be wrong in either case, assuming you'= re > not at a pole. So I don't see any difference between one flavor of wrong > and the other, at that level. At least clamping is less likely to cause > problems at higher layers. > > --Richard > > > On Jan 19, 2011, at 11:50 AM, Bernard Aboba wrote: > > > Ari Ker=E4nen's review (see below) included a comment on issues arising > from clamping of > > latitude/longitude values outside the range. > > > > Comments? > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 2.3. Latitude and Longitude Fields > > > > Latitude values encoded by the DHCP server MUST be constrained to the > > range from -90 to +90 degrees. Location consumers MUST be prepared > > to normalize values outside this range. Values outside the range are > > normalized by clamping [...] > > > > If the values MUST be within those boundaries, doesn't it mean that a > > value that is out of the range is somewhat likely completely wrong (due > > to a broken implementation) and thus it would make sense to ignore it > > rather than try to normalize the value and make it appear as if it was > > valid? I'm not sure if I'd like to be liberal in what I accept when it > > comes to information that could literally be a matter of life and death= . > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www.ietf.org/mailman/listinfo/geopriv > > --0016e649daeae3d889049a370b97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In reality, wouldn't the decision be made at higher layers anyway?=A0 T= he DHCP client typically would not be the place to execute the clamping (or= discard) logic, the LCI Option would be passed up to other components (e.g= . location provider or application) where the decision would be made.=A0 Gi= ven this, advocating that the DHCP client make a discard decision which rel= ies on detailed knowledge of the option format doesn't make sense to me= .

It seems more likely that a decision on discard would be made by the ap= plication which has available the full range of information relating to loc= ation determination (e.g. local policies, whether other more accurate locat= ion values are available, whether manual override has occurred, etc.).

On Wed, Jan 19, 2011 at 8:57 AM, Richard L. = Barnes <rbarnes@bbn= .com> wrote:
It seems like things are likely to be wrong in either case, assuming you= 9;re not at a pole. =A0So I don't see any difference between one flavor= of wrong and the other, at that level. =A0At least clamping is less likely= to cause problems at higher layers.

--Richard


On Jan 19, 2011, at 11:50 AM, Bernard Aboba wrote:

> Ari Ker=E4nen's review (see below) included a comment on issues ar= ising from clamping of
> latitude/longitude values outside the range.
>
> Comments?
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 2.3. Latitude and Longitude Fields
>
> Latitude values encoded by the DHCP server MUST be constrained to the<= br> > range from -90 to +90 degrees. Location consumers MUST be prepared
> to normalize values outside this range. Values outside the range are > normalized by clamping [...]
>
> If the values MUST be within those boundaries, doesn't it mean tha= t a
> value that is out of the range is somewhat likely completely wrong (du= e
> to a broken implementation) and thus it would make sense to ignore it<= br> > rather than try to normalize the value and make it appear as if it was=
> valid? I'm not sure if I'd like to be liberal in what I accept= when it
> comes to information that could literally be a matter of life and deat= h.
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv


--0016e649daeae3d889049a370b97-- From James.Winterbottom@andrew.com Wed Jan 19 15:48:02 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586E628C122 for ; Wed, 19 Jan 2011 15:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.430, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE8wvs7qZVPt for ; Wed, 19 Jan 2011 15:48:01 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 7EDC528C117 for ; Wed, 19 Jan 2011 15:48:01 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:23934 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S41624077Ab1ASXum convert rfc822-to-8bit (ORCPT ); Wed, 19 Jan 2011 17:50:42 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Wed, 19 Jan 2011 17:50:42 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 20 Jan 2011 07:50:40 +0800 From: "Winterbottom, James" To: "Thomson, Martin" , "geopriv@ietf.org" Date: Thu, 20 Jan 2011 07:50:39 +0800 Thread-Topic: Civic extensions draft Thread-Index: AcudpQKey19cne7xRxejazlHvugCzQajnmlg Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120F4429F53@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03F34FB187@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F34FB187@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Geopriv] Civic extensions draft X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 23:48:02 -0000 Can we please see some feedback on this updated document? We would like to get the issue of civic schema extensions resolved quickly to avoid extensions occurring that differ from what we would all like to see happen. Cheers James > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf > Of Thomson, Martin > Sent: Friday, 17 December 2010 3:44 PM > To: geopriv@ietf.org > Subject: [Geopriv] Civic extensions draft > > I've just posted a revision to the -local-civic draft that captures some > of the progress in the civic address extension discussions we've been > having. > > http://tools.ietf.org/html/draft-winterbottom-geopriv-local-civic-04 > > A lot has changed. The changes are based on the discussions that Brian, > Richard and I have had both on and off list. > > This isn't the end of the discussion. We haven't completely finished > ironing out all the details, but we've made some fairly significant > progress. > > The high points: > > - problem: there are two formats, and currently two places that > extensions to those formats can originate > > - solution: the draft makes the XML format the only place an extension > can originate > > - consequence: one final CAtype is defined for carrying an XML- > originating extension > > - consequence: the CAtype registry is revised to reflect this > > > I think that this is simple, pragmatic and backward compatible. > > --Martin > > p.s. On leave until January. Apologies if responses are a little slow. > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From creed@opengeospatial.org Fri Jan 21 14:09:40 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502143A6AA9 for ; Fri, 21 Jan 2011 14:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.243 X-Spam-Level: X-Spam-Status: No, score=0.243 tagged_above=-999 required=5 tests=[AWL=1.919, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unglCgePj57P for ; Fri, 21 Jan 2011 14:09:38 -0800 (PST) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by core3.amsl.com (Postfix) with ESMTP id C8EA03A6A81 for ; Fri, 21 Jan 2011 14:09:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 5B26C5A119; Fri, 21 Jan 2011 17:12:25 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (mail.opengeospatial.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHjj+81ocLiR; Fri, 21 Jan 2011 17:12:24 -0500 (EST) Received: from CarlandSusieOf (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id 3A0675A0E5; Fri, 21 Jan 2011 17:12:24 -0500 (EST) Message-ID: From: "Carl Reed" To: "Bernard Aboba" , References: In-Reply-To: Date: Fri, 21 Jan 2011 15:11:52 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0DCD_01CBB97D.8898FFD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Subject: Re: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC3825bis) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 22:09:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0DCD_01CBB97D.8898FFD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would agree that if a value is outside the normal ranges for lat and = long, then there is an error somewhere in the workflow. As such, an = error message should be reported to the application or the user. = Clamping to +90 is actually creating even more erroneous data. Thanks, = Bernard. Carl ----- Original Message -----=20 From: Bernard Aboba=20 To: geopriv@ietf.org=20 Sent: Wednesday, January 19, 2011 9:50 AM Subject: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS = on RFC3825bis) Ari Ker=E4nen's review (see below) included a comment on issues = arising from clamping of latitude/longitude values outside the range. =20 Comments? = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2.3. Latitude and Longitude Fields Latitude values encoded by the DHCP server MUST be constrained to the range from -90 to +90 degrees. Location consumers MUST be prepared to normalize values outside this range. Values outside the range are normalized by clamping [...] If the values MUST be within those boundaries, doesn't it mean that a=20 value that is out of the range is somewhat likely completely wrong = (due=20 to a broken implementation) and thus it would make sense to ignore it=20 rather than try to normalize the value and make it appear as if it was = valid? I'm not sure if I'd like to be liberal in what I accept when it = comes to information that could literally be a matter of life and = death. -------------------------------------------------------------------------= ----- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv ------=_NextPart_000_0DCD_01CBB97D.8898FFD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I would agree that if a value is outside the normal ranges for lat = and=20 long, then there is an error somewhere in the workflow. As such, an = error=20 message should be reported to the application or the user. Clamping to = +90 is=20 actually creating even more erroneous data. Thanks, Bernard.
 
Carl
 
----- Original Message -----
From:=20 Bernard=20 Aboba
Sent: Wednesday, January 19, = 2011 9:50=20 AM
Subject: [Geopriv] Proposed = resolution of=20 Ticket #44 (Jari's DISCUSS on RFC3825bis)

Ari = Ker=E4nen's=20 review (see below) included a comment on issues arising from clamping=20 of
latitude/longitude values outside the range.  =

Comments?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
2.3.=20 Latitude and Longitude Fields

Latitude = values=20 encoded by the DHCP server MUST be constrained to the
range from = -90 to +90=20 degrees. Location consumers MUST be prepared
to normalize values = outside=20 this range. Values outside the range are
normalized by clamping=20 [...]

If the = values MUST=20 be within those boundaries, doesn't it mean that a
value that is = out of=20 the range is somewhat likely completely wrong (due
to a broken=20 implementation) and thus it would make sense to ignore it
rather = than try=20 to normalize the value and make it appear as if it was
valid? I'm = not sure=20 if I'd like to be liberal in what I accept when it
comes to = information=20 that could literally be a matter of life and death.


_______________________________________________
Geopriv = mailing=20 = list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv=
------=_NextPart_000_0DCD_01CBB97D.8898FFD0-- From bernard.aboba@gmail.com Sat Jan 22 16:25:26 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461A93A6852 for ; Sat, 22 Jan 2011 16:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.603 X-Spam-Level: X-Spam-Status: No, score=-3.603 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMG1ASLwNSKL for ; Sat, 22 Jan 2011 16:25:25 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id BFAAB3A6840 for ; Sat, 22 Jan 2011 16:25:24 -0800 (PST) Received: by wwa36 with SMTP id 36so3712771wwa.13 for ; Sat, 22 Jan 2011 16:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QCND/UUj0ugVmsdSLXA0o+vYaj4vUaB1bOyPO4Tlgtk=; b=ECxJIUNaqUwvblOZNSpcAOWsZx7R8RAti5cdBqfhhygyPoZ77RNInlX8BQp8YKBIYA 7fHlV68TI1p/ybLs04VAmR3a0DMaavcXpTOF4Safe8HMmF/7oH5ib1c2kB21F9W0xuS+ b85WzRajGuux4wSvXeB2Gn81YQuLy0jsy4mAw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=n7AN1bJyHJk5sfHUJ6fzxxqgWrItx4XbdzRFXi/xBWQLJYvZVT3C5WgHoOYFE0KNxu 3qDtSdocgboRZ05JLxxesUWBRyZ7oJpLjcKcuN3pRC0O2OKvM6TtzD/sy9vOIbOqUuAt II+JtPF+U8uoWzLUYO/fJ69ndbZ5w5245RIUc= Received: by 10.216.205.213 with SMTP id j63mr864907weo.60.1295742494120; Sat, 22 Jan 2011 16:28:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.27.21 with HTTP; Sat, 22 Jan 2011 16:27:54 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Sat, 22 Jan 2011 16:27:54 -0800 Message-ID: To: Carl Reed Content-Type: multipart/alternative; boundary=0016e6dd892c151a76049a788f8c Cc: geopriv@ietf.org Subject: Re: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC3825bis) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 00:25:26 -0000 --0016e6dd892c151a76049a788f8c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here is a proposed revision of Section 2.3 to address the concern. Comment= s welcome. 2.3. Latitude and Longitude Fields The Latitude and Longitude values in this specification are encoded as 34 bit, twos complement, fixed point values with 9 integer bits and 25 fractional bits. The exact meaning of these values is determined by the datum; the description in this section applies to the datums defined in this document. This document uses the same definition for all datums it specifies. Latitude values encoded by the DHCP server MUST be constrained to the range from -90 to +90 degrees. Positive latitudes are north of the equator and negative latitudes are south of the equator. Longitude values encoded by the DHCP server MUST be normalized to the range from -180 to +180 degrees. Positive longitudes are east of the Prime Meridian (Greenwich) and negative (2s complement) longitudes are west of the Prime Meridian. Since it is required that server-provided values of Latitude and Longitude be constrained, location consumers encountering values outside the range MUST ignore the location data rather than attempting to normalize potentially invalid values. Location consumers SHOULD log the error. When encoding, Latitude and Longitude values are rounded to the nearest 34-bit binary representation. This imprecision is considered acceptable for the purposes to which this form is intended to be applied and is ignored when decoding. On Fri, Jan 21, 2011 at 2:11 PM, Carl Reed wrote= : > I would agree that if a value is outside the normal ranges for lat and > long, then there is an error somewhere in the workflow. As such, an error > message should be reported to the application or the user. Clamping to +9= 0 > is actually creating even more erroneous data. Thanks, Bernard. > > Carl > > > ----- Original Message ----- > *From:* Bernard Aboba > *To:* geopriv@ietf.org > *Sent:* Wednesday, January 19, 2011 9:50 AM > *Subject:* [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on > RFC3825bis) > > Ari Ker=E4nen's review (see below) included a comment on issues arising f= rom > clamping of > latitude/longitude values outside the range. > > Comments? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 2.3. Latitude and Longitude Fields > > Latitude values encoded by the DHCP server MUST be constrained to the > range from -90 to +90 degrees. Location consumers MUST be prepared > to normalize values outside this range. Values outside the range are > normalized by clamping [...] > > If the values MUST be within those boundaries, doesn't it mean that a > value that is out of the range is somewhat likely completely wrong (due > to a broken implementation) and thus it would make sense to ignore it > rather than try to normalize the value and make it appear as if it was > valid? I'm not sure if I'd like to be liberal in what I accept when it > comes to information that could literally be a matter of life and death. > > ------------------------------ > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > > --0016e6dd892c151a76049a788f8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here is a proposed revision of Section 2.3 to address the concern.=A0 Comme= nts welcome.

2.3.=A0 Latitude and Longitude Fields

=A0=A0 Th= e Latitude and Longitude values in this specification are encoded
=A0=A0= as 34 bit, twos complement, fixed point values with 9 integer bits
=A0=A0 and 25 fractional bits.=A0 The exact meaning of these values is
= =A0=A0 determined by the datum; the description in this section applies to<= br>=A0=A0 the datums defined in this document.=A0 This document uses the sa= me
=A0=A0 definition for all datums it specifies.

=A0=A0 Latitude values encoded by the DHCP server MUST be constrained t= o the
=A0=A0 range from -90 to +90 degrees.=A0 Positive latitudes are no= rth of the
=A0=A0 equator and negative latitudes are south of the equato= r.

=A0=A0 Longitude values encoded by the DHCP server MUST be normalized to th= e
=A0=A0 range from -180 to +180 degrees.=A0 Positive longitudes are eas= t of the
=A0=A0 Prime Meridian (Greenwich) and negative (2s complement) = longitudes
=A0=A0 are west of the Prime Meridian.

=A0=A0 Since it is required t= hat server-provided values of Latitude and
=A0=A0 Longitude be constrain= ed, location consumers encountering values
=A0=A0 outside the range MUST= ignore the location data rather than
=A0=A0 attempting to normalize potentially invalid values.=A0 Location
= =A0=A0 consumers SHOULD log the error.

=A0=A0 When encoding, Latitud= e and Longitude values are rounded to the
=A0=A0 nearest 34-bit binary r= epresentation.=A0 This imprecision is considered
=A0=A0 acceptable for the purposes to which this form is intended to be
= =A0=A0 applied and is ignored when decoding.


On Fri, Jan 21, 2011 at 2:11 PM, Carl Reed <creed@opengeospatial.org><= /span> wrote:
I would agree that if a value is outside the normal ranges for lat and= =20 long, then there is an error somewhere in the workflow. As such, an error= =20 message should be reported to the application or the user. Clamping to +90 = is=20 actually creating even more erroneous data. Thanks, Bernard.
=A0
Carl
=A0
----- Original Message -----
To: geopriv@ietf.org
Sent: Wednesday, January 19, 2011= 9:50=20 AM
Subject: [Geopriv] Proposed resol= ution of=20 Ticket #44 (Jari's DISCUSS on RFC3825bis)

Ari Ker=E4nen's=20 review (see below) included a comment on issues arising from clamping=20 of
latitude/longitude values outside the range.=A0

Comments?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
2.3.=20 Latitude and Longitude Fields

Latitude values=20 encoded by the DHCP server MUST be constrained to the
range from -90 t= o +90=20 degrees. Location consumers MUST be prepared
to normalize values outsi= de=20 this range. Values outside the range are
normalized by clamping=20 [...]

If the values MUS= T=20 be within those boundaries, doesn't it mean that a
value that is = out of=20 the range is somewhat likely completely wrong (due
to a broken=20 implementation) and thus it would make sense to ignore it
rather than= try=20 to normalize the value and make it appear as if it was
valid? I'm= not sure=20 if I'd like to be liberal in what I accept when it
comes to infor= mation=20 that could literally be a matter of life and death.


_______________________________________________
Geopriv mailing= =20 list
Geopriv@iet= f.org
https://www.ietf.org/mailman/listinfo/geopriv

--0016e6dd892c151a76049a788f8c-- From pigsotwing@gmail.com Sun Jan 23 02:47:35 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20823A684B for ; Sun, 23 Jan 2011 02:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyQrFZHqea-X for ; Sun, 23 Jan 2011 02:47:34 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 53A943A6849 for ; Sun, 23 Jan 2011 02:47:34 -0800 (PST) Received: by gxk27 with SMTP id 27so1137906gxk.31 for ; Sun, 23 Jan 2011 02:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=LA6PvliUODNV7n4mPhBL+K0t0mIhJhNRkixIX3OwZFs=; b=FgGY8exHqC6TNPoAHZoHLsEHGNozmbb7FEzwkghA3jTEsjCbbmqcc/b5il1XKG+RGz zaa/3EwsN4+mmL8RiN5S2LVFLzejMPO0tosFFRdk3ALJUw4NnVGXJm9Gq7WTsq00/zco Wo1S7dQBsDUMrEUuVMAJrZXqie63TS7wTrrv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; b=Yd8PwfYaWEcCAsz4doZ3DjrIT2tIFnMR8PzeAEbpDT+DXOrOO+V7wZgm4dDPVQNhAP dSmEO4MEewY/bhUhbKnX7SA2iG6JDC79zzD5KmSxZEcKx/BvZv/zTrQycUASb+OQPJz+ bqXQXCSKpAheliryikj/lHG/7OJCUl4ZSxWWE= Received: by 10.150.92.7 with SMTP id p7mr3076795ybb.232.1295779824473; Sun, 23 Jan 2011 02:50:24 -0800 (PST) MIME-Version: 1.0 Sender: pigsotwing@gmail.com Received: by 10.151.46.4 with HTTP; Sun, 23 Jan 2011 02:49:44 -0800 (PST) In-Reply-To: References: From: Andy Mabbett Date: Sun, 23 Jan 2011 10:49:44 +0000 X-Google-Sender-Auth: YgxhZMuH9yyO3yw0lxr7P4h9ehQ Message-ID: To: geopriv@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC3825bis) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 10:47:35 -0000 On 23 January 2011 00:27, Bernard Aboba wrote: > Here is a proposed revision of Section 2.3 to address the concern.=A0 Com= ments > welcome. > > 2.3.=A0 Latitude and Longitude Fields [...] > =A0=A0 Longitude values encoded by the DHCP server MUST be normalized to = the > =A0=A0 range from -180 to +180 degrees.=A0 Positive longitudes are east o= f the > =A0=A0 Prime Meridian (Greenwich) and negative (2s complement) longitudes > =A0=A0 are west of the Prime Meridian. geoURI (rfc5870) allows for a 'crs' (coordinate reference system) parameter so that, in future, coordinates on bodies such as The Moon or Mars can be expressed. Some such CRSs allow a longitude value range of 0-360, with no negative values, and of course these do not make reference to Greenwich. WGS84 is assumed as default, where no CRS is specified. It would be sensible to build in such future proofing - and consistency & compatibility - here, using the relevant sections of GeoURI (3.4.1, 3.4.2) as a model. See: also . --=20 Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk From bernard.aboba@gmail.com Sun Jan 23 08:22:13 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563433A690D for ; Sun, 23 Jan 2011 08:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwOep942sr+p for ; Sun, 23 Jan 2011 08:22:11 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 50CE03A690B for ; Sun, 23 Jan 2011 08:22:11 -0800 (PST) Received: by wwa36 with SMTP id 36so4119897wwa.13 for ; Sun, 23 Jan 2011 08:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vMEiuWSnUQf4XXPrja8rdzsuad1SyLcetSx/H2+fE6c=; b=rOrgnj+P6WwnwH+OgoVGdV2Ll4QGfWG8hhrr5NADEJM/wE3pj30/HNqkBBW/Xfsn6M boSoXf/XdEV32QXUtHj84We6CU8i9+aFv3SL2HiSSCKFoTexnb5PBKl5q5ILOD4Dt6cW xxnqb4DkutUtaIssdLe07DYDJpcnl4D57yHo8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=QlyNUaVirMW7QifbtfF786FjSO6cUzE2aQ1NiiXHOJnFnk/sZlxLQSIBgYZ0y8t0wY r/rjA4gcOK6dL7/dgaoslv+FT2rOZJP4+rQUxyPLnHT38z1IQF+4c9lCHlbTYYyGZ2YJ rrn5AKHR2l1FtoG75j2q/ntvskDH12duVh2VQ= Received: by 10.216.27.202 with SMTP id e52mr2559047wea.75.1295799902604; Sun, 23 Jan 2011 08:25:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.27.21 with HTTP; Sun, 23 Jan 2011 08:24:42 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Sun, 23 Jan 2011 08:24:42 -0800 Message-ID: To: Andy Mabbett Content-Type: multipart/alternative; boundary=00504502c70be50f72049a85ec60 Cc: geopriv@ietf.org Subject: Re: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC3825bis) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 16:22:13 -0000 --00504502c70be50f72049a85ec60 Content-Type: text/plain; charset=ISO-8859-1 How about this? 2.3. Latitude and Longitude Fields The Latitude and Longitude values in this specification are encoded as 34 bit, twos complement, fixed point values with 9 integer bits and 25 fractional bits. The exact meaning of these values is determined by the datum; the description in this section applies to the datums defined in this document. This document uses the same definition for all datums it specifies. When encoding, Latitude and Longitude values are rounded to the nearest 34-bit binary representation. This imprecision is considered acceptable for the purposes to which this form is intended to be applied and is ignored when decoding. Positive latitudes are north of the equator and negative latitudes are south of the equator. Positive longitudes are east of the Prime Meridian (Greenwich) and negative (2s complement) longitudes are west of the Prime Meridian. Within the coordinate reference systems defined in this document (Datum values 1-3), longitude values outside the range of -180 to 180 decimal degrees or latitude values outside the range of -90 to 90 degrees MUST be considered invalid. Server implementations SHOULD prevent the entry of invalid values within the selected coordinate reference system. Location consumers MUST ignore invalid location coordinates and SHOULD log invalid location errors. On Sun, Jan 23, 2011 at 2:49 AM, Andy Mabbett wrote: > On 23 January 2011 00:27, Bernard Aboba wrote: > > Here is a proposed revision of Section 2.3 to address the concern. > Comments > > welcome. > > > > 2.3. Latitude and Longitude Fields > > [...] > > > Longitude values encoded by the DHCP server MUST be normalized to the > > range from -180 to +180 degrees. Positive longitudes are east of the > > Prime Meridian (Greenwich) and negative (2s complement) longitudes > > are west of the Prime Meridian. > > geoURI (rfc5870) allows for a 'crs' (coordinate reference system) > parameter so that, in future, coordinates on bodies such as The Moon > or Mars can be expressed. Some such CRSs allow a longitude value range > of 0-360, with no negative values, and of course these do not make > reference to Greenwich. > > WGS84 is assumed as default, where no CRS is specified. > > It would be sensible to build in such future proofing - and > consistency & compatibility - here, using the relevant sections of > GeoURI (3.4.1, 3.4.2) as a model. > > See: > > > > > > also . > > -- > Andy Mabbett > @pigsonthewing > http://pigsonthewing.org.uk > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > --00504502c70be50f72049a85ec60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable How about this?

2.3.=A0 Latitude and Longitude Fields

=A0=A0 = The Latitude and Longitude values in this specification are encoded
=A0= =A0 as 34 bit, twos complement, fixed point values with 9 integer bits
= =A0=A0 and 25 fractional bits.=A0 The exact meaning of these values is
=A0=A0 determined by the datum; the description in this section applies to<= br>=A0=A0 the datums defined in this document.=A0 This document uses the sa= me
=A0=A0 definition for all datums it specifies.

=A0=A0 When enc= oding, Latitude and Longitude values are rounded to the
=A0=A0 nearest 34-bit binary representation.=A0 This imprecision is conside= red
=A0=A0 acceptable for the purposes to which this form is intended to= be
=A0=A0 applied and is ignored when decoding.

=A0=A0 Positive = latitudes are north of the equator and negative latitudes
=A0=A0 are south of the equator.=A0 Positive longitudes are east of the Pri= me
=A0=A0 Meridian (Greenwich) and negative (2s complement) longitudes a= re west
=A0=A0 of the Prime Meridian.

=A0=A0 Within the coordinat= e reference systems defined in this document
=A0=A0 (Datum values 1-3), longitude values outside the range of -180 to 18= 0
=A0=A0 decimal degrees or latitude values outside the range of -90 to = 90
=A0=A0 degrees MUST be considered invalid.=A0 Server implementations = SHOULD
=A0=A0 prevent the entry of invalid values within the selected coordinate=A0=A0 reference system.=A0 Location consumers MUST ignore invalid locati= on
=A0=A0 coordinates and SHOULD log invalid location errors.

On Sun, Jan 23, 2011 at 2:49 AM, Andy Mabbett <andy@pigsonthewing.org.uk> wrote:
On 23 January 2011 00:27, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> Here is a proposed revision of Section 2.3 to address the concern.=A0 = Comments
> welcome.
>
> 2.3.=A0 Latitude and Longitude Fields

[...]

> =A0=A0 Longitude values encoded by the DHCP server MUST be normalized = to the
> =A0=A0 range from -180 to +180 degrees.=A0 Positive longitudes are eas= t of the
> =A0=A0 Prime Meridian (Greenwich) and negative (2s complement) longitu= des
> =A0=A0 are west of the Prime Meridian.

geoURI (rfc5870) allows for a 'crs' (coordinate reference sys= tem)
parameter so that, in future, coordinates on bodies such as The Moon
or Mars can be expressed. Some such CRSs allow a longitude value range
of 0-360, with no negative values, and of course these do not make
reference to Greenwich.

WGS84 is assumed as default, where no CRS is specified.

It would be sensible to build in such future proofing - and
consistency & compatibility - here, using the relevant sections of
GeoURI (3.4.1, 3.4.2) as a model.

See:

<http://tools.ietf.org/html/rfc5870#section-3.4.1>

<http://tools.ietf.org/html/rfc5870#section-3.4.2>

also <http://en.wikipedia.org/wiki/Geo_URI>.

--
Andy Mabbett
@pigsonthewing
http://pigsonthew= ing.org.uk
__________________________________= _____________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

--00504502c70be50f72049a85ec60-- From acooper@cdt.org Mon Jan 24 05:11:29 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FB4E3A68C6 for ; Mon, 24 Jan 2011 05:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qdb8MrSwFjk5 for ; Mon, 24 Jan 2011 05:11:28 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 087663A6845 for ; Mon, 24 Jan 2011 05:11:27 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for geopriv@ietf.org; Mon, 24 Jan 2011 08:14:20 -0500 Message-Id: <18BBFD2E-DD16-47D6-96A3-EF712ACAD5B4@cdt.org> From: Alissa Cooper To: geopriv@ietf.org In-Reply-To: <020BBF4F-8D14-4EC1-831D-C6246D410045@cdt.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 24 Jan 2011 13:14:18 +0000 References: <020BBF4F-8D14-4EC1-831D-C6246D410045@cdt.org> X-Mailer: Apple Mail (2.936) Subject: Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 13:11:29 -0000 Thanks all, looks like we have consensus on this one. Alissa On Jan 12, 2011, at 2:18 PM, Alissa Cooper wrote: > Now that we have a milestone to "submit recommendations for LIS > discovery conducted by hosts behind residential gateways as > Informational," I'd like to call for WG adoption of draft-thomson- > geopriv-res-gw-lis-discovery-04. Please respond to the list by > January 19, 2011 about adopting this document as a WG item. > > Thanks, > Alissa > > > > > > > > > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > From rbarnes@bbn.com Mon Jan 24 13:38:48 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006823A694F for ; Mon, 24 Jan 2011 13:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDOXe1ZG0ypQ for ; Mon, 24 Jan 2011 13:38:46 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id D833F3A68EE for ; Mon, 24 Jan 2011 13:38:46 -0800 (PST) Received: from [128.89.254.150] (port=54078 helo=[10.45.1.166]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PhUAQ-000L3f-ED for geopriv@ietf.org; Mon, 24 Jan 2011 16:41:42 -0500 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Jan 2011 16:41:41 -0500 Message-Id: <73B6354E-59C7-4486-BBE4-27F823119952@bbn.com> To: geopriv@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Geopriv] "Do not track" header field X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 21:38:48 -0000 This will likely come up on the WEBSEC list as well, but I thought this = might be interesting to GEOPRIV folks: Mozilla and Google Chrome are proposing to extend browsers to send a "do = not track" HTTP header of the following form: X-Tracking-Choice: do-not-track This seems like another example of users sending along privacy = preferences with their data, just like PIDF-LO privacy rules, Creative = Commons licenses, etc. References: = =20 --Richard From Martin.Thomson@andrew.com Mon Jan 24 13:42:25 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394303A6967 for ; Mon, 24 Jan 2011 13:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buL7eE1tp1qb for ; Mon, 24 Jan 2011 13:42:24 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 20C5C3A68EE for ; Mon, 24 Jan 2011 13:42:24 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:25671 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S41854349Ab1AXVpT (ORCPT ); Mon, 24 Jan 2011 15:45:19 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 24 Jan 2011 15:45:16 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 25 Jan 2011 05:45:13 +0800 From: "Thomson, Martin" To: "Richard L. Barnes" , "geopriv@ietf.org" Date: Tue, 25 Jan 2011 05:45:09 +0800 Thread-Topic: [Geopriv] "Do not track" header field Thread-Index: Acu8D4KSixaUhuIXSu+BqmknOlt30gAAGNAw Message-ID: <8B0A9FCBB9832F43971E38010638454F03FEA148AA@SISPE7MB1.commscope.com> References: <73B6354E-59C7-4486-BBE4-27F823119952@bbn.com> In-Reply-To: <73B6354E-59C7-4486-BBE4-27F823119952@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Geopriv] "Do not track" header field X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 21:42:25 -0000 VGhleSBzaG91bGQgcmVhbGx5IGRyb3AgdGhlIFgtLi4uDQoNCk9uIDIwMTEtMDEtMjUgYXQgMDg6 NDE6NDEsIFJpY2hhcmQgTC4gQmFybmVzIHdyb3RlOg0KPiBUaGlzIHdpbGwgbGlrZWx5IGNvbWUg dXAgb24gdGhlIFdFQlNFQyBsaXN0IGFzIHdlbGwsIGJ1dCBJIHRob3VnaHQgdGhpcw0KPiBtaWdo dCBiZSBpbnRlcmVzdGluZyB0byBHRU9QUklWIGZvbGtzOg0KPiANCj4gTW96aWxsYSBhbmQgR29v Z2xlIENocm9tZSBhcmUgcHJvcG9zaW5nIHRvIGV4dGVuZCBicm93c2VycyB0byBzZW5kIGENCj4g ImRvIG5vdCB0cmFjayIgSFRUUCBoZWFkZXIgb2YgdGhlIGZvbGxvd2luZyBmb3JtOg0KPiBYLVRy YWNraW5nLUNob2ljZTogZG8tbm90LXRyYWNrDQo+IA0KPiBUaGlzIHNlZW1zIGxpa2UgYW5vdGhl ciBleGFtcGxlIG9mIHVzZXJzIHNlbmRpbmcgYWxvbmcgcHJpdmFjeQ0KPiBwcmVmZXJlbmNlcyB3 aXRoIHRoZWlyIGRhdGEsIGp1c3QgbGlrZSBQSURGLUxPIHByaXZhY3kgcnVsZXMsIENyZWF0aXZl DQo+IENvbW1vbnMgbGljZW5zZXMsIGV0Yy4NCj4gDQo+IFJlZmVyZW5jZXM6DQo+IDxodHRwOi8v Zmlyc3RwZXJzb25jb29raWUud29yZHByZXNzLmNvbS8yMDExLzAxLzIzL21vcmUtY2hvaWNlLWFu ZC0NCj4gY29udHJvbC1vdmVyLW9ubGluZS10cmFja2luZy8+DQo+IDxodHRwczovL2J1Z3ppbGxh Lm1vemlsbGEub3JnL3Nob3dfYnVnLmNnaT9pZD02MjgxOTc+DQo+IDxodHRwczovL2J1Z3ppbGxh Lm1vemlsbGEub3JnL3Nob3dfYnVnLmNnaT9pZD02MjgxOTg+DQo+IA0KPiAtLVJpY2hhcmQNCg0K From rbarnes@bbn.com Mon Jan 24 13:46:23 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8DA3A6995 for ; Mon, 24 Jan 2011 13:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INShRSRtrPFU for ; Mon, 24 Jan 2011 13:46:22 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A00F23A696E for ; Mon, 24 Jan 2011 13:46:22 -0800 (PST) Received: from [128.89.254.150] (port=54088 helo=[10.45.1.166]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PhUHm-000L8f-5Z; Mon, 24 Jan 2011 16:49:18 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03FEA148AA@SISPE7MB1.commscope.com> Date: Mon, 24 Jan 2011 16:49:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <177DBA32-0CAD-4163-8C3F-9862A05C817D@bbn.com> References: <73B6354E-59C7-4486-BBE4-27F823119952@bbn.com> <8B0A9FCBB9832F43971E38010638454F03FEA148AA@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1082) Cc: "geopriv@ietf.org" Subject: Re: [Geopriv] "Do not track" header field X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 21:46:23 -0000 If you look at the Bugzilla link, Julian has already suggested that this = go to WEBSEC for IETF approval and de-X-ification. --Richard On Jan 24, 2011, at 4:45 PM, Thomson, Martin wrote: > They should really drop the X-... >=20 > On 2011-01-25 at 08:41:41, Richard L. Barnes wrote: >> This will likely come up on the WEBSEC list as well, but I thought = this >> might be interesting to GEOPRIV folks: >>=20 >> Mozilla and Google Chrome are proposing to extend browsers to send a >> "do not track" HTTP header of the following form: >> X-Tracking-Choice: do-not-track >>=20 >> This seems like another example of users sending along privacy >> preferences with their data, just like PIDF-LO privacy rules, = Creative >> Commons licenses, etc. >>=20 >> References: >> > control-over-online-tracking/> >> >> >>=20 >> --Richard >=20 From James.Winterbottom@andrew.com Mon Jan 24 15:26:03 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 223AA3A6B3F for ; Mon, 24 Jan 2011 15:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDY741PB3Khu for ; Mon, 24 Jan 2011 15:26:02 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 1493E3A6B1F for ; Mon, 24 Jan 2011 15:26:02 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:53368 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S538368Ab1AXX25 (ORCPT ); Mon, 24 Jan 2011 17:28:57 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 24 Jan 2011 17:28:54 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 25 Jan 2011 07:28:51 +0800 From: "Winterbottom, James" To: "geopriv@ietf.org" Date: Tue, 25 Jan 2011 07:28:50 +0800 Thread-Topic: General consensus on Civic schema extensions Thread-Index: Acu8HnT6GIKunMoHSX6hdJ7qdl3DWA== Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120FDF20B5E@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC81880120FDF20B5ESISPE7MB1co_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: [Geopriv] General consensus on Civic schema extensions X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 23:26:03 -0000 --_000_5A55A45AE77F5941B18E5457ECAC81880120FDF20B5ESISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alissa and Richard, At the virtual interim, did we get general consensus from the WG that we ne= eded to have a milestone for a document describing how to do civic address = extensions? I did think that we had at least got that. If we did, can we ge= t a milestone added to the charter for it please? Given the relatively little opposition to the latest version of local-civic= , it also seems like we might be approaching consensus on a mechanism to me= et this milestone. Cheers James --_000_5A55A45AE77F5941B18E5457ECAC81880120FDF20B5ESISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alissa and Richard,

 

At the virtual interim, did we get general consensus fro= m the WG that we needed to have a milestone for a document describing how to do c= ivic address extensions? I did think that we had at least got that. If we did, c= an we get a milestone added to the charter for it please?

 

Given the relatively little opposition to the latest ver= sion of local-civic, it also seems like we might be approaching consensus on a mechanism to meet this milestone.

 

Cheers

James

 

 

 

--_000_5A55A45AE77F5941B18E5457ECAC81880120FDF20B5ESISPE7MB1co_-- From br@brianrosen.net Mon Jan 24 16:05:41 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6B53A69BC for ; Mon, 24 Jan 2011 16:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.867 X-Spam-Level: X-Spam-Status: No, score=-102.867 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGrB74sv3tzc for ; Mon, 24 Jan 2011 16:05:40 -0800 (PST) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.236]) by core3.amsl.com (Postfix) with ESMTP id 32A1E3A69B5 for ; Mon, 24 Jan 2011 16:05:40 -0800 (PST) X-ASG-Debug-ID: 1295914114-00f27e0f5a1cbf50001-fOFzYG Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id IDNumay19V4o3VwA; Mon, 24 Jan 2011 16:08:34 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.129.58]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PhWST-0005Ut-Tz; Mon, 24 Jan 2011 16:08:34 -0800 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: [Geopriv] General consensus on Civic schema extensions Content-Type: multipart/alternative; boundary=Apple-Mail-57--220675264 From: Brian Rosen In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120FDF20B5E@SISPE7MB1.commscope.com> Date: Mon, 24 Jan 2011 19:08:24 -0500 Message-Id: References: <5A55A45AE77F5941B18E5457ECAC81880120FDF20B5E@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1295914114 X-Barracuda-URL: http://64.34.111.236:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.53346 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Cc: "geopriv@ietf.org" Subject: Re: [Geopriv] General consensus on Civic schema extensions X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 00:05:41 -0000 --Apple-Mail-57--220675264 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am in favor of this. I have some issues with the current draft, but they are relatively = minor. I am comfortable with the basic idea. Brian On Jan 24, 2011, at 6:28 PM, Winterbottom, James wrote: > Hi Alissa and Richard, > =20 > At the virtual interim, did we get general consensus from the WG that = we needed to have a milestone for a document describing how to do civic = address extensions? I did think that we had at least got that. If we = did, can we get a milestone added to the charter for it please? > =20 > Given the relatively little opposition to the latest version of = local-civic, it also seems like we might be approaching consensus on a = mechanism to meet this milestone. > =20 > Cheers > James > =20 > =20 > =20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv --Apple-Mail-57--220675264 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I am in favor of this.

I have = some issues with the current draft, but they are relatively minor. =  I am comfortable with the basic = idea.

Brian

On Jan 24, = 2011, at 6:28 PM, Winterbottom, James wrote:

Hi Alissa and = Richard,
At = the virtual interim, did we get general consensus from the WG that we = needed to have a milestone for a document describing how to do civic = address extensions? I did think that we had at least got that. If we = did, can we get a milestone added to the charter for it = please?
 
Cheers
James
 
 
Geopriv@ietf.org
); Mon, 24 Jan 2011 18:43:20 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 24 Jan 2011 18:43:19 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 25 Jan 2011 08:43:16 +0800 From: "Thomson, Martin" To: "Richard L. Barnes" Date: Tue, 25 Jan 2011 08:43:14 +0800 Thread-Topic: [Geopriv] LIS discovery implementation thoughts Thread-Index: Acuzpj5MnGKFdRYfTQ2OzjWrqSQgxwIglmsg Message-ID: <8B0A9FCBB9832F43971E38010638454F03FEA148D3@SISPE7MB1.commscope.com> References: <5125204A-95F5-42E3-9EE5-DEAC5F3273A1@bbn.com> In-Reply-To: <5125204A-95F5-42E3-9EE5-DEAC5F3273A1@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "geopriv@ietf.org" Subject: Re: [Geopriv] LIS discovery implementation thoughts X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 00:40:26 -0000 V2hhdCBhcmUgeW91ciB0aG91Z2h0cyBvbiB0aGUgc2VydmVyIGF1dGhlbnRpY2F0aW9uIHJlcXVp cmVtZW50cz8gIE9yIGlzIHRoYXQgYW5vdGhlciBwYXJ0IG9mIHRoZSB2YWxpZGF0aW9uIHRoYXQg eW91IGFyZW4ndCBwZXJmb3JtaW5nPw0KDQpJIGhhdmUgdG8gY29tbWVuZCB0aGUgYXBwcm9hY2gg eW91IGFyZSB1c2luZy4gIEkgYWx3YXlzIGhvcGVkIHRoYXQgdGhpcyBpcyBob3cgZGlzY292ZXJ5 IHdvdWxkIGJlIGltcGxlbWVudGVkLg0KDQotLU1hcnRpbg0KDQpPbiAyMDExLTAxLTE0IGF0IDE1 OjQ3OjU4LCBSaWNoYXJkIEwuIEJhcm5lcyB3cm90ZToNCj4gT25lIGFkZGl0aW9uYWwgbm90ZTog T3VyIGNsaWVudCBpcyBub3QgdGVjaG5pY2FsbHkgY29tcGxpYW50IHdpdGggUkZDDQo+IDU5ODYs IHNpbmNlIGl0IGRvZXNuJ3QgdmFsaWRhdGUgdGhlIFVSSSB3aXRoIGEgSEVMRCByZXF1ZXN0Og0K PiAiDQo+ICAgIEEgRGV2aWNlIHRoYXQgZGlzY292ZXJzIGEgTElTIFVSSSBNVVNUIGF0dGVtcHQg dG8gdmVyaWZ5IHRoYXQgdGhlDQo+IExJUw0KPiAgICBpcyBhYmxlIHRvIHByb3ZpZGUgbG9jYXRp b24gaW5mb3JtYXRpb24uICBGb3IgdGhlIEhFTEQgcHJvdG9jb2wsIHRoZQ0KPiAgICBEZXZpY2Ug dmVyaWZpZXMgdGhlIFVSSSBieSBtYWtpbmcgYSBsb2NhdGlvbiByZXF1ZXN0IHRvIHRoZSBMSVMu DQo+ICINCj4gDQo+IC0tUmljaGFyZA0KPiANCj4gDQo+IE9uIEphbiAxMywgMjAxMSwgYXQgMTE6 NDUgUE0sIFJpY2hhcmQgTC4gQmFybmVzIHdyb3RlOg0KPiANCj4gPiBIZXkgYWxsLA0KPiA+DQo+ ID4gSnVzdCB3YW50ZWQgdG8gc2hhcmUgc29tZSBpbXByZXNzaW9ucyBvZiB0aGUgTElTIGRpc2Nv dmVyeSBwcm9jZXNzLA0KPiBpbmNsdWRpbmcgTkFUIHRyYXZlcnNhbCwgYmFzZWQgb24gb3VyIGV4 cGVyaWVuY2UgaW1wbGVtZW50aW5nIHRoaXMNCj4gZnVuY3Rpb24gaW4gdGhlIGlndGsgcHJvamVj dCBbMV0uICAoTm90ZTogVGhlIHRlY2huaXF1ZXMgaGVyZSBoYXZlbid0DQo+IHlldCBiZWVuIG1l cmdlZCBpbnRvIHRoZSBzb3VyY2Vmb3JnZSB2ZXJzaW9uLikNCj4gPg0KPiA+IFRoZSBiYXNpYyBm bG93LWNoYXJ0IGluIFJGQyA1OTg2IGlzIHByZXR0eSBlYXN5IHRvIGltcGxlbWVudCwNCj4gYWx0 aG91Z2ggaXQgd2Fzbid0IHJlYWxseSBjbGVhciB3aGF0IHRvIGRvIGZvciBzdGVwICgzKSwgIkNo ZWNrIFVSSSIsDQo+IGJleW9uZCB2ZXJpZnlpbmcgdGhhdCBpdCdzIGEgd2VsbC1mb3JtZWQgVVJJ LiAgSW4gcHNldWRvLWNvZGUsIHdlIGVuZGVkDQo+IHVwIHdpdGggc29tZXRoaW5nIGxpa2UgdGhp czoNCj4gPg0KPiA+IGZvcmVhY2ggKE5ldHdvcmtJbnRlcmZhY2UgaWZhY2UpIHsNCj4gPiAgICBE b21haW5JdGVyYXRvciBpdChpZmFjZSk7DQo+ID4gICAgd2hpbGUgKGl0Lmhhc05leHQoKSkgew0K PiA+ICAgICAgICBzdHJpbmcgbGlzVXJpID0gcGVyZm9ybURkZHMoaXQubmV4dCgpKTsNCj4gPiAJ aWYgKHZhbGlkKGxpc1VyaSkpIHsgcmV0dXJuIGxpc1VyaTsgfQ0KPiA+ICAgIH0NCj4gPiB9DQo+ ID4NCj4gPiBIZXJlIHRoZSBEb21haW5JdGVyYXRvciBzdXBwbGllcyB0aGUgZm9sbG93aW5nIGRv bWFpbnMsIGlmIHRoZXkgYXJlDQo+IGF2YWlsYWJsZToNCj4gPiAxLiBPcHRpb24gMjEzIFtOQjog Tm90IERIQ1B2NiBjYXBhYmxlXQ0KPiA+IDIuIE9wdGlvbiAxNQ0KPiA+DQo+ID4gVGhlIERvbWFp bkl0ZXJhdG9yIGNvbnN0cnVjdCBhbHNvIGFsbG93cyB1cyB0byBlYXNpbHkgZXh0ZW5kIHRoZQ0K PiBwcm9jZXNzIHRvIHN1cHBvcnQgTkFUIHRyYXZlcnNhbC4gIElmIG5laXRoZXIgb2YgdGhlIGFi b3ZlIG9wdGlvbnMNCj4gd29ya3MsIHRoZSBEb21haW5JdGVyYXRvciBsb29rcyBhdCB0aGUgSVAg YWRkcmVzcyBmb3IgdGhlIGludGVyZmFjZSwNCj4gYW5kIGlmIGl0J3MgcHJpdmF0ZSAoYW55IG9m IHRoZSBJQU5BIHJlc2VydmVkIHJhbmdlcyBbMl0pLCB0aGVuIGl0IGRvZXMNCj4gYSBTVFVOIHJl cXVlc3QgdG8gZmluZCBhIHB1YmxpYyBhZGRyZXNzLiAgVXNpbmcgZWl0aGVyIHRoZSBpbnRlcmZh Y2UNCj4gYWRkcmVzcyBvciB0aGUgU1RVTiBhZGRyZXNzLCBpdCB0aGVuIHByb3ZpZGVzIHRoZSBm b2xsb3dpbmcgZG9tYWluczoNCj4gPiAzLiBUaGUgcmV2ZXJzZSBkb21haW4NCj4gPiA0LiBUaGUg cmV2ZXJzZSBkb21haW4gd2l0aCB0aGUgZmlyc3QgbGFiZWwgZHJvcHBlZA0KPiA+IDUuIFRoZSBy ZXZlcnNlIGRvbWFpbiB3aXRoIHRoZSBmaXJzdCB0d28gbGFiZWxzIGRyb3BwZWQNCj4gPg0KPiA+ IFRoZSBlbnRpcmUgTElTIGRpc2NvdmVyeSBzZXJ2aWNlLCB3aGljaCBsaXN0ZW5zIGZvciBuZXR3 b3JrIGludGVyZmFjZQ0KPiBjaGFuZ2VzIGFuZCBlbWl0cyBhbGVydHMgd2hlbiBpdCBmaW5kcyBh IG5ldyBMSVMgVVJJLCByZXF1aXJlZCA1ODQNCj4gbGluZXMgb2YgQysrLiAgQSB2ZXJ5IGJhc2lj IFNUVU4gY2xpZW50IHdhcyBhbm90aGVyIDI5My4NCj4gPg0KPiA+IFNvIGluIGEgbnV0c2hlbGws IGV4dGVuZGluZyBhIGNsaWVudCBmcm9tIFJGQyA1OTg2IHRvIGRyYWZ0LXRob21zb24tDQo+IGdl b3ByaXYtcmVzLWd3LWxpcy1kaXNjb3Zlcnkgd2FzIHByZXR0eSB0cml2aWFsLCBqdXN0IGEgbWF0 dGVyIG9mDQo+IGFkZGluZyBhIGZldyBkb21haW5zIHRvIHRoZSBzZWFyY2ggbGlzdC4gIFdlIGhv cGUgdG8gaGF2ZSB0aGUgY29kZQ0KPiBwb3N0ZWQgdG8gdGhlIGlndGsgc2l0ZSBzb29uOyBpZiB5 b3UncmUgaW50ZXJlc3RlZCBpbiBhbiBhZHZhbmNlIGNvcHksDQo+IGxldCBtZSBrbm93IGFuZCBJ IGNhbiBzZW5kIHlvdSBhbiBpbnRlcmltIHNuYXBzaG90Lg0KPiA+DQo+ID4gLS1SaWNoYXJkDQo+ ID4NCj4gPg0KPiA+IFsxXSA8aHR0cDovL2lndGsuc291cmNlZm9yZ2UubmV0Lz4NCj4gPiBbMl0g PGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaXB2NC1hZGRyZXNzLXNwYWNlL2lwdjQt YWRkcmVzcy0NCj4gc3BhY2UueG1sPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gR2VvcHJpdiBtYWlsaW5nIGxpc3QNCj4gPiBHZW9wcml2 QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9w cml2DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBHZW9wcml2IG1haWxpbmcgbGlzdA0KPiBHZW9wcml2QGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VvcHJpdg0KDQoNCg== From rbarnes@bbn.com Mon Jan 24 18:52:04 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366873A6A16 for ; Mon, 24 Jan 2011 18:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXK12Zfw4kFY for ; Mon, 24 Jan 2011 18:52:03 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E28923A6A0E for ; Mon, 24 Jan 2011 18:52:02 -0800 (PST) Received: from [128.89.255.108] (port=55037 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PhZ3a-000O9y-CQ; Mon, 24 Jan 2011 21:54:58 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03FEA148D3@SISPE7MB1.commscope.com> Date: Mon, 24 Jan 2011 21:54:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5125204A-95F5-42E3-9EE5-DEAC5F3273A1@bbn.com> <8B0A9FCBB9832F43971E38010638454F03FEA148D3@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1082) Cc: "geopriv@ietf.org" Subject: Re: [Geopriv] LIS discovery implementation thoughts X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 02:52:04 -0000 I'm assuming you mean the authentication against the input to the = U-NAPTR process? =20 The way we have things structured, we have separate modules that = communicate via pub/sub: measurements ---+ +--> held --> zeus-locator [=3D=3D application API] lis-discovery ---+=20 (DHCP location is parallel to the HELD module, and also feeds the = application API.) The messages that the the lis-discovery module emits are of the form: struct LisDiscoveryInfo { std::string lisUri; std::string domain; } So: 1. We could in principle do authentication against the input to U-NAPTR = -- if it's supported by the underlying HTTP library. Right now, we're = using libcurl, which does not support changes to the name that it = authenticates. 2. At the same time, it would be awkward for the lis-discovery module to = do HELD requests required to "verify that the LIS is able to provide = location information". It's not impossible (there's actually a separate = HeldRequest object (think like XMLHttpRequest) that could be used), but = it would feel kind of like a circular dependency. --Richard On Jan 24, 2011, at 7:43 PM, Thomson, Martin wrote: > What are your thoughts on the server authentication requirements? Or = is that another part of the validation that you aren't performing? >=20 > I have to commend the approach you are using. I always hoped that = this is how discovery would be implemented. >=20 > --Martin >=20 > On 2011-01-14 at 15:47:58, Richard L. Barnes wrote: >> One additional note: Our client is not technically compliant with RFC >> 5986, since it doesn't validate the URI with a HELD request: >> " >> A Device that discovers a LIS URI MUST attempt to verify that the >> LIS >> is able to provide location information. For the HELD protocol, = the >> Device verifies the URI by making a location request to the LIS. >> " >>=20 >> --Richard >>=20 >>=20 >> On Jan 13, 2011, at 11:45 PM, Richard L. Barnes wrote: >>=20 >>> Hey all, >>>=20 >>> Just wanted to share some impressions of the LIS discovery process, >> including NAT traversal, based on our experience implementing this >> function in the igtk project [1]. (Note: The techniques here haven't >> yet been merged into the sourceforge version.) >>>=20 >>> The basic flow-chart in RFC 5986 is pretty easy to implement, >> although it wasn't really clear what to do for step (3), "Check URI", >> beyond verifying that it's a well-formed URI. In pseudo-code, we = ended >> up with something like this: >>>=20 >>> foreach (NetworkInterface iface) { >>> DomainIterator it(iface); >>> while (it.hasNext()) { >>> string lisUri =3D performDdds(it.next()); >>> if (valid(lisUri)) { return lisUri; } >>> } >>> } >>>=20 >>> Here the DomainIterator supplies the following domains, if they are >> available: >>> 1. Option 213 [NB: Not DHCPv6 capable] >>> 2. Option 15 >>>=20 >>> The DomainIterator construct also allows us to easily extend the >> process to support NAT traversal. If neither of the above options >> works, the DomainIterator looks at the IP address for the interface, >> and if it's private (any of the IANA reserved ranges [2]), then it = does >> a STUN request to find a public address. Using either the interface >> address or the STUN address, it then provides the following domains: >>> 3. The reverse domain >>> 4. The reverse domain with the first label dropped >>> 5. The reverse domain with the first two labels dropped >>>=20 >>> The entire LIS discovery service, which listens for network = interface >> changes and emits alerts when it finds a new LIS URI, required 584 >> lines of C++. A very basic STUN client was another 293. >>>=20 >>> So in a nutshell, extending a client from RFC 5986 to draft-thomson- >> geopriv-res-gw-lis-discovery was pretty trivial, just a matter of >> adding a few domains to the search list. We hope to have the code >> posted to the igtk site soon; if you're interested in an advance = copy, >> let me know and I can send you an interim snapshot. >>>=20 >>> --Richard >>>=20 >>>=20 >>> [1] >>> [2] = > space.xml> >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www.ietf.org/mailman/listinfo/geopriv >>=20 >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv >=20 >=20 From Hannes.Tschofenig@gmx.net Tue Jan 25 00:41:46 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7AA3A63D2 for ; Tue, 25 Jan 2011 00:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaLhduR+IJ6Z for ; Tue, 25 Jan 2011 00:41:45 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 253D93A6B81 for ; Tue, 25 Jan 2011 00:41:44 -0800 (PST) Received: (qmail invoked by alias); 25 Jan 2011 08:44:39 -0000 Received: from unknown (EHLO [10.255.133.16]) [192.100.123.77] by mail.gmx.net (mp007) with SMTP; 25 Jan 2011 09:44:39 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX188r2s8ApE8x0JOure5JHSUxoLIOIFEC+gsfs5QWj 0X69HbGYA9oTV1 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <020BBF4F-8D14-4EC1-831D-C6246D410045@cdt.org> Date: Tue, 25 Jan 2011 10:43:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <261D150A-01D4-4444-80FE-A5BBF1DE7174@gmx.net> References: <020BBF4F-8D14-4EC1-831D-C6246D410045@cdt.org> To: Alissa Cooper X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: geopriv@ietf.org, Hannes Tschofenig Subject: Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 08:41:46 -0000 I argued that the chosen approach is not the one I would like to see = moving forward, and the description in the document replicates text we = already have in other documents.=20 In that sense I do not want this document as a WG item.=20 On Jan 12, 2011, at 4:18 PM, Alissa Cooper wrote: > Now that we have a milestone to "submit recommendations for LIS = discovery conducted by hosts behind residential gateways as = Informational," I'd like to call for WG adoption of = draft-thomson-geopriv-res-gw-lis-discovery-04. Please respond to the = list by January 19, 2011 about adopting this document as a WG item. >=20 > Thanks, > Alissa >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From Hannes.Tschofenig@gmx.net Tue Jan 25 00:41:48 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C04C3A6B8C for ; Tue, 25 Jan 2011 00:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.828 X-Spam-Level: X-Spam-Status: No, score=-101.828 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ++IU5dpVLG for ; Tue, 25 Jan 2011 00:41:47 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 15D113A63D2 for ; Tue, 25 Jan 2011 00:41:46 -0800 (PST) Received: (qmail invoked by alias); 25 Jan 2011 08:44:42 -0000 Received: from unknown (EHLO [10.255.133.16]) [192.100.123.77] by mail.gmx.net (mp007) with SMTP; 25 Jan 2011 09:44:42 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+1TJsRIce1SK0h/FPMj/OhMiZzcgSECTOBn0i5KC J+rLLmvdem+zAR Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/html; charset=us-ascii X-Apple-Base-Url: x-msg://161/ X-Apple-Mail-Plain-Text-Draft: yes From: Hannes Tschofenig X-Apple-Mail-Remote-Attachments: YES In-Reply-To: <020BBF4F-8D14-4EC1-831D-C6246D410045@cdt.org> X-Apple-Windows-Friendly: 1 Date: Tue, 25 Jan 2011 10:43:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9328D323-46FD-4AED-B334-555423787924@gmx.net> References: <020BBF4F-8D14-4EC1-831D-C6246D410045@cdt.org> X-Uniform-Type-Identifier: com.apple.mail-draft To: Alissa Cooper X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: geopriv@ietf.org, Hannes Tschofenig Subject: Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 08:41:48 -0000 I argued that the chosen approach is not the one I = would like to see moving forward, and the description in the document = replicates text we already have in other documents.

In that = sense I do not want this document as a WG item.

On Jan 12, 2011, = at 4:18 PM, Alissa Cooper wrote:

Now = that we have a milestone to "submit recommendations for LIS discovery = conducted by hosts behind residential gateways as Informational," I'd = like to call for WG adoption of = draft-thomson-geopriv-res-gw-lis-discovery-04. Please respond to the = list by January 19, 2011 about adopting this document as a WG = item.

Thanks,
Alissa











_______________________________________________
Geopriv mailing = list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

= From acooper@cdt.org Tue Jan 25 01:44:29 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BC0A3A6A85 for ; Tue, 25 Jan 2011 01:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-5WtAZinEbU for ; Tue, 25 Jan 2011 01:44:28 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id E9A5F3A63EB for ; Tue, 25 Jan 2011 01:44:27 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 25 Jan 2011 04:47:20 -0500 Message-Id: <0FEB4AD6-45A1-47C8-9548-DB4007C4623B@cdt.org> From: Alissa Cooper To: Richard L. Barnes In-Reply-To: <177DBA32-0CAD-4163-8C3F-9862A05C817D@bbn.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Jan 2011 09:47:17 +0000 References: <73B6354E-59C7-4486-BBE4-27F823119952@bbn.com> <8B0A9FCBB9832F43971E38010638454F03FEA148AA@SISPE7MB1.commscope.com> <177DBA32-0CAD-4163-8C3F-9862A05C817D@bbn.com> X-Mailer: Apple Mail (2.936) Cc: "geopriv@ietf.org" , "Thomson, Martin" Subject: Re: [Geopriv] "Do not track" header field X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 09:44:29 -0000 And I've been talking to Sid at Mozilla about getting a draft ready before IETF 80. On Jan 24, 2011, at 9:49 PM, Richard L. Barnes wrote: > If you look at the Bugzilla link, Julian has already suggested that > this go to WEBSEC for IETF approval and de-X-ification. > --Richard > > > On Jan 24, 2011, at 4:45 PM, Thomson, Martin wrote: > >> They should really drop the X-... >> >> On 2011-01-25 at 08:41:41, Richard L. Barnes wrote: >>> This will likely come up on the WEBSEC list as well, but I thought >>> this >>> might be interesting to GEOPRIV folks: >>> >>> Mozilla and Google Chrome are proposing to extend browsers to send a >>> "do not track" HTTP header of the following form: >>> X-Tracking-Choice: do-not-track >>> >>> This seems like another example of users sending along privacy >>> preferences with their data, just like PIDF-LO privacy rules, >>> Creative >>> Commons licenses, etc. >>> >>> References: >>> >> control-over-online-tracking/> >>> >>> >>> >>> --Richard >> > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > From rbarnes@bbn.com Tue Jan 25 02:25:16 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 202B43A6827; Tue, 25 Jan 2011 02:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9FW0ZCW7MUe; Tue, 25 Jan 2011 02:25:13 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 68FFE3A6B80; Tue, 25 Jan 2011 02:25:13 -0800 (PST) Received: from [128.89.255.108] (port=55956 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Phg89-000NQq-Du; Tue, 25 Jan 2011 05:28:10 -0500 From: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=Apple-Mail-7--183496333 Date: Tue, 25 Jan 2011 05:28:03 -0500 References: <006b01cbbc71$5eb4e1b0$1c1ea510$@org> To: ecrit , geopriv@ietf.org, 802-23 Emergency Services Message-Id: <897B042D-F8A2-4A12-9DCA-A588516C6D6B@bbn.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Geopriv] ESW8 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 10:25:16 -0000 --Apple-Mail-7--183496333 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Dear all, > =20 > We are delighted to invite you to the 8th Emergency Services Workshop = (ESW8). The ESW8, an international emergency service standards = coordination group conference, will be held in Budapest on 13-15 April = 2011. > =20 > This year, the event is hosted by EENA, the European Emergency Number = Association, and it is integrated in the programme of the EU Emergency = Services Workshop that gathers emergency services, public authorities = and industry representatives. This 3-day conference aims at fostering = sharing of best practices between the relevant stakeholders. > =20 > The ESW8 is indicated as =93Next Generation Emergency Services (ESW8)=94= in the programme of the event. Participants are however welcome to = attend the entire 3-day event. As usual, special attention will be paid = to Next Generation, IP-based emergency calling, including: > =A7 An introduction to Next-Generation emergency services intended to = provide a basic understanding of IP-based emergency calling to public = safety representatives > =A7 A session on testing and deployment elements with a focus on some = relevant projects and initiatives > =A7 A discussion on standards aiming at coordinating between = different specific efforts and standards development organisations = (SDOs) > =20 > The Workshop will welcome around 200 participants, including around = 100 emergency services and public authorities=92 representatives. > =20 > Since the number of attendees is limited, we invite you to register to = the event as soon as possible. > =20 > More information, programme and registration: > http://www.emergency-services-coordination.info/esw8.html > =20 > Kind regards, > =20 > =20 > Gary MACHADO > Executive Director > European Emergency Number Association - EENA112 > Avenue Louise 262 > 1050 Brussels > Belgium > Tel: +32 (0)2 53 49 789 > www.eena.org > Privileged / confidential information may be contained in this mail = and is intended only for the use of the addressee. If you are not the = addressee, or person responsible for delivering to the person addressed, = you may not copy or deliver this to anyone else. If you receive this = mail by mistake, please notify us immediately by telephone. Thank you. > =20 > =20 --Apple-Mail-7--183496333 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Dear = all,
We are delighted to invite you to = the 8th Emergency Services Workshop = (ESW8). The ESW8, an international emergency service standards = coordination group conference, will be held in Budapest on 13-15 April = 2011.
 
 EU Emergency Services = Workshop that = gathers emergency services, public authorities and industry = representatives. This 3-day conference aims at fostering sharing of best = practices between the relevant stakeholders.
The ESW8 is indicated as =93Next Generation = Emergency Services (ESW8)=94 in the programme of the = event. Participants are however welcome to attend the entire 3-day = event. As usual, special attention will be paid to Next Generation, = IP-based emergency calling, including:
=A7  An = introduction to Next-Generation emergency services intended to provide a = basic understanding of IP-based emergency calling to public safety = representatives
=A7 A session = on testing and deployment elements with a focus on some relevant = projects and initiatives
=A7 A = discussion on standards aiming at coordinating between different = specific efforts and standards development organisations = (SDOs)
 
The = Workshop will welcome around 200 participants, including around 100 = emergency services and public authorities=92 = representatives.
 
More information, programme and = registration:
European Emergency = Number Association - EENA112
Avenue Louise 262
1050 = Brussels
Belgium
Tel: +32 (0)2 53 49 789
www.eena.orgPrivileged / = confidential information may be contained in this mail and is intended = only for the use of the addressee. If you are not the addressee, or = person responsible for delivering to the person addressed, you may not = copy or deliver this to anyone else. If you receive this mail by = mistake, please notify us immediately by telephone. Thank = you.
>=20 >> Thanks, >> Alissa >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From creed@opengeospatial.org Tue Jan 25 07:44:52 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6DA53A6805 for ; Tue, 25 Jan 2011 07:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.063 X-Spam-Level: * X-Spam-Status: No, score=1.063 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmNYxj-FRJ9H for ; Tue, 25 Jan 2011 07:44:51 -0800 (PST) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by core3.amsl.com (Postfix) with ESMTP id 76A813A67FF for ; Tue, 25 Jan 2011 07:44:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id E33355A1D4; Tue, 25 Jan 2011 10:47:48 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (mail.opengeospatial.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoPtFqFKysRu; Tue, 25 Jan 2011 10:47:48 -0500 (EST) Received: from CarlandSusieOf (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id 0303E5A1DE; Tue, 25 Jan 2011 10:47:47 -0500 (EST) Message-ID: From: "Carl Reed" To: , "Pomfret, Kevin D." Date: Tue, 25 Jan 2011 08:40:55 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02FA_01CBBC6B.9515AF60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Subject: Re: [Geopriv] Want to Track People? There's an App for That X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 15:44:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02FA_01CBBC6B.9515AF60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.technologyreview.com/computing/27128/?nlid=3D4040&a=3Df Just a matter of time until the consumer begins to realize the = implications to their privacy Carl Reed, PhD CTO and Executive Director Specification Program Open Geospatial Consortium www.opengeospatial.org The OGC: Making Location Count! --------------------- This communication, including attachments, is for the exclusive use of = addressee and may contain proprietary, confidential or privileged = information. If you are not the intended recipient, any use, copying, = disclosure, dissemination or distribution is strictly prohibited. If you = are not the intended recipient, please notify the sender immediately by = return email and delete this communication and destroy all copies. "The important thing is not to stop questioning." -- Albert Einstein=20 "Security is mostly a superstition. It does not exist in nature. Life is = either a daring adventure or nothing." -- Helen Keller ------=_NextPart_000_02FA_01CBBC6B.9515AF60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.technologyreview.com/computing/27128/?nlid=3D4040&a= =3Df
 
Just a matter of time until the consumer begins to realize the = implications=20 to their privacy
 
Carl Reed, PhD
CTO and Executive Director Specification = Program
Open=20 Geospatial Consortium
www.opengeospatial.org
 
The OGC: Making Location Count!
 
---------------------
 
This communication, including attachments, is for the exclusive use = of=20 addressee and may contain proprietary, confidential or privileged = information.=20 If you are not the intended recipient, any use, copying, disclosure,=20 dissemination or distribution is strictly prohibited. If you are not the = intended recipient, please notify the sender  immediately by return = email=20 and delete this communication and destroy all copies.
 
"The important thing is not to stop questioning." -- Albert = Einstein=20
"Security is mostly a superstition. It does not exist in nature. = Life is=20 either a daring adventure or nothing." -- Helen Keller =
------=_NextPart_000_02FA_01CBBC6B.9515AF60-- From trac@tools.ietf.org Tue Jan 25 16:04:58 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02533A68A4 for ; Tue, 25 Jan 2011 16:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ajfDl0Yz9Xx for ; Tue, 25 Jan 2011 16:04:57 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D08413A68E7 for ; Tue, 25 Jan 2011 16:04:57 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PhsvU-0002CM-TP; Tue, 25 Jan 2011 16:07:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "geopriv issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: geopriv Date: Wed, 26 Jan 2011 00:07:56 -0000 X-URL: http://tools.ietf.org/geopriv/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/geopriv/trac/ticket/44#comment:2 Message-ID: <076.296deca7ff28b8fa9e9ace49dfef1a04@tools.ietf.org> References: <067.a9490063a52d2f0d82c4d5f06371498f@tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <067.a9490063a52d2f0d82c4d5f06371498f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, geopriv@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: geopriv@ietf.org Subject: Re: [Geopriv] [geopriv] rfc3825bis #44 (closed): Jari's DISCUSS X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 00:04:58 -0000 #44: Jari's DISCUSS Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: To address the concern bout clamping versus ignoring potential invalid lat/long values, the proposal is to replace the text of Section 2.3 with the following: 2.3. Latitude and Longitude Fields The Latitude and Longitude values in this specification are encoded as 34 bit, twos complement, fixed point values with 9 integer bits and 25 fractional bits. The exact meaning of these values is determined by the datum; the description in this section applies to the datums defined in this document. This document uses the same definition for all datums it specifies. When encoding, Latitude and Longitude values are rounded to the nearest 34-bit binary representation. This imprecision is considered acceptable for the purposes to which this form is intended to be applied and is ignored when decoding. Positive latitudes are north of the equator and negative latitudes are south of the equator. Positive longitudes are east of the Prime Meridian (Greenwich) and negative (2s complement) longitudes are west of the Prime Meridian. Within the coordinate reference systems defined in this document (Datum values 1-3), longitude values outside the range of -180 to 180 decimal degrees or latitude values outside the range of -90 to 90 degrees MUST be considered invalid. Server implementations SHOULD prevent the entry of invalid values within the selected coordinate reference system. Location consumers MUST ignore invalid location coordinates and SHOULD log invalid location errors. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: bernard_aboba@… Type: defect | Status: closed Priority: blocker | Milestone: draft-ietf-geopriv-3825bis Component: rfc3825bis | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: geopriv From Internet-Drafts@ietf.org Tue Jan 25 16:15:02 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0A143A68BD; Tue, 25 Jan 2011 16:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRtcuNmFtApg; Tue, 25 Jan 2011 16:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229753A68AB; Tue, 25 Jan 2011 16:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110126001502.22964.88759.idtracker@localhost> Date: Tue, 25 Jan 2011 16:15:02 -0800 Cc: geopriv@ietf.org Subject: [Geopriv] I-D Action:draft-ietf-geopriv-rfc3825bis-16.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 00:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Geographic Location/Privacy Working Group of the IETF. Title : Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information Author(s) : J. Polk, et al. Filename : draft-ietf-geopriv-rfc3825bis-16.txt Pages : 33 Date : 2011-01-25 This document specifies Dynamic Host Configuration Protocol Options (both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes Latitude, Longitude, and Altitude, with resolution or uncertainty indicators for each. Separate parameters indicate the reference datum for each of these values. This document obsoletes RFC 3825. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-rfc3825bis-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-geopriv-rfc3825bis-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-25160549.I-D@ietf.org> --NextPart-- From pigsotwing@gmail.com Wed Jan 26 08:10:10 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E50D3A6774 for ; Wed, 26 Jan 2011 08:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.644, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUaGvQ79sxay for ; Wed, 26 Jan 2011 08:10:07 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id DF4013A6765 for ; Wed, 26 Jan 2011 08:10:06 -0800 (PST) Received: by yxt33 with SMTP id 33so196263yxt.31 for ; Wed, 26 Jan 2011 08:13:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=WOHypFFI7iU13cJLIExV6MEUZHWNFieh/4o34sHpZCA=; b=W3w1xpqhTqvfyiebbG+rW3sWAlaZeV3J06ZR/nCq9nmEAaTis0Dtq1GmoTtT1pLRQV O753jZYgXK73pUUB6kox69E/3zvdToqx3Rr0ZvqMyssGQnylZeichbUZLFKPdaBVoaDp FbXydePlv9RnWdWhzYoP0O2uB4MB0E2KTFw+w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=vcIS9VhmScW3c8T3oYTI+fpbO/IYF5VHowR+69JnprInV+JBL4qxzRozxW0TYOeJ+L jj0U2aHsCkVApxmwGVPhF2BIcsoHp8/LnkCQrHp/wX+eJuX6y7s2TVvSd/8QR1hn1DMa Me34Xm4SUDsOAWEhUxwiTTMkXC/SuyK4euNhQ= Received: by 10.150.92.7 with SMTP id p7mr1365232ybb.232.1296058387231; Wed, 26 Jan 2011 08:13:07 -0800 (PST) MIME-Version: 1.0 Sender: pigsotwing@gmail.com Received: by 10.151.46.4 with HTTP; Wed, 26 Jan 2011 08:12:27 -0800 (PST) In-Reply-To: References: From: Andy Mabbett Date: Wed, 26 Jan 2011 16:12:27 +0000 X-Google-Sender-Auth: b7N_4J6gEl9PN9fiJWoZ-HBRgEA Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org Subject: Re: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC3825bis) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 16:10:10 -0000 Thank you, but I do think the the GeoURL approach: 1) Any recognised CRS may be used 2) For each a set of rules must be provided 3) The default CRS is WGS84 4) Here are the rules for WGS84... 5) No other CRS is recognised, yet. using wording based on that in the cited section of the GeoURL specifcation would be better, more compatible (not least with GeoURL), and more future proof; for the reasons given previously. On 23 January 2011 16:24, Bernard Aboba wrote: > How about this? > > 2.3.=A0 Latitude and Longitude Fields > > =A0=A0 The Latitude and Longitude values in this specification are encode= d > =A0=A0 as 34 bit, twos complement, fixed point values with 9 integer bits > =A0=A0 and 25 fractional bits.=A0 The exact meaning of these values is > =A0=A0 determined by the datum; the description in this section applies t= o > =A0=A0 the datums defined in this document.=A0 This document uses the sam= e > =A0=A0 definition for all datums it specifies. > > =A0=A0 When encoding, Latitude and Longitude values are rounded to the > =A0=A0 nearest 34-bit binary representation.=A0 This imprecision is consi= dered > =A0=A0 acceptable for the purposes to which this form is intended to be > =A0=A0 applied and is ignored when decoding. > > =A0=A0 Positive latitudes are north of the equator and negative latitudes > =A0=A0 are south of the equator.=A0 Positive longitudes are east of the P= rime > =A0=A0 Meridian (Greenwich) and negative (2s complement) longitudes are w= est > =A0=A0 of the Prime Meridian. > > =A0=A0 Within the coordinate reference systems defined in this document > =A0=A0 (Datum values 1-3), longitude values outside the range of -180 to = 180 > =A0=A0 decimal degrees or latitude values outside the range of -90 to 90 > =A0=A0 degrees MUST be considered invalid.=A0 Server implementations SHOU= LD > =A0=A0 prevent the entry of invalid values within the selected coordinate > =A0=A0 reference system.=A0 Location consumers MUST ignore invalid locati= on > =A0=A0 coordinates and SHOULD log invalid location errors. > > > On Sun, Jan 23, 2011 at 2:49 AM, Andy Mabbett > wrote: >> >> On 23 January 2011 00:27, Bernard Aboba wrote: >> > Here is a proposed revision of Section 2.3 to address the concern. >> > Comments >> > welcome. >> > >> > 2.3.=A0 Latitude and Longitude Fields >> >> [...] >> >> > =A0=A0 Longitude values encoded by the DHCP server MUST be normalized = to the >> > =A0=A0 range from -180 to +180 degrees.=A0 Positive longitudes are eas= t of the >> > =A0=A0 Prime Meridian (Greenwich) and negative (2s complement) longitu= des >> > =A0=A0 are west of the Prime Meridian. >> >> geoURI (rfc5870) allows for a 'crs' (coordinate reference system) >> parameter so that, in future, coordinates on bodies such as The Moon >> or Mars can be expressed. Some such CRSs allow a longitude value range >> of 0-360, with no negative values, and of course these do not make >> reference to Greenwich. >> >> WGS84 is assumed as default, where no CRS is specified. >> >> It would be sensible to build in such future proofing - and >> consistency & compatibility - here, using the relevant sections of >> GeoURI (3.4.1, 3.4.2) as a model. >> >> See: >> >> >> >> >> >> also . >> >> -- >> Andy Mabbett >> @pigsonthewing >> http://pigsonthewing.org.uk >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > > --=20 Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk From rbarnes@bbn.com Wed Jan 26 08:25:25 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01CC43A6803 for ; Wed, 26 Jan 2011 08:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKtHaZqeB0Y3 for ; Wed, 26 Jan 2011 08:25:23 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 95F3C3A67D6 for ; Wed, 26 Jan 2011 08:25:23 -0800 (PST) Received: from [128.89.255.99] (port=65293 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pi8EI-000P5b-HU; Wed, 26 Jan 2011 11:28:23 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 26 Jan 2011 11:28:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Mabbett X-Mailer: Apple Mail (2.1082) Cc: geopriv@ietf.org, Bernard Aboba Subject: Re: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC3825bis) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 16:25:25 -0000 Note this phrase: "The exact meaning of these values determined by the datum; the = description in this section applies to the datums defined in this = document. " So the approach you're proposing is already there. (1) You can use any = datum value you want, but (2) you have to define it. (4) This document = defines the rules for the datums in the document (including WGS84).=20 (3) and (5) are noops. There is no default CRS, because it is always = specified -- the datum bits always have a value. There are other datums = besides WGS84 (see the IANA registry). --Richard =20 On Jan 26, 2011, at 11:12 AM, Andy Mabbett wrote: > Thank you, but I do think the the GeoURL approach: >=20 > 1) Any recognised CRS may be used > 2) For each a set of rules must be provided > 3) The default CRS is WGS84 > 4) Here are the rules for WGS84... > 5) No other CRS is recognised, yet. >=20 > using wording based on that in the cited section of the GeoURL > specifcation would be better, more compatible (not least with GeoURL), > and more future proof; for the reasons given previously. >=20 > On 23 January 2011 16:24, Bernard Aboba = wrote: >> How about this? >>=20 >> 2.3. Latitude and Longitude Fields >>=20 >> The Latitude and Longitude values in this specification are = encoded >> as 34 bit, twos complement, fixed point values with 9 integer bits >> and 25 fractional bits. The exact meaning of these values is >> determined by the datum; the description in this section applies = to >> the datums defined in this document. This document uses the same >> definition for all datums it specifies. >>=20 >> When encoding, Latitude and Longitude values are rounded to the >> nearest 34-bit binary representation. This imprecision is = considered >> acceptable for the purposes to which this form is intended to be >> applied and is ignored when decoding. >>=20 >> Positive latitudes are north of the equator and negative latitudes >> are south of the equator. Positive longitudes are east of the = Prime >> Meridian (Greenwich) and negative (2s complement) longitudes are = west >> of the Prime Meridian. >>=20 >> Within the coordinate reference systems defined in this document >> (Datum values 1-3), longitude values outside the range of -180 to = 180 >> decimal degrees or latitude values outside the range of -90 to 90 >> degrees MUST be considered invalid. Server implementations SHOULD >> prevent the entry of invalid values within the selected coordinate >> reference system. Location consumers MUST ignore invalid location >> coordinates and SHOULD log invalid location errors. >>=20 >>=20 >> On Sun, Jan 23, 2011 at 2:49 AM, Andy Mabbett = >> wrote: >>>=20 >>> On 23 January 2011 00:27, Bernard Aboba = wrote: >>>> Here is a proposed revision of Section 2.3 to address the concern. >>>> Comments >>>> welcome. >>>>=20 >>>> 2.3. Latitude and Longitude Fields >>>=20 >>> [...] >>>=20 >>>> Longitude values encoded by the DHCP server MUST be normalized = to the >>>> range from -180 to +180 degrees. Positive longitudes are east = of the >>>> Prime Meridian (Greenwich) and negative (2s complement) = longitudes >>>> are west of the Prime Meridian. >>>=20 >>> geoURI (rfc5870) allows for a 'crs' (coordinate reference system) >>> parameter so that, in future, coordinates on bodies such as The Moon >>> or Mars can be expressed. Some such CRSs allow a longitude value = range >>> of 0-360, with no negative values, and of course these do not make >>> reference to Greenwich. >>>=20 >>> WGS84 is assumed as default, where no CRS is specified. >>>=20 >>> It would be sensible to build in such future proofing - and >>> consistency & compatibility - here, using the relevant sections of >>> GeoURI (3.4.1, 3.4.2) as a model. >>>=20 >>> See: >>>=20 >>> >>>=20 >>> >>>=20 >>> also . >>>=20 >>> -- >>> Andy Mabbett >>> @pigsonthewing >>> http://pigsonthewing.org.uk >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www.ietf.org/mailman/listinfo/geopriv >>=20 >>=20 >=20 >=20 >=20 > --=20 > Andy Mabbett > @pigsonthewing > http://pigsonthewing.org.uk > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From stpeter@stpeter.im Thu Jan 27 06:51:02 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55BA93A68C0 for ; Thu, 27 Jan 2011 06:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h99MYzie1NcG for ; Thu, 27 Jan 2011 06:51:01 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 012303A672F for ; Thu, 27 Jan 2011 06:51:00 -0800 (PST) Received: from squire.local (dsl-251-175.dynamic-dsl.frii.net [216.17.251.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D0C4B400F6; Thu, 27 Jan 2011 08:10:23 -0700 (MST) Message-ID: <4D41870A.1030203@stpeter.im> Date: Thu, 27 Jan 2011 07:54:02 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alissa Cooper References: <73B6354E-59C7-4486-BBE4-27F823119952@bbn.com> <8B0A9FCBB9832F43971E38010638454F03FEA148AA@SISPE7MB1.commscope.com> <177DBA32-0CAD-4163-8C3F-9862A05C817D@bbn.com> <0FEB4AD6-45A1-47C8-9548-DB4007C4623B@cdt.org> In-Reply-To: <0FEB4AD6-45A1-47C8-9548-DB4007C4623B@cdt.org> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060308070707080401080308" Cc: "geopriv@ietf.org" , "Thomson, Martin" Subject: Re: [Geopriv] "Do not track" header field X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 14:51:02 -0000 This is a cryptographically signed message in MIME format. --------------ms060308070707080401080308 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks. I've forwarded this to the WEBSEC list. On 1/25/11 2:47 AM, Alissa Cooper wrote: > And I've been talking to Sid at Mozilla about getting a draft ready > before IETF 80. >=20 > On Jan 24, 2011, at 9:49 PM, Richard L. Barnes wrote: >=20 >> If you look at the Bugzilla link, Julian has already suggested that >> this go to WEBSEC for IETF approval and de-X-ification. >> --Richard >> >> >> On Jan 24, 2011, at 4:45 PM, Thomson, Martin wrote: >> >>> They should really drop the X-... >>> >>> On 2011-01-25 at 08:41:41, Richard L. Barnes wrote: >>>> This will likely come up on the WEBSEC list as well, but I thought t= his >>>> might be interesting to GEOPRIV folks: >>>> >>>> Mozilla and Google Chrome are proposing to extend browsers to send a= >>>> "do not track" HTTP header of the following form: >>>> X-Tracking-Choice: do-not-track >>>> >>>> This seems like another example of users sending along privacy >>>> preferences with their data, just like PIDF-LO privacy rules, Creati= ve >>>> Commons licenses, etc. >>>> >>>> References: >>>> >>> control-over-online-tracking/> >>>> >>>> >>>> >>>> --Richard >>> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv >> --------------ms060308070707080401080308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEy NzE0NTQwMlowIwYJKoZIhvcNAQkEMRYEFLZjLilHgPThDXGs3YpNHAyiAW1FMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCTjvRJz20Os2KhJET9Cre8XBGwe5E7Em1UvE4V+DZLKb3a4C0dodQUqorC DCFot2yc1LFF3hARVfYllORaBPhQLWMgVN5ZUxXCD7Zp5xi9ZcNcSOL70RuoBc13BzvcVyv9 UnUifoYwN5UlsxJqoYBDUTGHuqJpIciteL3F5QKHDI5eAF7zcFruvknDIZ+Hyd/MgaLQh/5a GTAioGhJ5hXmb8OYlJ7FJXxOvr/sEEK+ec1Wud7JX1SisTbz9TScxrBqlkzrejr54cOEaJQG LbKXtT6/q7ktvFUZgI1i6zVzQXYaWBZREwRCG7J7fJ3YTpO4dVzmyMDbRDcKsAusXepCAAAA AAAA --------------ms060308070707080401080308-- From acooper@cdt.org Mon Jan 31 04:23:01 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14043A68DF for ; Mon, 31 Jan 2011 04:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0X2Lv3JyL8h6 for ; Mon, 31 Jan 2011 04:23:00 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 5134B3A68A7 for ; Mon, 31 Jan 2011 04:23:00 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Mon, 31 Jan 2011 07:26:10 -0500 Message-Id: From: Alissa Cooper To: Brian Rosen In-Reply-To: <8AA35379-A5A2-4FBA-8799-C53C1C87D9FE@brianrosen.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 31 Jan 2011 12:26:08 +0000 References: <020BBF4F-8D14-4EC1-831D-C6246D410045@cdt.org> <9328D323-46FD-4AED-B334-555423787924@gmx.net> <8AA35379-A5A2-4FBA-8799-C53C1C87D9FE@brianrosen.net> X-Mailer: Apple Mail (2.936) Cc: geopriv@ietf.org Subject: Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 12:23:01 -0000 We're going to go ahead with the (rough) consensus that we have on this one, acknowledging that text changes can and will likely be made before WGLC, and that the updated milestone is restricted to the first- party case. Alissa On Jan 25, 2011, at 2:24 PM, Brian Rosen wrote: > Is there an alternative document that you want to use as a basis for > the milestone? > > Brian > > On Jan 25, 2011, at 3:43 AM, Hannes Tschofenig wrote: > >> I argued that the chosen approach is not the one I would like to >> see moving forward, and the description in the document replicates >> text we already have in other documents. >> >> In that sense I do not want this document as a WG item. >> >> On Jan 12, 2011, at 4:18 PM, Alissa Cooper wrote: >> >>> Now that we have a milestone to "submit recommendations for LIS >>> discovery conducted by hosts behind residential gateways as >>> Informational," I'd like to call for WG adoption of draft-thomson- >>> geopriv-res-gw-lis-discovery-04. Please respond to the list by >>> January 19, 2011 about adopting this document as a WG item. >>> >>> Thanks, >>> Alissa >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www.ietf.org/mailman/listinfo/geopriv >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > > From rbarnes@bbn.com Mon Jan 31 06:58:53 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27383A6B32 for ; Mon, 31 Jan 2011 06:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kU1cjokxOIc for ; Mon, 31 Jan 2011 06:58:52 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id D7FFF3A6C0C for ; Mon, 31 Jan 2011 06:58:52 -0800 (PST) Received: from [128.89.255.144] (port=62172 helo=[172.27.17.202]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PjvGY-000G5X-VE for geopriv@ietf.org; Mon, 31 Jan 2011 10:02:07 -0500 From: Richard L. Barnes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Jan 2011 10:02:06 -0500 Message-Id: <4D14D286-C339-4FA5-9188-60DC0AC6875E@bbn.com> To: geopriv@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Geopriv] Consensus call: Civic extensions X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 14:58:53 -0000 Hey all, The chairs would like to get a sense of the working group for a plan for = a group of civic-address-related issues. =20 -- Request a milestone for civic address extensibility Dec 2012 - Submit recommendations for civic address extensions as PS -- Adopt draft-winterbottom-geopriv-local-civic-04 as the basis for this = milestone -- Merge draft-ietf-geopriv-prefix-00 and = draft-george-geopriv-lamp-post-00 into the milestone draft. Please send comments on this proposal to the list by Monday, 7 Feb 2011. Thanks, --Richard= From Martin.Thomson@andrew.com Mon Jan 31 13:59:08 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446DC3A69B8 for ; Mon, 31 Jan 2011 13:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwxC8CjFL84W for ; Mon, 31 Jan 2011 13:59:07 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 3D63D3A67F7 for ; Mon, 31 Jan 2011 13:59:07 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:39176 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S42151408Ab1AaWCT (ORCPT ); Mon, 31 Jan 2011 16:02:19 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 31 Jan 2011 16:02:19 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 1 Feb 2011 06:02:16 +0800 From: "Thomson, Martin" To: Richard L.Barnes , "geopriv@ietf.org" Date: Tue, 1 Feb 2011 06:02:12 +0800 Thread-Topic: [Geopriv] Consensus call: Civic extensions Thread-Index: AcvBV9cNWaJnFpBtSIi7ki6/Ldr5qwAOo28g Message-ID: <8B0A9FCBB9832F43971E38010638454F03FEA150FD@SISPE7MB1.commscope.com> References: <4D14D286-C339-4FA5-9188-60DC0AC6875E@bbn.com> In-Reply-To: <4D14D286-C339-4FA5-9188-60DC0AC6875E@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Geopriv] Consensus call: Civic extensions X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:59:08 -0000 WWVzIHRvIHRoZSBmaXJzdCB0d28uDQoNCkkgaGF2ZSBubyBzdHJvbmcgb3BpbmlvbiBvbiB0aGUg bWVyZ2luZyBvZiBwcmVmaXggYW5kIGxhbXAtcG9zdC4gIEknbGwgZ28gd2l0aCB0aGUgY3Jvd2Qg b24gdGhhdCBwYXJ0Lg0KDQpPbiAyMDExLTAyLTAxIGF0IDAyOjAyOjA2LCBSaWNoYXJkIEwuQmFy bmVzIHdyb3RlOg0KPiBIZXkgYWxsLA0KPiANCj4gVGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGdl dCBhIHNlbnNlIG9mIHRoZSB3b3JraW5nIGdyb3VwIGZvciBhIHBsYW4NCj4gZm9yIGEgZ3JvdXAg b2YgY2l2aWMtYWRkcmVzcy1yZWxhdGVkIGlzc3Vlcy4NCj4gDQo+IC0tIFJlcXVlc3QgYSBtaWxl c3RvbmUgZm9yIGNpdmljIGFkZHJlc3MgZXh0ZW5zaWJpbGl0eQ0KPiBEZWMgMjAxMiAtIFN1Ym1p dCByZWNvbW1lbmRhdGlvbnMgZm9yIGNpdmljIGFkZHJlc3MgZXh0ZW5zaW9ucyBhcyBQUw0KPiAN Cj4gLS0gQWRvcHQgZHJhZnQtd2ludGVyYm90dG9tLWdlb3ByaXYtbG9jYWwtY2l2aWMtMDQgYXMg dGhlIGJhc2lzIGZvcg0KPiB0aGlzIG1pbGVzdG9uZQ0KPiANCj4gLS0gTWVyZ2UgZHJhZnQtaWV0 Zi1nZW9wcml2LXByZWZpeC0wMCBhbmQgZHJhZnQtZ2VvcmdlLWdlb3ByaXYtbGFtcC0NCj4gcG9z dC0wMCBpbnRvIHRoZSBtaWxlc3RvbmUgZHJhZnQuDQo+IA0KPiBQbGVhc2Ugc2VuZCBjb21tZW50 cyBvbiB0aGlzIHByb3Bvc2FsIHRvIHRoZSBsaXN0IGJ5IE1vbmRheSwgNyBGZWINCj4gMjAxMS4N Cj4gDQo+IFRoYW5rcywNCj4gLS1SaWNoYXJkDQoNCg== From James.Winterbottom@andrew.com Mon Jan 31 13:59:29 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74F4E3A6B8C for ; Mon, 31 Jan 2011 13:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97UVMAFJtrZe for ; Mon, 31 Jan 2011 13:59:28 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id B9E7B3A6B30 for ; Mon, 31 Jan 2011 13:59:28 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:49483 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S504992Ab1AaWCl convert rfc822-to-8bit (ORCPT ); Mon, 31 Jan 2011 16:02:41 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 31 Jan 2011 16:02:41 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 1 Feb 2011 06:02:37 +0800 From: "Winterbottom, James" To: Richard L.Barnes , "geopriv@ietf.org" Date: Tue, 1 Feb 2011 06:02:35 +0800 Thread-Topic: [Geopriv] Consensus call: Civic extensions Thread-Index: AcvBV9cNWaJnFpBtSIi7ki6/Ldr5qwAOo40Q Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120FDF21209@SISPE7MB1.commscope.com> References: <4D14D286-C339-4FA5-9188-60DC0AC6875E@bbn.com> In-Reply-To: <4D14D286-C339-4FA5-9188-60DC0AC6875E@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Geopriv] Consensus call: Civic extensions X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:59:29 -0000 See inline: > > The chairs would like to get a sense of the working group for a plan for a > group of civic-address-related issues. > > -- Request a milestone for civic address extensibility > Dec 2012 - Submit recommendations for civic address extensions as PS > [AJW] I support the creation of this milestone. > -- Adopt draft-winterbottom-geopriv-local-civic-04 as the basis for this > milestone > [AJW] I support this proposal > -- Merge draft-ietf-geopriv-prefix-00 and draft-george-geopriv-lamp-post- > 00 into the milestone draft. > [AJW] I support this proposal also. From br@brianrosen.net Mon Jan 31 14:11:06 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564B73A6CB0 for ; Mon, 31 Jan 2011 14:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.855 X-Spam-Level: X-Spam-Status: No, score=-102.855 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkbF6iI1VWaK for ; Mon, 31 Jan 2011 14:10:57 -0800 (PST) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by core3.amsl.com (Postfix) with ESMTP id C6B243A6885 for ; Mon, 31 Jan 2011 14:10:56 -0800 (PST) X-ASG-Debug-ID: 1296512050-00000013e82856b0001-fOFzYG Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id jfodLCy0R3J5sh4Y; Mon, 31 Jan 2011 14:14:10 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=nned-lt61.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Pk20f-0002js-MB; Mon, 31 Jan 2011 14:14:11 -0800 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: [Geopriv] Consensus call: Civic extensions Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <4D14D286-C339-4FA5-9188-60DC0AC6875E@bbn.com> Date: Mon, 31 Jan 2011 17:13:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D14D286-C339-4FA5-9188-60DC0AC6875E@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1296512050 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.54008 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: geopriv@ietf.org Subject: Re: [Geopriv] Consensus call: Civic extensions X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 22:11:06 -0000 I support this plan Brian On Jan 31, 2011, at 10:02 AM, Richard L. Barnes wrote: > Hey all, >=20 > The chairs would like to get a sense of the working group for a plan = for a group of civic-address-related issues. =20 >=20 > -- Request a milestone for civic address extensibility > Dec 2012 - Submit recommendations for civic address extensions as PS >=20 > -- Adopt draft-winterbottom-geopriv-local-civic-04 as the basis for = this milestone >=20 > -- Merge draft-ietf-geopriv-prefix-00 and = draft-george-geopriv-lamp-post-00 into the milestone draft. >=20 > Please send comments on this proposal to the list by Monday, 7 Feb = 2011. >=20 > Thanks, > --Richard > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From Internet-Drafts@ietf.org Mon Jan 31 16:00:03 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519223A6C8E; Mon, 31 Jan 2011 16:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGEw0CVLsUOA; Mon, 31 Jan 2011 16:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0A7C3A6C95; Mon, 31 Jan 2011 16:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.11 Message-ID: <20110201000001.7214.5582.idtracker@localhost> Date: Mon, 31 Jan 2011 16:00:01 -0800 Cc: geopriv@ietf.org Subject: [Geopriv] I-D Action:draft-ietf-geopriv-res-gw-lis-discovery-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 00:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Geographic Location/Privacy Working Group of the IETF. Title : Location Information Server (LIS) Discovery using IP address and Reverse DNS Author(s) : M. Thomson, R. Bellis Filename : draft-ietf-geopriv-res-gw-lis-discovery-00.txt Pages : 19 Date : 2011-01-31 The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway. This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-res-gw-lis-discovery-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-geopriv-res-gw-lis-discovery-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-31154750.I-D@ietf.org> --NextPart-- From Martin.Dawson@andrew.com Mon Jan 31 16:15:11 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D013A6C97 for ; Mon, 31 Jan 2011 16:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ceWEfFDdN87 for ; Mon, 31 Jan 2011 16:15:10 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 8AF343A6C8E for ; Mon, 31 Jan 2011 16:15:10 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:48925 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S543027Ab1BAASX convert rfc822-to-8bit (ORCPT ); Mon, 31 Jan 2011 18:18:23 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 31 Jan 2011 18:18:23 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 1 Feb 2011 08:18:21 +0800 From: "Dawson, Martin" To: Richard L.Barnes , "geopriv@ietf.org" Date: Tue, 1 Feb 2011 08:18:17 +0800 Thread-Topic: [Geopriv] Consensus call: Civic extensions Thread-Index: AcvBV9cNWaJnFpBtSIi7ki6/Ldr5qwATZ/4Q Message-ID: <8B0A9FCBB9832F43971E38010638454F03FEA1513E@SISPE7MB1.commscope.com> References: <4D14D286-C339-4FA5-9188-60DC0AC6875E@bbn.com> In-Reply-To: <4D14D286-C339-4FA5-9188-60DC0AC6875E@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Subject: Re: [Geopriv] Consensus call: Civic extensions X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 00:15:11 -0000 Sounds good thanks Richard. Cheers, Martin -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Richard L.Barnes Sent: Tuesday, 1 February 2011 2:02 AM To: geopriv@ietf.org Subject: [Geopriv] Consensus call: Civic extensions Hey all, The chairs would like to get a sense of the working group for a plan for a group of civic-address-related issues. -- Request a milestone for civic address extensibility Dec 2012 - Submit recommendations for civic address extensions as PS -- Adopt draft-winterbottom-geopriv-local-civic-04 as the basis for this milestone -- Merge draft-ietf-geopriv-prefix-00 and draft-george-geopriv-lamp-post-00 into the milestone draft. Please send comments on this proposal to the list by Monday, 7 Feb 2011. Thanks, --Richard _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv From robinsgv@gmail.com Mon Jan 31 20:01:51 2011 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B0B3A69EB for ; Mon, 31 Jan 2011 20:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqz0eji5Ie3t for ; Mon, 31 Jan 2011 20:01:50 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 8D8963A67D3 for ; Mon, 31 Jan 2011 20:01:49 -0800 (PST) Received: by fxm9 with SMTP id 9so6958936fxm.31 for ; Mon, 31 Jan 2011 20:05:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EQRaKbwIxsTPC/uNPnjqCRhoooEH0Oxo0HywuaUB53k=; b=UdgHOCB8EFWnLfomzIa+2qKbatBbicV4aMDGoEuKlpOm5Hyf3KEyCEmKPiv+EC8TIz iCSlzOQlcCxZwuaVy+VfydUcRTC5Snu0BQs9MdjzEPb06sRGzKbxDVs22Opa4d9l+D8B pKoSiwolFgzQKu3ddcHZfjmK1LI9oQ7IkdMm8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YrnXzJOGWM7rLzbcuQQ+pZlkX8ZJiQ2vc9KFB9xZtmLPJ8usNU2fc0j+U7YthAR4vA UNt9pLC+nqFX07QTiAgJ9FmamVTui5BNbrHinrQQLn8vJ4/3ssZqUMbxxT15eLe40ujP rN3QFWKGeVzmaKVZBTb5Ic/XCu8UFDgXbpxcE= MIME-Version: 1.0 Received: by 10.223.70.136 with SMTP id d8mr1024609faj.3.1296533104909; Mon, 31 Jan 2011 20:05:04 -0800 (PST) Received: by 10.223.160.129 with HTTP; Mon, 31 Jan 2011 20:05:04 -0800 (PST) Received: by 10.223.160.129 with HTTP; Mon, 31 Jan 2011 20:05:04 -0800 (PST) In-Reply-To: References: <4D14D286-C339-4FA5-9188-60DC0AC6875E@bbn.com> Date: Tue, 1 Feb 2011 09:35:04 +0530 Message-ID: From: Robins George To: Brian Rosen Content-Type: multipart/alternative; boundary=00248c11da37285d54049b30a38d Cc: geopriv@ietf.org Subject: Re: [Geopriv] Consensus call: Civic extensions X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 04:01:51 -0000 --00248c11da37285d54049b30a38d Content-Type: text/plain; charset=ISO-8859-1 +1 -Robins On 01-Feb-2011 3:44 AM, "Brian Rosen" wrote: > I support this plan > > Brian > > On Jan 31, 2011, at 10:02 AM, Richard L. Barnes wrote: > >> Hey all, >> >> The chairs would like to get a sense of the working group for a plan for a group of civic-address-related issues. >> >> -- Request a milestone for civic address extensibility >> Dec 2012 - Submit recommendations for civic address extensions as PS >> >> -- Adopt draft-winterbottom-geopriv-local-civic-04 as the basis for this milestone >> >> -- Merge draft-ietf-geopriv-prefix-00 and draft-george-geopriv-lamp-post-00 into the milestone draft. >> >> Please send comments on this proposal to the list by Monday, 7 Feb 2011. >> >> Thanks, >> --Richard >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv --00248c11da37285d54049b30a38d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

+1

-Robins

On 01-Feb-2011 3:44 AM, "Brian Rosen" <br@brianrosen.net> wrote:
&= gt; I support this plan
>
> Brian
>
> On Jan 31, = 2011, at 10:02 AM, Richard L. Barnes wrote:
>
>> Hey all,
>>
>> The chairs would like t= o get a sense of the working group for a plan for a group of civic-address-= related issues.
>>
>> -- Request a milestone for civic= address extensibility
>> Dec 2012 - Submit recommendations for civic address extensions as = PS
>>
>> -- Adopt draft-winterbottom-geopriv-local-civic= -04 as the basis for this milestone
>>
>> -- Merge draft= -ietf-geopriv-prefix-00 and draft-george-geopriv-lamp-post-00 into the mile= stone draft.
>>
>> Please send comments on this proposal to the list by = Monday, 7 Feb 2011.
>>
>> Thanks,
>> --Richard<= br>>> _______________________________________________
>> Geo= priv mailing list
>> Geopriv@ietf.org
>&g= t; https://www.ie= tf.org/mailman/listinfo/geopriv
>
> ______________________= _________________________
> Geopriv mailing list
> Geopr= iv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

--00248c11da37285d54049b30a38d--