From rjsparks@nostrum.com Mon Oct 1 14:23:49 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8B01F0D5F for ; Mon, 1 Oct 2012 14:23:49 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKBbIknq5pDo for ; Mon, 1 Oct 2012 14:23:49 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D6E521F040A for ; Mon, 1 Oct 2012 14:23:48 -0700 (PDT) Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q91LNcb0092208 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 16:23:41 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <506A09DA.6000806@nostrum.com> Date: Mon, 01 Oct 2012 16:23:38 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Richard Barnes References: <41AE8C3955724032BFE2ADBA75DF6599@bbn.com> In-Reply-To: <41AE8C3955724032BFE2ADBA75DF6599@bbn.com> Content-Type: multipart/alternative; boundary="------------040204010209040005040602" Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: geopriv@ietf.org Subject: Re: [Geopriv] Changes in -policy-uri-06 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 21:23:50 -0000 This is a multi-part message in MIME format. --------------040204010209040005040602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/26/12 7:59 AM, Richard Barnes wrote: > Dear GEOPRIV, > > The latest version of -policy-uri seems to have addressed all of the > DISCUSS comments, but it contains several changes that I would like to > run by the working group. Going in order of the diff [1]: > > -- Section 1: Clarified that LbyR only provides privacy protections if > appropriate access control policies are configured > > -- Section 3.1: Added requirement that clients SHOULD support HTTP > client auth and MAY support TLS client certs. > > -- Added Section 3.3, providing some example policies (e.g., a > deny-all policy) > > -- Section 7.1: Clarified that the general requirements for TLS > support/usage are the same as for -deref-protocol. > > -- Section 7.2: Clarified requirements for entropy in policy URIs, and > provided an example algorithm for generating policy URIs There's one change in this section that goes beyond clarification. I have no problem with it, but I wanted to make sure people knew it was there - you changed the recommended entropy going into the policy URI from 32 to 128 bits. > > -- Added Section 7.4, recommending that policy URIs be protected to > the same level as other shared secrets (e.g., passwords) > > The only normative changes are (1) SHOULD support HTTP client auth, > and (2) SHOULD protect policy URIs as shared secrets. > > Hope this helps, > --Richard > > > [1] > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv --------------040204010209040005040602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 9/26/12 7:59 AM, Richard Barnes wrote:
Dear GEOPRIV,

The latest version of -policy-uri seems to have addressed all of the DISCUSS comments, but it contains several changes that I would like to run by the working group.  Going in order of the diff [1]:

-- Section 1: Clarified that LbyR only provides privacy protections if appropriate access control policies are configured

-- Section 3.1: Added requirement that clients SHOULD support HTTP client auth and MAY support TLS client certs.

-- Added Section 3.3, providing some example policies (e.g., a deny-all policy)

-- Section 7.1: Clarified that the general requirements for TLS support/usage are the same as for -deref-protocol.

-- Section 7.2: Clarified requirements for entropy in policy URIs, and provided an example algorithm for generating policy URIs
There's one change in this section that goes beyond clarification. I have no problem with it, but I wanted to make sure people knew
it was there - you changed the recommended entropy going into the policy URI from 32 to 128 bits.

-- Added Section 7.4, recommending that policy URIs be protected to the same level as other shared secrets (e.g., passwords)

The only normative changes are (1) SHOULD support HTTP client auth, and (2) SHOULD protect policy URIs as shared secrets.

Hope this helps,
--Richard




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

--------------040204010209040005040602-- From acooper@cdt.org Wed Oct 3 03:33:36 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA96221F84F6 for ; Wed, 3 Oct 2012 03:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.417 X-Spam-Level: X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WW3EeQpMUpqv for ; Wed, 3 Oct 2012 03:33:36 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id BA42B21F84F3 for ; Wed, 3 Oct 2012 03:33:35 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Wed, 3 Oct 2012 06:33:28 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <41AE8C3955724032BFE2ADBA75DF6599@bbn.com> Date: Wed, 3 Oct 2012 04:33:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <41AE8C3955724032BFE2ADBA75DF6599@bbn.com> To: Richard Barnes X-Mailer: Apple Mail (2.1084) Cc: geopriv@ietf.org Subject: Re: [Geopriv] Changes in -policy-uri-06 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 10:33:36 -0000 I have two questions about the text in 3.3: > The same reasoning could also be applied to servers, with the caveat > that servers do not know whether a given HELD client supports the = use > of policy URIs. A client that does not understand policy URIs will > not be able to set its own policy, and so the server must choose a > default that is open enough that clients will find it useful. =20 I feel like between this statement and the text in 3.2 and 7.4 about = authorization by possession ("Without policy URIs, location URIs are = subject to the "authorization by possession model", and location URIs = must be conveyed to another entity in order to be useful."), the = suggestions to servers about how they should set the default policy are = muddy. A default option that is open enough for clients to find it = useful could be a whole set of things that are still more restrictive = than authorization by possession. I realize that there is no normative = requirement for the default to be anything in particular, but I think = every time the subject of the default is raised, the suggestion should = be consistent. > On the > other hand, once a client indicates that it understands policy URIs > (e.g., by sending an HTTP request to a policy URI), the server may > change its default policy to something more restrictive -- even the > empty, default-deny policy -- since the client can specify something > more permissive if desired. When you say "default policy" above, are you talking about the policy = that exists between the time that the client issues a GET for the policy = and the time that the client issues a PUT or DELETE on the policy? (Not = exactly what I would think of as a "default," but that's my best guess = as to what this means).=20 If the above interpretation is correct, this still seems a little weird = to me to suggest that servers would change from auth-by-possession to = deny-everything just because a client supports policy URIs. E.g., if the = client fires the GET when the user opens up a permissions interface, but = then the user cancels without setting his policy, the policy will have = changed completely without the user taking any affirmative step. I = realize that this scenario is possible, but I don't see why we need to = point it out explicitly. Alissa On Sep 26, 2012, at 6:59 AM, Richard Barnes wrote: > Dear GEOPRIV, >=20 > The latest version of -policy-uri seems to have addressed all of the = DISCUSS comments, but it contains several changes that I would like to = run by the working group. Going in order of the diff [1]: >=20 > -- Section 1: Clarified that LbyR only provides privacy protections if = appropriate access control policies are configured >=20 > -- Section 3.1: Added requirement that clients SHOULD support HTTP = client auth and MAY support TLS client certs. >=20 > -- Added Section 3.3, providing some example policies (e.g., a = deny-all policy) >=20 > -- Section 7.1: Clarified that the general requirements for TLS = support/usage are the same as for -deref-protocol. >=20 > -- Section 7.2: Clarified requirements for entropy in policy URIs, and = provided an example algorithm for generating policy URIs >=20 > -- Added Section 7.4, recommending that policy URIs be protected to = the same level as other shared secrets (e.g., passwords) >=20 > The only normative changes are (1) SHOULD support HTTP client auth, = and (2) SHOULD protect policy URIs as shared secrets. >=20 > Hope this helps, > --Richard >=20 >=20 > [1] = > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From rbarnes@bbn.com Wed Oct 3 11:39:46 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382E721F853F for ; Wed, 3 Oct 2012 11:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.505 X-Spam-Level: X-Spam-Status: No, score=-106.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sk0rwzKYF4BT for ; Wed, 3 Oct 2012 11:39:45 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 560A821F8503 for ; Wed, 3 Oct 2012 11:39:45 -0700 (PDT) Received: from ros-dhcp192-1-51-103.bbn.com ([192.1.51.103]:59679) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TJTr4-0005FR-HE; Wed, 03 Oct 2012 14:39:34 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: Date: Wed, 3 Oct 2012 14:39:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <41AE8C3955724032BFE2ADBA75DF6599@bbn.com> To: Alissa Cooper X-Mailer: Apple Mail (2.1283) Cc: geopriv@ietf.org Subject: Re: [Geopriv] Changes in -policy-uri-06 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 18:39:46 -0000 Hey Alissa, Thanks for pointing these out. There is some legitimate ambiguity. = Proposed text inline below. On Oct 3, 2012, at 6:33 AM, Alissa Cooper wrote: > I have two questions about the text in 3.3: >=20 >> The same reasoning could also be applied to servers, with the caveat >> that servers do not know whether a given HELD client supports the = use >> of policy URIs. A client that does not understand policy URIs will >> not be able to set its own policy, and so the server must choose a >> default that is open enough that clients will find it useful. =20 >=20 > I feel like between this statement and the text in 3.2 and 7.4 about = authorization by possession ("Without policy URIs, location URIs are = subject to the "authorization by possession model", and location URIs = must be conveyed to another entity in order to be useful."), the = suggestions to servers about how they should set the default policy are = muddy. A default option that is open enough for clients to find it = useful could be a whole set of things that are still more restrictive = than authorization by possession. I realize that there is no normative = requirement for the default to be anything in particular, but I think = every time the subject of the default is raised, the suggestion should = be consistent. OLD: "Without policy URIs, location URIs are subject to the = "authorization by possession model", and" NEW: "Without policy URIs, location URIs are subject to a default policy = set unilaterally by the server, and" >> On the >> other hand, once a client indicates that it understands policy URIs >> (e.g., by sending an HTTP request to a policy URI), the server may >> change its default policy to something more restrictive -- even the >> empty, default-deny policy -- since the client can specify something >> more permissive if desired. >=20 > When you say "default policy" above, are you talking about the policy = that exists between the time that the client issues a GET for the policy = and the time that the client issues a PUT or DELETE on the policy? (Not = exactly what I would think of as a "default," but that's my best guess = as to what this means).=20 >=20 > If the above interpretation is correct, this still seems a little = weird to me to suggest that servers would change from auth-by-possession = to deny-everything just because a client supports policy URIs. E.g., if = the client fires the GET when the user opens up a permissions interface, = but then the user cancels without setting his policy, the policy will = have changed completely without the user taking any affirmative step. I = realize that this scenario is possible, but I don't see why we need to = point it out explicitly. I was thinking that the server would change before it responds to the = GET, in which case the user would see the policy as default-deny. But I = see your point. OLD: "the server may change its default policy to something more = restrictive" NEW: "the server may change the policy for the relevant policy URI from = its default policy to something more restrictive" NEW(at end of paragraph): " Obviously, if such a change is made, it should be visible to the client. = For example, if the server uses a GET request to a policy URI as an = indication that the client supports policy URIs, then it should change = the policy before replying to the GET. That way, the results of the GET = will accurately reflect the more restrictive policy. " Do those clarifications help? --Richard >=20 > Alissa >=20 > On Sep 26, 2012, at 6:59 AM, Richard Barnes wrote: >=20 >> Dear GEOPRIV, >>=20 >> The latest version of -policy-uri seems to have addressed all of the = DISCUSS comments, but it contains several changes that I would like to = run by the working group. Going in order of the diff [1]: >>=20 >> -- Section 1: Clarified that LbyR only provides privacy protections = if appropriate access control policies are configured >>=20 >> -- Section 3.1: Added requirement that clients SHOULD support HTTP = client auth and MAY support TLS client certs. >>=20 >> -- Added Section 3.3, providing some example policies (e.g., a = deny-all policy) >>=20 >> -- Section 7.1: Clarified that the general requirements for TLS = support/usage are the same as for -deref-protocol. >>=20 >> -- Section 7.2: Clarified requirements for entropy in policy URIs, = and provided an example algorithm for generating policy URIs >>=20 >> -- Added Section 7.4, recommending that policy URIs be protected to = the same level as other shared secrets (e.g., passwords) >>=20 >> The only normative changes are (1) SHOULD support HTTP client auth, = and (2) SHOULD protect policy URIs as shared secrets. >>=20 >> Hope this helps, >> --Richard >>=20 >>=20 >> [1] = >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv >=20 >=20 From martin.thomson@gmail.com Wed Oct 3 11:45:33 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD27D21F85B8 for ; Wed, 3 Oct 2012 11:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaOJgRfQXfCh for ; Wed, 3 Oct 2012 11:45:33 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C1C4721F8596 for ; Wed, 3 Oct 2012 11:45:32 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4183347wgb.13 for ; Wed, 03 Oct 2012 11:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RKc7S/BiIUa6tSeSiSq+FywiviEmS11tKgIUrW/hKD4=; b=KbZAk5hZVsATGNraYGZQMUk4LTjorShCoPXIMDvifBH6j4UBOk6bS5Bb7Qz+AG2bIk Ez41TB1n4Ljmp0hA0c0qSPW3C255j87zfkY96uQ6Z+1Pmo+PenivBYC390epCZFyyINi dyflajEMl1dZ1ZAou1w9xC0jFH8E7FTOzCcf7+ie3VVJ0jAzlQYfQf3+Np0gtVw1dRfA JE709LIagP/4sW8MOSswCy32a6uLkTKfE90GzlZwg5AdOKe86fjg/n5c8HahTxVnItoH 9CHrDKyWHOYANTU+ZHdKv4eCS3zC0G/bpxRjoCYscOAbtBpJOKrbMN5gdO0j8LmqnfhN KGYQ== MIME-Version: 1.0 Received: by 10.216.209.40 with SMTP id r40mr1779153weo.144.1349289931834; Wed, 03 Oct 2012 11:45:31 -0700 (PDT) Received: by 10.180.96.9 with HTTP; Wed, 3 Oct 2012 11:45:31 -0700 (PDT) In-Reply-To: References: <41AE8C3955724032BFE2ADBA75DF6599@bbn.com> Date: Wed, 3 Oct 2012 19:45:31 +0100 Message-ID: From: Martin Thomson To: Richard Barnes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org Subject: Re: [Geopriv] Changes in -policy-uri-06 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 18:45:33 -0000 On 3 October 2012 19:39, Richard Barnes wrote: > I was thinking that the server would change before it responds to the GET= , in which case the user would see the policy as default-deny. But I see y= our point. > > OLD: "the server may change its default policy to something more restrict= ive" > NEW: "the server may change the policy for the relevant policy URI from i= ts default policy to something more restrictive" > > NEW(at end of paragraph): > " > Obviously, if such a change is made, it should be visible to the client. = For example, if the server uses a GET request to a policy URI as an indica= tion that the client supports policy URIs, then it should change the policy= before replying to the GET. That way, the results of the GET will accurat= ely reflect the more restrictive policy. > " This bothers me. It bugged me before, but I couldn't pin it down to something specific. Thanks for the extra text to help clarify things. A GET is supposed to be safe. This violates that basic contract. If I make a GET request to a policy URI, there could be consequences that I am not aware of. The problem is that it is possible, prior to the GET, to observe the policy that the server has applied. Having that policy change as a result of a request that is defined as having no repercussions on the requester is not good. A better way of signaling support for this sort of feature would be at the time that the resources were created. --Martin From rbarnes@bbn.com Wed Oct 3 12:08:14 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10EA11E8091 for ; Wed, 3 Oct 2012 12:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.214 X-Spam-Level: X-Spam-Status: No, score=-106.214 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujiIqgVrUlwT for ; Wed, 3 Oct 2012 12:08:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 450B021F8516 for ; Wed, 3 Oct 2012 12:08:14 -0700 (PDT) Received: from ros-dhcp192-1-51-103.bbn.com ([192.1.51.103]:60070) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TJUIk-0005aB-QY; Wed, 03 Oct 2012 15:08:10 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: Date: Wed, 3 Oct 2012 15:08:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <32504ED3-B82D-44E9-AF97-340D7EA5D4C2@bbn.com> References: <41AE8C3955724032BFE2ADBA75DF6599@bbn.com> To: Martin Thomson X-Mailer: Apple Mail (2.1283) Cc: geopriv@ietf.org Subject: Re: [Geopriv] Changes in -policy-uri-06 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:08:14 -0000 On Oct 3, 2012, at 2:45 PM, Martin Thomson wrote: > On 3 October 2012 19:39, Richard Barnes wrote: >> I was thinking that the server would change before it responds to the = GET, in which case the user would see the policy as default-deny. But I = see your point. >>=20 >> OLD: "the server may change its default policy to something more = restrictive" >> NEW: "the server may change the policy for the relevant policy URI = from its default policy to something more restrictive" >>=20 >> NEW(at end of paragraph): >> " >> Obviously, if such a change is made, it should be visible to the = client. For example, if the server uses a GET request to a policy URI = as an indication that the client supports policy URIs, then it should = change the policy before replying to the GET. That way, the results of = the GET will accurately reflect the more restrictive policy. >> " >=20 > This bothers me. It bugged me before, but I couldn't pin it down to > something specific. Thanks for the extra text to help clarify things. >=20 > A GET is supposed to be safe. This violates that basic contract. If > I make a GET request to a policy URI, there could be consequences that > I am not aware of. >=20 > The problem is that it is possible, prior to the GET, to observe the > policy that the server has applied. Having that policy change as a > result of a request that is defined as having no repercussions on the > requester is not good. >=20 > A better way of signaling support for this sort of feature would be at > the time that the resources were created. How silly of me. I forgot the element that we = defined, which is exactly what you're asking for. OLD: "once a client indicates that it understands policy URIs (e.g., by = sending an HTTP request to a policy URI)" NEW: "if a client indicates that it understands policy URIs (e.g., by = including a element in its HELD request)" That leaves DHCP out in the cold, but I think it's much better than = changing on GET. --Richard= From martin.thomson@gmail.com Wed Oct 3 13:47:53 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EBE1F0421 for ; Wed, 3 Oct 2012 13:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.693 X-Spam-Level: X-Spam-Status: No, score=-3.693 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYPt72Nkcbyx for ; Wed, 3 Oct 2012 13:47:53 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id A28CB11E80AD for ; Wed, 3 Oct 2012 13:47:52 -0700 (PDT) Received: by wibhr7 with SMTP id hr7so2421757wib.13 for ; Wed, 03 Oct 2012 13:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z0eA+8FPnxirMcCyzRJiXRJG5dwCwAMd0Fh2H8x4Vnk=; b=BZybCBlw82BiLXxFYNQY24nz4dIFnJkHS3x454mkQch1+3OMFhA8Kjz7BrRNtp4prf YRJXxxcpzj9qxD/vFtqPlbUW/E/U2dCq0mZWa+HZCWzUkta2ypGqotySuMWdd1jbgkE/ WZmg2A95BEhxObGT8dpAtYwSEJgrMYP0BBBrg/MPwkKs3ZTQTt+CbznlC5yC+kozxLvn h/2gUl9sEdQc5V+ZmMqPQSGOEJP7lzcs5laS479tZ7hBjRRaLA16MNItgxYKpFOGtTAq uzErR/4Sb6BC8sl3XSl1BsK1NlUvvC3ClmWc9F+O983hBDd9cqOhX1QE2y3ymmEaZ1YE /zog== MIME-Version: 1.0 Received: by 10.180.84.169 with SMTP id a9mr7445501wiz.8.1349297264466; Wed, 03 Oct 2012 13:47:44 -0700 (PDT) Received: by 10.180.96.9 with HTTP; Wed, 3 Oct 2012 13:47:44 -0700 (PDT) In-Reply-To: <32504ED3-B82D-44E9-AF97-340D7EA5D4C2@bbn.com> References: <41AE8C3955724032BFE2ADBA75DF6599@bbn.com> <32504ED3-B82D-44E9-AF97-340D7EA5D4C2@bbn.com> Date: Wed, 3 Oct 2012 21:47:44 +0100 Message-ID: From: Martin Thomson To: Richard Barnes Content-Type: text/plain; charset=UTF-8 Cc: geopriv@ietf.org Subject: Re: [Geopriv] Changes in -policy-uri-06 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:47:53 -0000 On 3 October 2012 20:08, Richard Barnes wrote: > OLD: "once a client indicates that it understands policy URIs (e.g., by sending an HTTP request to a policy URI)" > NEW: "if a client indicates that it understands policy URIs (e.g., by including a element in its HELD request)" > > That leaves DHCP out in the cold, but I think it's much better than changing on GET. DHCP servers will have to operate on the assumption that the client doesn't understand policies. That's simply maintains status quo. The HELD side improves upon it. From acooper@cdt.org Thu Oct 4 08:41:39 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E8D21F86F8 for ; Thu, 4 Oct 2012 08:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3+-tS0lkhK1 for ; Thu, 4 Oct 2012 08:41:39 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id CDBA121F86F0 for ; Thu, 4 Oct 2012 08:41:38 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 4 Oct 2012 11:41:29 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: Date: Thu, 4 Oct 2012 11:41:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8BBE6199-E961-4F4E-BEA6-FCF960CF5513@cdt.org> References: <41AE8C3955724032BFE2ADBA75DF6599@bbn.com> To: Richard Barnes X-Mailer: Apple Mail (2.1084) Cc: geopriv@ietf.org Subject: Re: [Geopriv] Changes in -policy-uri-06 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 15:41:40 -0000 On Oct 3, 2012, at 2:39 PM, Richard Barnes wrote: >> I have two questions about the text in 3.3: >>=20 >>> The same reasoning could also be applied to servers, with the caveat >>> that servers do not know whether a given HELD client supports the = use >>> of policy URIs. A client that does not understand policy URIs will >>> not be able to set its own policy, and so the server must choose a >>> default that is open enough that clients will find it useful. =20 >>=20 >> I feel like between this statement and the text in 3.2 and 7.4 about = authorization by possession ("Without policy URIs, location URIs are = subject to the "authorization by possession model", and location URIs = must be conveyed to another entity in order to be useful."), the = suggestions to servers about how they should set the default policy are = muddy. A default option that is open enough for clients to find it = useful could be a whole set of things that are still more restrictive = than authorization by possession. I realize that there is no normative = requirement for the default to be anything in particular, but I think = every time the subject of the default is raised, the suggestion should = be consistent. >=20 > OLD: "Without policy URIs, location URIs are subject to the = "authorization by possession model", and" > NEW: "Without policy URIs, location URIs are subject to a default = policy set unilaterally by the server, and" >=20 Better, thanks. Alissa From acooper@cdt.org Thu Oct 4 08:43:36 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9C421F85C3 for ; Thu, 4 Oct 2012 08:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9TswV5LbkYL for ; Thu, 4 Oct 2012 08:43:36 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id D4BD821F85BB for ; Thu, 4 Oct 2012 08:43:35 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 4 Oct 2012 11:43:27 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <32504ED3-B82D-44E9-AF97-340D7EA5D4C2@bbn.com> Date: Thu, 4 Oct 2012 11:43:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <41AE8C3955724032BFE2ADBA75DF6599@bbn.com> <32504ED3-B82D-44E9-AF97-340D7EA5D4C2@bbn.com> To: Richard Barnes X-Mailer: Apple Mail (2.1084) Cc: geopriv@ietf.org Subject: Re: [Geopriv] Changes in -policy-uri-06 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 15:43:36 -0000 On Oct 3, 2012, at 3:08 PM, Richard Barnes wrote: >> This bothers me. It bugged me before, but I couldn't pin it down to >> something specific. Thanks for the extra text to help clarify = things. >>=20 >> A GET is supposed to be safe. This violates that basic contract. If >> I make a GET request to a policy URI, there could be consequences = that >> I am not aware of. >>=20 >> The problem is that it is possible, prior to the GET, to observe the >> policy that the server has applied. Having that policy change as a >> result of a request that is defined as having no repercussions on the >> requester is not good. >>=20 >> A better way of signaling support for this sort of feature would be = at >> the time that the resources were created. >=20 > How silly of me. I forgot the element that we = defined, which is exactly what you're asking for. >=20 > OLD: "once a client indicates that it understands policy URIs (e.g., = by sending an HTTP request to a policy URI)" > NEW: "if a client indicates that it understands policy URIs (e.g., by = including a element in its HELD request)" I would say drop the "e.g.," and it's good to go. Alissa >=20 > That leaves DHCP out in the cold, but I think it's much better than = changing on GET. >=20 > --Richard From internet-drafts@ietf.org Thu Oct 4 12:37:23 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B0F11E80ED; Thu, 4 Oct 2012 12:37:23 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAgIJi8ZD0Fb; Thu, 4 Oct 2012 12:37:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4666E11E80E0; Thu, 4 Oct 2012 12:37:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121004193723.12677.80586.idtracker@ietfa.amsl.com> Date: Thu, 04 Oct 2012 12:37:23 -0700 Cc: geopriv@ietf.org Subject: [Geopriv] I-D Action: draft-ietf-geopriv-policy-uri-07.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 19:37:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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) : Richard Barnes Martin Thomson James Winterbottom Hannes Tschofenig Filename : draft-ietf-geopriv-policy-uri-07.txt Pages : 21 Date : 2012-10-04 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-geopriv-policy-uri There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-geopriv-policy-uri-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-geopriv-policy-uri-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rbarnes@bbn.com Thu Oct 4 12:38:37 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20911F0C95 for ; Thu, 4 Oct 2012 12:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ONAxQK68jUQ for ; Thu, 4 Oct 2012 12:38:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id BC31A1F0424 for ; Thu, 4 Oct 2012 12:38:36 -0700 (PDT) Received: from dhcp-192-1-255-191.col.bbn.com ([192.1.255.191]:64754) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TJrFW-000G1u-OL; Thu, 04 Oct 2012 15:38:22 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Richard Barnes In-Reply-To: <20121004193723.12677.80586.idtracker@ietfa.amsl.com> Date: Thu, 4 Oct 2012 15:38:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121004193723.12677.80586.idtracker@ietfa.amsl.com> To: geopriv@ietf.org, Robert Sparks X-Mailer: Apple Mail (2.1283) Subject: Re: [Geopriv] I-D Action: draft-ietf-geopriv-policy-uri-07.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 19:38:37 -0000 This should address the comments from Alissa and Martin on -06. Robert: Clear to launch? --Richard On Oct 4, 2012, at 3:37 PM, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Location Configuration Extensions for Policy = Management > Author(s) : Richard Barnes > Martin Thomson > James Winterbottom > Hannes Tschofenig > Filename : draft-ietf-geopriv-policy-uri-07.txt > Pages : 21 > Date : 2012-10-04 >=20 > Abstract: > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-geopriv-policy-uri >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-geopriv-policy-uri-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-geopriv-policy-uri-07 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From acooper@cdt.org Mon Oct 8 06:53:19 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1348121F85B8 for ; Mon, 8 Oct 2012 06:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieh8dGo5p3Pw for ; Mon, 8 Oct 2012 06:53:18 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 5375121F85AF for ; Mon, 8 Oct 2012 06:53:18 -0700 (PDT) X-Footer: Y2R0Lm9yZw== 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, 8 Oct 2012 09:53:17 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Alissa Cooper In-Reply-To: Date: Mon, 8 Oct 2012 09:53:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7D61F2BA-80F8-45F1-B436-A275C679F5A8@cdt.org> References: <5295BA39-EC17-49CB-A08E-5D2BF7CC1B9C@cdt.org> To: GEOPRIV WG X-Mailer: Apple Mail (2.1084) Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-flow-identity-00 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 13:53:19 -0000 Any other responses to this WGLC? Would be good to hear from a few more = people so we know the WG has read and supports this doc (even if you = just say, "it's good to go"). Thanks, Alissa On Sep 13, 2012, at 12:35 PM, Martin Thomson wrote: > Looks good. >=20 > Minor comment that the editor might like to consider for the > schema...or not: enumerated types are more efficient than branching > regular expressions when it comes to defining simple types. This > would apply to "layer3" and "target". "layer4" would require a union > type with an enumerated type and a number (though the number could be > range constrained in that case). >=20 > I'll let Ray use his discretion - it's clear that the current schema > is correct. A more efficient schema can be built by implementers >=20 > Nit in Section 3, p1: s/show/shown/ >=20 > On 13 September 2012 07:52, Alissa Cooper wrote: >> Dear GEOPRIV, >>=20 >> This is a Working Group Last Call for comments on = draft-ietf-geopriv-flow-identity-00: >> >>=20 >> Please send comments to the list no later than Friday, 5 October = 2012. >>=20 >> Remember that all comments are helpful, even if it's just "Looks good = to me". You can also say "Doesn't look good to me", but it's more = helpful to say why! >>=20 >> Thanks, >> Alissa >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv >=20 From rjsparks@nostrum.com Mon Oct 8 14:56:04 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8138B1F0423 for ; Mon, 8 Oct 2012 14:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBIGccoScExW for ; Mon, 8 Oct 2012 14:56:03 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CC85B1F041F for ; Mon, 8 Oct 2012 14:56:03 -0700 (PDT) Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q98Lu2qo011642 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 8 Oct 2012 16:56:02 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <50734BF2.8040203@nostrum.com> Date: Mon, 08 Oct 2012 16:56:02 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Winterbottom, James" References: <505B9440.4020303@nostrum.com> <5A55A45AE77F5941B18E5457ECAC818801212C37D0FD@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC818801212C37D0FD@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: GEOPRIV WG , "draft-ietf-geopriv-local-civic@tools.ietf.org" Subject: Re: [Geopriv] AD Review: draft-ietf-geopriv-local-civic-06 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 21:56:04 -0000 James - LC expired - please spin a new version reflecting these and any direct feedback you might have received. I'll add it to the next telechat once the revision is available. RjS On 9/20/12 6:44 PM, Winterbottom, James wrote: > Thanks Robert, > > I have fixed these but will hold off submitting pending further discussion from the IESG. > > Cheers > James > > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Robert Sparks > Sent: Friday, 21 September 2012 8:10 AM > To: GEOPRIV WG; draft-ietf-geopriv-local-civic@tools.ietf.org > Subject: [Geopriv] AD Review: draft-ietf-geopriv-local-civic-06 > > Summary: This is ready for IETF LC, with nits. > > Please address these along with any IETF LC comments you receive. > > 1) Where the IANA considerations section speaks of the "CATypes" > registry, please > say the "CATypes" registry on the "Civic Address Types Registry" page (at least once at the beginning of the section). > (see > http://www.iana.org/assignments/civic-address-types-registry/civic-address-types-registry.xml) > > 2) There's a dangling double-quote at the end of the first sentence of section 8.5.1 _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From iesg-secretary@ietf.org Mon Oct 8 15:13:20 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD53721F854F; Mon, 8 Oct 2012 15:13:20 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAEP2bAfp9yA; Mon, 8 Oct 2012 15:13:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2484511E80FC; Mon, 8 Oct 2012 15:13:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121008221320.26125.76288.idtracker@ietfa.amsl.com> Date: Mon, 08 Oct 2012 15:13:20 -0700 Cc: geopriv mailing list , geopriv chair , RFC Editor Subject: [Geopriv] Protocol Action: 'Location Configuration Extensions for Policy Management' to Proposed Standard (draft-ietf-geopriv-policy-uri-07.txt) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 22:13:21 -0000 The IESG has approved the following document: - 'Location Configuration Extensions for Policy Management' (draft-ietf-geopriv-policy-uri-07.txt) as Proposed Standard This document is the product of the Geographic Location/Privacy Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-geopriv-policy-uri/ Technical Summary 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. Working Group Summary This document was uncontroversial. It fills a gap in the location configuration architecture. Document Quality At this time there are no known implementations, nor are there any reviewers or experts that merit a special mention. Personnel Robert Sparks is the responsible Area Director. Alissa Cooper is the document shepherd. From internet-drafts@ietf.org Mon Oct 8 21:52:18 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C09D21F8735; Mon, 8 Oct 2012 21:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuJH5HO5N1zi; Mon, 8 Oct 2012 21:52:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8330821F8737; Mon, 8 Oct 2012 21:51:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121009045144.8383.32766.idtracker@ietfa.amsl.com> Date: Mon, 08 Oct 2012 21:51:44 -0700 Cc: geopriv@ietf.org Subject: [Geopriv] I-D Action: draft-ietf-geopriv-local-civic-07.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 04:52:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Geographic Location/Privacy Working Group= of the IETF. Title : Specifying Civic Address Extensions in PIDF-LO Author(s) : James Winterbottom Martin Thomson Richard Barnes Brian Rosen Robins George Filename : draft-ietf-geopriv-local-civic-07.txt Pages : 21 Date : 2012-10-08 Abstract: New fields are occasionally added to civic addresses. A backwardly- compatible mechanism for adding civic address elements to the Geopriv civic address format is described. A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation. Intial extensions for some new elements are also defined. The LoST (RFC5222) protocol mechanism that returns civic address element names used for validation of location information is clarified and is normatively updated to require a qualifying namespace identifier on each civic address element returned as part of the validation process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-geopriv-local-civic There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-geopriv-local-civic-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-geopriv-local-civic-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From James.Winterbottom@commscope.com Mon Oct 8 21:52:19 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9217121F8740 for ; Mon, 8 Oct 2012 21:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz91nD2LMPq9 for ; Mon, 8 Oct 2012 21:52:18 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id 7D40521F8739 for ; Mon, 8 Oct 2012 21:52:18 -0700 (PDT) X-AuditID: 0a0404e8-b7c1dae0000009ce-02-5073ada01de7 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 8A.28.02510.0ADA3705; Mon, 8 Oct 2012 23:52:48 -0500 (CDT) 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.279.1; Mon, 8 Oct 2012 23:52:08 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 9 Oct 2012 12:52:06 +0800 From: "Winterbottom, James" To: Robert Sparks Date: Tue, 9 Oct 2012 12:52:05 +0800 Thread-Topic: [Geopriv] AD Review: draft-ietf-geopriv-local-civic-06 Thread-Index: Ac2ln7demE5p+P77ThegURKezWVegwAOheoA Message-ID: <5A55A45AE77F5941B18E5457ECAC818801212C3D8219@SISPE7MB1.commscope.com> References: <505B9440.4020303@nostrum.com> <5A55A45AE77F5941B18E5457ECAC818801212C37D0FD@SISPE7MB1.commscope.com> <50734BF2.8040203@nostrum.com> In-Reply-To: <50734BF2.8040203@nostrum.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: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAhlX8kscKIYB Cc: GEOPRIV WG , "draft-ietf-geopriv-local-civic@tools.ietf.org" Subject: Re: [Geopriv] AD Review: draft-ietf-geopriv-local-civic-06 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 04:52:19 -0000 Done Robert. -----Original Message----- From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 Sent: Tuesday, 9 October 2012 8:56 AM To: Winterbottom, James Cc: GEOPRIV WG; draft-ietf-geopriv-local-civic@tools.ietf.org Subject: Re: [Geopriv] AD Review: draft-ietf-geopriv-local-civic-06 James - LC expired - please spin a new version reflecting these and any direct feed= back you might have received. I'll add it to the next telechat once the revision is available. RjS On 9/20/12 6:44 PM, Winterbottom, James wrote: > Thanks Robert, > > I have fixed these but will hold off submitting pending further discussio= n from the IESG. > > Cheers > James > > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On=20 > Behalf Of Robert Sparks > Sent: Friday, 21 September 2012 8:10 AM > To: GEOPRIV WG; draft-ietf-geopriv-local-civic@tools.ietf.org > Subject: [Geopriv] AD Review: draft-ietf-geopriv-local-civic-06 > > Summary: This is ready for IETF LC, with nits. > > Please address these along with any IETF LC comments you receive. > > 1) Where the IANA considerations section speaks of the "CATypes" > registry, please > say the "CATypes" registry on the "Civic Address Types Registry" page (at= least once at the beginning of the section). > (see > http://www.iana.org/assignments/civic-address-types-registry/civic-add > ress-types-registry.xml) > > 2) There's a dangling double-quote at the end of the first sentence of=20 > section 8.5.1 _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From joe@cdt.org Tue Oct 9 07:05:20 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA1311E8109 for ; Tue, 9 Oct 2012 07:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyatoDyDlHhc for ; Tue, 9 Oct 2012 07:05:20 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id AF5DD11E810F for ; Tue, 9 Oct 2012 07:05:16 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for geopriv@ietf.org; Tue, 9 Oct 2012 10:05:14 -0400 From: Joseph Lorenzo Hall Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (9B206) Message-Id: <36AFCAB5-44AC-49D7-8639-6F8F97646F75@cdt.org> Date: Tue, 9 Oct 2012 16:04:52 +0200 To: "geopriv@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: [Geopriv] apologies X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:05:20 -0000 I believe I've found a strange bug in Thinderbird that caused a mis-send to t= his list. Apologies; how embarrassing. best, Joe -- Joseph Lorenzo Hall Senior Staff Technologist Center for Democracy & Technology https://www.cdt.org/= From acooper@cdt.org Sat Oct 13 08:32:35 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030F521F852A for ; Sat, 13 Oct 2012 08:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHZiwAHIJfBW for ; Sat, 13 Oct 2012 08:32:29 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id C658321F84FD for ; Sat, 13 Oct 2012 08:32:29 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for geopriv@ietf.org; Sat, 13 Oct 2012 11:32:25 -0400 From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Oct 2012 16:32:23 +0100 Message-Id: <49E5F28A-1172-4FC1-A7FC-98DD396C98B2@cdt.org> To: GEOPRIV WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Geopriv] Agenda items X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 15:32:35 -0000 If you have something you'd like to present in Atlanta, please let me = know ASAP. Thanks, Alissa= From internet-drafts@ietf.org Wed Oct 17 00:58:44 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A9A21F8593; Wed, 17 Oct 2012 00:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzki+LfKLam9; Wed, 17 Oct 2012 00:58:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC88B21F851B; Wed, 17 Oct 2012 00:58:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121017075843.22421.71698.idtracker@ietfa.amsl.com> Date: Wed, 17 Oct 2012 00:58:43 -0700 Cc: geopriv@ietf.org Subject: [Geopriv] I-D Action: draft-ietf-geopriv-local-civic-08.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 07:58:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Geographic Location/Privacy Working Group= of the IETF. Title : Specifying Civic Address Extensions in PIDF-LO Author(s) : James Winterbottom Martin Thomson Richard Barnes Brian Rosen Robins George Filename : draft-ietf-geopriv-local-civic-08.txt Pages : 20 Date : 2012-10-17 Abstract: New fields are occasionally added to civic addresses. A backwardly- compatible mechanism for adding civic address elements to the Geopriv civic address format is described. A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation. Intial extensions for some new elements are also defined. The LoST (RFC5222) protocol mechanism that returns civic address element names used for validation of location information is clarified and is normatively updated to require a qualifying namespace identifier on each civic address element returned as part of the validation process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-geopriv-local-civic There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-geopriv-local-civic-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-geopriv-local-civic-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Oct 17 08:16:52 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B95521F86E5; Wed, 17 Oct 2012 08:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-lHx1NxdSQp; Wed, 17 Oct 2012 08:16:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF21C21F86B8; Wed, 17 Oct 2012 08:16:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121017151651.19101.43555.idtracker@ietfa.amsl.com> Date: Wed, 17 Oct 2012 08:16:51 -0700 Cc: geopriv@ietf.org Subject: [Geopriv] I-D Action: draft-ietf-geopriv-local-civic-09.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:16:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Geographic Location/Privacy Working Group= of the IETF. Title : Specifying Civic Address Extensions in PIDF-LO Author(s) : James Winterbottom Martin Thomson Richard Barnes Brian Rosen Robins George Filename : draft-ietf-geopriv-local-civic-09.txt Pages : 20 Date : 2012-10-17 Abstract: New fields are occasionally added to civic addresses. A backwardly- compatible mechanism for adding civic address elements to the Geopriv civic address format is described. A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation. Intial extensions for some new elements are also defined. The LoST (RFC5222) protocol mechanism that returns civic address element names used for validation of location information is clarified and is normatively updated to require a qualifying namespace identifier on each civic address element returned as part of the validation process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-geopriv-local-civic There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-geopriv-local-civic-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-geopriv-local-civic-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kjones@skyhookwireless.com Wed Oct 17 13:50:51 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9A721F8546 for ; Wed, 17 Oct 2012 13:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJt5B5C9oJrc for ; Wed, 17 Oct 2012 13:50:48 -0700 (PDT) Received: from server505.appriver.com (server505a.appriver.com [98.129.35.4]) by ietfa.amsl.com (Postfix) with ESMTP id 71AC121F86BB for ; Wed, 17 Oct 2012 13:50:47 -0700 (PDT) X-Note-AR-ScanTimeLocal: 10/17/2012 3:50:46 PM X-Policy: GLOBAL - skyhookwireless.com X-Primary: kjones@skyhookwireless.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @skyhookwireless.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: smtp.exg5.exghost.com X-Note-Return-Path: kjones@skyhookwireless.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G321 G322 G323 G324 G328 G329 G340 G436 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 329302584 for geopriv@ietf.org; Wed, 17 Oct 2012 15:50:46 -0500 Received: from MBX02.exg5.exghost.com ([169.254.2.43]) by HT09-e5.exg5.exghost.com ([98.129.23.242]) with mapi; Wed, 17 Oct 2012 15:50:45 -0500 From: Kipp Jones To: GEOPRIV WG Date: Wed, 17 Oct 2012 15:50:43 -0500 Thread-Topic: draft-jones-geopriv-sigpos-survey Thread-Index: Ac2sqRQkJP8KGdRcQPW9NMXNOFS6sQ== Message-ID: <44A96F3A-61ED-42F3-8F7C-36E1D650F392@skyhookwireless.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_44A96F3A61ED42F38F7C36E1D650F392skyhookwirelesscom_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 17 Oct 2012 13:57:10 -0700 Subject: Re: [Geopriv] draft-jones-geopriv-sigpos-survey X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 20:50:51 -0000 --_000_44A96F3A61ED42F38F7C36E1D650F392skyhookwirelesscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks again for all of the comments and apologies for a delayed response. = I've attempted to assimilate all of the comments and responses here and wi= ll provide an revision of the draft that incorporates these and cleans up a= couple of other nits. >>>Usage Models [Martin Thompson] There seem to be two verydifferent usage models: (1) crowd-source, (2) cont= racted to do asurvey with specialized equipment ... These models seem to b= e quite different, especially when one talks about licensing On reviewing the comments and discussions, I think this issue muddies the w= ater. The primary purpose of this specification is for 'formal' and 'semi-= formal' (directed) surveys of a given venue. Therefore, I'm stripping out = language and consideration for the 'crowdsourcing' of venue surveys and exp= licitly identifying this as not addressed. I believe there will be many di= fferent models that will be experimented with for the crowdsource model and= I think it is too early to try to nail down a specific model/specification= to encompass these use cases. However the process of performing a directed venue survey has been somethin= g that has been going on for years and should be able to be wrangled into a= structure that supports a more common model for interoperability, privacy,= and extensibility. >Licensing / Terms of Use There were several discussions on the topic of licensing, ownership and rel= ated topics. I'll try to summarize and respond below. The primary intent for including the licensing component in the specificati= on is to provide both data provenance as well as rights declarations for us= age of the data. I've simplified the structure to support a more focused se= t of licensing terms and clarified their meanings in this context. As several pointed out, the idea of data 'ownership' is a tricky one, espec= ially in light of the fact that this specification is covering signals that= are broadcast and in the public spectrum. However, it is not the signal i= nformation that is being addressed, rather the location information. To wh= it, the signals are associated with locations, some of which may be within = controlled access areas in a given venue. For example, it is reasonable th= at a corporation would desire to have accurate indoor location within it's = facilities, but they may not want this to be publicly accessible. The specific data is a product of the venue owner that either produced it o= r contracted to have it produced. Thus, there are no specific deterrents f= rom another person/company producing a similar dataset, excepting perhaps g= aining legal access to the facility for this purpose. To make this more clear, I've changed the wording from 'owner' to 'licensor= ', as this better describes the relationship and allows some flexibility as= to who the licensor is (venue owner, proprietor, leaser, etc.). >>>>[Martin Thompson]: This is a minor structuring point, but I think the location of the beacon is a property of the venue (at a point in time) instead of a property of the survey. I see a survey as a collection of measurements I agree with Martin's point, the intent is for the venue owner/manager to b= e able to retain rights to the location data that is generated during a ven= ue survey. Thus the rights to the location data generated by the survey is = the property of the licensor. It is feasible that somebody could surreptit= iously survey a venue without the consent of the venue owner, but I don't t= hink we want/should deal with that scenario within this specification. >Data Usage and Rights There is an additional issue having to do with derivative uses of the data.= Survey data at a high quality could be used to 'seed' a location system, = allowing an organization to build their own beacon location database over t= ime. At some point, the original data could be removed but the derived data= base could continue to be used. For data licensors who wish to protect fro= m this, the notion of derivative rights is included in the license structur= e. >>>>[Robin Wilton] I think the 'finesse' here might be to draw the distinction between i - the venue owner's entitlement to exercise their rights relating to the = premises, the private networks etc ii - the rights individuals might have relating to data about them that is = captured as a result of their presence/movement/actions in a given space This specification does not address the actual determination of end users l= ocations. Instead, it is concerned with the rights of the Venue data licen= sor with respect to their hardware and the location of that data and the re= lated signals. And, as I noted above, I am excluding the 'crowdsource' mod= el from this specification, thus eliminating the concerns (I hope) with res= pect to the location data of end users. >>>> [Martin Thompson] it may be possible to deal with licensing declaratio= ns out of band, I am interested in hearing a clear argument for why in-band= declaration of licensing in the interchange is the right way forward While I agree that it would be possible to deal with licensing in an out-of= -band model, the lack of connectivity between the data and the licensing is= at best disconcerting. Including the terms of use with the data means tha= t the terms travel with the data. There is no doubt about the terms. I'm l= eaning on my experience with software, wherein the license terms are either= spelled out within the code or have a reference to a specific license or s= et of terms of use. I believe the explicit linkage of data to the license provides a stronger b= ond between the two and thus more assurance that the terms will be honored. >>>Transport Mechanism [Adam Roach]What appears to be missing is a discussion of how these documen= ts move around the network. Based on the microphone discussion with the aut= hor, it appears that the current plan for moving this information around is= something like using PUT or POST requests over https. I think it would be = of great use to cover this topic, either in this document or in a separate = one. Thanks Adam, excellent call. I will add this to the new revision. The foc= us will be HTTP/TLS as transport. Key things to consider would be: * What https URL is used for the PUT or POST? I would expect the URL to be service provider dependent. Thus if Venue X p= roduced a survey of their Venue, they would likely already be in contact wi= th a location service provider to acquire the proper URL and credentials. I= t would also be reasonable for them to know their own URL in the case of se= lf-provisioning. o How is it provisioned into survey devices? The URL and credentials would be added during the configuration/set up for = the survey along with additional information (e.g. Licensor information, Bu= ilding location, Licensing info, etc.). o Is it valid to use http instead of https? HTTPS * What kind of authentication is used? Basic? Digest? Client certs? S/MIME = signatures? Something else? Basic over HTTPS * What can the client infer from the HTTP response code regarding the state= of the information it has submitted? Good question. I'm using RFC5985 (HELD) as a template for defining this sec= tion. If there is a better model, feel free to point it out. The draft re= vision will include this information. * Is there utility in defining additional transport mechanisms? Not currently, do you think there needs to be? o SIP SUBCRIBE/NOTIFY? Not sure why this would be necessary. o Is there value in distributing this information in Atom over HTTP? Again, not sure the value of this. Can you elaborate? * Do we need to define an inter-server protocol for exchanging information = between survey aggregators? I believe the same mechanism can be used for inter-aggregator communication= . >>>Capturing EMEA/Ephemerides [Martin Thompson] You might also consider capturing ephemerides if you are = capturing EMEA sentences and if you want an archival format. I'm looking into this to see what additional value the ephemeris data would= provide and how common this practice is. >>>Privacy Concerns wrt Device Characteristics [Martin Thompson] There are privacy implications on the use of device chara= cteristics, useful as they are. I believe the privacy concerns would be more applicable in a 'crowdsource' = model of survey. Do you still have concerns with respect to device charact= eristics in the directed survey model? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D FROM Alissa Cooper - IETF 84 Minutes -------------------------- Indoor Signal Position Conveyance by Kyp Jones (of Skyhook) --------------------------- Document: draft-jones-geopriv-sigpos-survey Slides: http://www.ietf.org/proceedings/84/slides/slides-84-geopriv-0.pdf -- Adam Roach: This is an interesting problem space. However, I don't see anything in the spec about transport mechanism for this data. How this is sent across the network will have a lot of affect Answer: I expect this will probably be transported by HTTPS, but I welcome discussion of how to talk about transport in the document -- Martin Thompson: I have read this. There seem to be two very different usage models: (1) crowd-source, (2) contracted to do a survey with specialized equipment ... These models seem to be quite different, especially when one talks about licensing ... I think it may be possible to deal with licensing declarations out of band, I am interested in hearing a clear argument for why in-band declaration of licensing in the interchange is the right way forward ... and you certainly make different use of data depending on what model it comes from ... raises questions about crowd-sourcing in private spaces Answer: There seems to be some fuzziness in the industry with regards to things like definitions of private spaces with regards to wireless signals. -- Martin Thompson: This is a minor structuring point, but I think the location of the beacon is a property of the venue (at a point in time) instead of a property of the survey. I see a survey as a collection of measurements. We should talk about this more offline -- Robin Wilton: I think this is interesting. I think there are some issues to explore which may be applicable to other contexts (in particular, from a privacy and data-rights point-of-view). 1. User opt-in opt-out by default 2. Transparency 3. Use of the data Therefore, it may be valuable to document some of these considerations in the document. -- Alissa: Question about the other players in this space. We have a lot of relevant expertise in this room, but we don't have all the people who would benefit from this standardization. Answer: This is somewhat of a chicken-egg problem. It is easier to get people interested in participating once if it has been accepted by a working group. I appreciate any guidance on how best to solve this chicken egg problem. -- Many hands think this is an interesting problem that could benefit from st Thanks Ted - entirely rational. I was perhaps misinterpreting the emphasis = of this work (i.e. on mapping the premises, rather than on mapping the move= ment of customers - so apologies if I was tilting at the wrong windmill ;^) I think the 'finesse' here might be to draw the distinction between i - the venue owner's entitlement to exercise their rights relating to the = premises, the private networks etc ii - the rights individuals might have relating to data about them that is = captured as a result of their presence/movement/actions in a given space (And I also fully appreciate that there are different legal contexts (and d= ifferent social expectations) relating to this, depending which country etc= this is happening in.) Engagement/discussion with venue owners would be great=85 because stakehold= er engagement is always good, and because down the road, one foreseeable ou= tcome is some form of self-regulatory code of conduct on the collection/use= of this kind of data. Yrs., Robin Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 1 Aug 2012, at 12:54, Ted Morgan wrote: Fair points and maybe there is better language to use but the venue owners = (think Best Buy, MGM Grand, Mall owners, corp campuses, Ball parks) are ver= y protective about what happens on their premises and do view those wifi ne= tworks as something very proprietary. These aren't public hotspots. Now, = we know that anyone can observe and collect these signals on their own, but= what is trying to be accomplished with this standard is to have the venue = owners participate in and drive the mapping of their venues. Some comments= we have heard "why should I let someone scan my ball park and then make mo= ney off of apps/services which we see none of?" "I don't want XXXX coming i= n here and mapping my store only to offer comparative shopping services to = show people how to leave my store and buy a product elsewhere". So if they= are going to be involved, they want control. We may not like it but our a= lternative is to watch the adoption move at the rate it has for the last te= n years (slow). With this model, they can say "anyone can come into my ven= ue and do detailed mapping as long as they support the standard". Hopefully the venue owners will get involved in this list as well so you ca= n hear their concerns directly. On Aug 1, 2012, at 2:20 PM, Robin Wilton wrote: The word 'ownership' always makes me nervous in this kind of context=85 and= apologies, this is one of my pet rant topics, so I promise not to beat the= subject to death. Bottom line: it may be healthier if we refer to venues a= s being 'data controllers', rather than 'data owners'. In brief, the underlying point is this: You've probably all seen privacy threads where an aggrieved data subject sa= ys "All I want is to be given back *my* data"=85 The implicit assumption is= that, in some way, I 'own' my [sic] personal data. Unfortunately, not far = down the line that leads to all kinds of unwanted consequences, and therefo= re we're better off not starting out with a model based on concepts of 'own= ership' if at all possible. For instance, as Bob Blakley pithly put it, "You can't control the stories = other people tell about you". There's lots of personal data about you over = which you have no control, let alone 'ownership', because it's generated by= other people. The only time you get control over it is, for instance, if t= he information is libellous. Even then, you don't get 'ownership' of the da= ta, but you get the opportunity to exercise certain rights pertaining to it= . Similarly, a model based on a concept of 'ownership' doesn't work well for = informational resources that can be 'stolen' from you, yet still leave you = in possession of the data. Think of copyright digital media=85 you own the = CD of Beethoven's 5th., but there are rights to do with the original work (= or the performance) that you don't enjoy. Legally, there are distinctions between the treatment of "personal property= " (or personalty) and "real property" (or realty), and if you want to delve= into that aspect, my own belief is that we're better off treating personal= data as if it were realty than as if it were personalty. (Happy to take th= at offline=85 ;^) I know this is a rather terse and dense statement of the issue, and my apol= ogies again for that - there are doubtless points here that could be unpack= ed ad infinitum - but suffice to say, I think an approach based on assumpti= ons of 'rights' over data has fewer problems than one based on assumptions = of 'ownership'. I think this is especially true of personal data (including= location/tracking/behavioural data): it makes little sense to claim that I= 'own' the data collected about my path through a shopping mall, but it mak= es s lot of sense to claim that I have certain rights relating to data abou= t me. Hope this is helpful - Robin Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 1 Aug 2012, at 10:29, Ted Morgan wrote: Well the venues will be unwilling to interchange their data if their is not= some licensing model associated with it. That ownership question has dram= atically slowed the adoption of indoor technologies. In fact venue owners = have told us data ownership is the single biggest factor keeping them from = deploying in-store location technology. If not part of a standard like thi= s, where would that *promise* be accommodated? On Aug 1, 2012, at 12:03 PM, Martin Thomson wrote: My own: Given what I know of the deployment models for this sort of technology, I don't see that license information is a) useful to an automaton, and b) necessary for a standardized interchange format. Also, I don't see the beacons as being relevant to the survey, but more to the venue. (You might also consider capturing ephemerides if you are capturing EMEA sentences and if you want an archival format.) There are privacy implications on the use of device characteristics, useful as they are. To Adam's points: I believe that there is a fair degree of pre-arrangement involved in this that may alleviate most of your concerns. A description of the two primary modes of operation is important, because that makes the considerations clearer. On 31 July 2012 14:02, Robin Wilton > wrote: Thanks Adam - In the same spirit, here's a quick recap of my remarks at the mic=85. The 'venue survey' use-case is an interesting one in its own right, but als= o gives an opportunity to explore issues which will be relevant to privacy in other contexts. Three such issues are: 1 - Opt-in versus opt-out by default. There have been a lot of 'opted-in-by-default' service deployments in recent years, with corresponding concern about user notice and consent. The venue survey use-case is an opportunity to explore the alternative of 'opted-out-by-default' and to look at ways of encouraging the data subject to take part on the basis of an engaged awareness. 2 - User transparency; as noted by another commenter, there's a potential lack of transparency here, with the consequence that individuals may have n= o idea that their information is being collected or why=85 A paper that explo= res the various possible means of making users aware of what's going on would b= e of value. 3 - The need to take account of possible third party access to the geolocation data collected through the survey. The temptation is to design for the 'straight-through' use-case where the only parties involved are the data subject, the venue owner and the data collector. For privacy purposes, the proposed document ought at least to acknowledge the risks arising out o= f potentially malicious third-party access to data collected. Hope this helps - Robin Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 31 Jul 2012, at 13:50, Adam Roach wrote: This is intended to be a reiteration of the points I made at the microphone today, for the purpose of stimulating discussion on the mailing list. The document covers an aspect of something that I think is interesting and has utility. At the moment, it covers a syntax for conveying survey information as well as a fairly rigorous description of what each element i= n that information means. What appears to be missing is a discussion of how these documents move around the network. Based on the microphone discussion with the author, it appears that the current plan for moving this information around is something like using PUT or POST requests over https. I think it would be o= f great use to cover this topic, either in this document or in a separate one= . Key things to consider would be: * What https URL is used for the PUT or POST? o How is it provisioned into survey devices? o Is it valid to use http instead of https? * What kind of authentication is used? Basic? Digest? Client certs? S/MIME signatures? Something else? * What can the client infer from the HTTP response code regarding the state of the information it has submitted? * Is there utility in defining additional transport mechanisms? o SIP SUBCRIBE/NOTIFY? o Is there value in distributing this information in Atom over HTTP? * Do we need to define an inter-server protocol for exchanging information between survey aggregators? In terms of permissions (which is related to the privacy question raised by the presentation), it seems that this kind of document would be well suited for talking about using Common Policy (RFC 4745). However, without having a better grip on the larger architecture in which these documents will be used, I can't really come up with useful suggestions about how such documents are conveyed/applied/etc. /a _______________________________________________ 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 _______________________________________________ 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 .............................................. Kipp Jones Chief Architect/Privacy Czar kjones@skyhookwireless.com m: 404.213.9293 | @skykipp .............................................. Kipp Jones Chief Architect/Privacy Czar kjones@skyhookwireless.com m: 404.213.9293 | @skykipp --_000_44A96F3A61ED42F38F7C36E1D650F392skyhookwirelesscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks again for= all of the comments and apologies for a delayed response.  I've attem= pted to assimilate all of the comments and responses here and will provide = an revision of the draft that incorporates these and cleans up a couple of = other nits.
 

>>>Usage Models [Martin Thompson] 
The= re seem to be two verydifferent usage models: (1) crowd-source, (2) contrac= ted to do asurvey with specialized equipment  ... These models seem to= be quite different, especially when one talks about licensing

On reviewing the comments and discuss= ions, I think this issue muddies the water.  The primary purpose of th= is specification is for 'formal' and 'semi-formal' (directed) surveys of a = given venue.  Therefore, I'm stripping out language and consideration = for the 'crowdsourcing' of venue surveys and explicitly identifying this as= not addressed.  I believe there will be many different models that wi= ll be experimented with for the crowdsource model and I think it is too ear= ly to try to nail down a specific model/specification to encompass these us= e cases.

However the process of performing a direc= ted venue survey has been something that has been going on for years and sh= ould be able to be wrangled into a structure that supports a more common mo= del for interoperability, privacy, and extensibility.

<= div>
>Licensing / Terms of Use 

There were several discussions on the topic of licensing, ownershi= p and related topics.  I'll try to summarize and respond below. <= /div>

The primary intent for including the licensi= ng component in the specification is to provide both data provenance as wel= l as rights declarations for usage of the data. I've simplified the structu= re to support a more focused set of licensing terms and clarified their mea= nings in this context.

As several pointed out= , the idea of data 'ownership' is a tricky one, especially in light of the = fact that this specification is covering signals that are broadcast and in = the public spectrum.  However, it is not the signal information that i= s being addressed, rather the location information.  To whit, the sign= als are associated with locations, some of which may be within controlled a= ccess areas in a given venue.  For example, it is reasonable that a co= rporation would desire to have accurate indoor location within it's facilit= ies, but they may not want this to be publicly accessible.

The specific data is a product of the venue owner that either prod= uced it or contracted to have it produced.  Thus, there are no specifi= c deterrents from another person/company producing a similar dataset, excep= ting perhaps gaining legal access to the facility for this purpose.

To make this more clear, I've changed the wording f= rom 'owner' to 'licensor', as this better describes the relationship and al= lows some flexibility as to who the licensor is (venue owner, proprietor, l= easer, etc.).


=

>>>>[Martin Thomp= son]: This is a minor structuring point, but I think the
locati= on of the beacon is a property of the venue (at a point in time)
= instead of a property of the survey. I see a survey as a collection of
measurements

I agr= ee with Martin's point, the intent is for the venue owner/manager to be abl= e to retain rights to the location data that is generated during a venue su= rvey. Thus the rights to the location data generated by the survey is the p= roperty of the licensor.  It is feasible that somebody could surreptit= iously survey a venue without the consent of the venue owner, but I don't t= hink we want/should deal with that scenario within this specification.


>Data Usage and Rights

There is an additional issue having to do with deriva= tive uses of the data.  Survey data at a high quality could be used to= 'seed' a location system, allowing an organization to build their own beac= on location database over time. At some point, the original data could be r= emoved but the derived database could continue to be used.  For data l= icensors who wish to protect from this, the notion of derivative rights is = included in the license structure.

>>>>[Robin Wilton]
=
>>>Transport Mechanism 
[Adam Roach]W= hat appears to be missing is a discussion of how these documents move = around the network. Based on the microphone discussion with the author, it&= nbsp;appears that the current plan for moving this information around is&nb= sp;something like using PUT or POST requests over https. I think it would b= e of great use to cover this topic, either in this document or in a se= parate one.

Thanks Adam, excel= lent call.  I will add this to the new revision.  The focus will = be HTTP/TLS as transport.


Key things to consider would be:
* What https URL is used for the= PUT or POST?

I= would expect the URL to be service provider dependent.  Thus if Venue= X produced a survey of their Venue, they would likely already be in contac= t with a location service provider to acquire the proper URL and credential= s. It would also be reasonable for them to know their own URL in the case o= f self-provisioning.

&n= bsp; o How is it provisioned into survey devices?


The URL and credentials would be added during th= e configuration/set up for the survey along with additional information (e.= g. Licensor information, Building location, Licensing info, etc.).

=
  o Is it valid to use http instead o= f https?

HTTPS


* What kind of aut= hentication is used? Basic? Digest? Client certs? S/MIME signatures? S= omething else?

Basic over HTTPS

* What can the client infer from the HT= TP response code regarding the state of the information it has submitt= ed?

Good question. I'm using RFC5985 (HELD= ) as a template for defining this section.  If there is a better model= , feel free to point it out.  The draft revision will include this inf= ormation.

* Is there utility in d= efining additional transport mechanisms?

Not currently, do you think there needs to be?


  o SIP SUBCRI= BE/NOTIFY?

Not sure why this would be nece= ssary.

  o Is there = value in distributing this information in Atom over HTTP?
<= br>
Again, not sure the value of this. Can you elaborate?
=



= * Do we need to define an inter-server protocol for exchanging informa= tion between survey aggregators?

I believe the same mechanism can be used for inter-aggregator communicat= ion.


>>>Capturing EMEA/Ephemerides
[Marti= n Thompson] You might also consider capturing ephemerides if you are c= apturing EMEA sentences and if you want an archival format.

I'm looking into this to see what addit= ional value the ephemeris data would provide and how common this practice i= s.


=
>>>Privacy Concerns wrt Device Char= acteristics
[Martin Thompson] There are privacy implicatio= ns on the use of device characteristics, useful as they are.

I believe the privacy concerns wo= uld be more applicable in a 'crowdsource' model of survey.  Do you sti= ll have concerns with respect to device characteristics in the directed sur= vey model?






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
FROM Alissa Cooper - IETF 84 Minutes

<= div>
--------------------------
Indoor Signal Position Conveyan= ce by Kyp Jones (of Skyhook)
---------------------------
Document: dr= aft-jones-geopriv-sigpos-survey
Slides: http://www.ietf.org/proc= eedings/84/slides/slides-84-geopriv-0.pdf

-- Adam Roach: This is= an interesting problem space. However, I don't
see anything in the spec= about transport mechanism for this data. How
this is sent across the ne= twork will have a lot of affect
Answer: I expect this will probably be t= ransported by HTTPS, but I
welcome discussion of how to talk about trans= port in the document

-- Martin Thompson: I have read this. There see= m to be two very
different usage models: (1) crowd-source, (2) contracte= d to do a
survey with specialized equipment
  ... These mod= els seem to be quite different, especially when one
talks about licensin= g
  ... I think it may be possible to deal with licensing
d= eclarations out of band, I am interested in hearing a clear argument
for= why in-band declaration of licensing in the interchange is the
right wa= y forward
  ... and you certainly make different use of data d= epending on
what model it comes from
  ... raises questions= about crowd-sourcing in private spaces
Answer: There seems to be some f= uzziness in the industry with
regards to things like definitions of priv= ate spaces with regards to
wireless signals.

-- Martin Thompson: = This is a minor structuring point, but I think the
location of the beaco= n is a property of the venue (at a point in time)
instead of a property = of the survey. I see a survey as a collection of
measurements. We should= talk about this more offline

-- Robin Wilton: I think this is inter= esting. I think there are some
issues to explore which may be applicable= to other contexts (in
particular, from a privacy and data-rights point-= of-view).
1. User opt-in opt-out by default
2. Transparency
3. Use= of the data
Therefore, it may be valuable to document some of these
= considerations in the document.

-- Alissa: Question about the other = players in this space. We have a
lot of relevant expertise in this room,= but we don't have all the
people who would benefit from this standardiz= ation.
Answer: This is somewhat of a chicken-egg problem. It is easier t= o
get people interested in participating once if it has been accepted by=
a working group. I appreciate any guidance on how best to solve thischicken egg problem.

-- Many hands think this is an interesting pro= blem that could benefit
from st





Thanks Ted - entirely rational. I was perh= aps misinterpreting the emphasis of this work (i.e. on mapping the premises= , rather than on mapping the movement of customers - so apologies if I was = tilting at the wrong windmill ;^)


I think= the 'finesse' here might be to draw the distinction between 

=
i - the venue owner's entitlement to exercise their rights relat= ing to the premises, the private networks etc

ii -= the rights individuals might have relating to data about them that is capt= ured as a result of their presence/movement/actions in a given space
<= div>
(And I also fully appreciate that there are different le= gal contexts (and different social expectations) relating to this, dependin= g which country etc this is happening in.)

Engagem= ent/discussion with venue owners would be great=85 because stakeholder enga= gement is always good, and because down the road, one foreseeable outcome i= s some form of self-regulatory code of conduct on the collection/use of thi= s kind of data.

Yrs.,
Robin
   
Robin Wilton
Technical Outreach Director - Identity and Privacy
Internet= Society

Phone: +44 705 005 2931
Twitt= er: @futureidentity




=
On 1 Aug 2012, at 12:54, Ted Morgan wrote:


Hopefully the venue owner= s will get involved in this list as well so you can hear their concerns dir= ectly.


On Aug 1, 2012, at 2:20 PM, Rob= in Wilton wrote:

The word 'ownership' always makes= me nervous in this kind of context=85 and apologies, this is one of my pet= rant topics, so I promise not to beat the subject to death. Bottom line: i= t may be healthier if we refer to venues as being 'data controllers', rathe= r than 'data owners'. 

In brief, the underlying poi= nt is this: 

You've probably all seen privacy= threads where an aggrieved data subject says "All I want is to be given ba= ck *my* data"=85 The implicit assumption is that, in some way, I 'own' my [= sic] personal data. Unfortunately, not far down the line that leads to all = kinds of unwanted consequences, and therefore we're better off not starting= out with a model based on concepts of 'ownership' if at all possible.

For instance, as Bob Blakley pithly put it, "You can't= control the stories other people tell about you". There's lots of personal= data about you over which you have no control, let alone 'ownership', beca= use it's generated by other people. The only time you get control over it i= s, for instance, if the information is libellous. Even then, you don't get = 'ownership' of the data, but you get the opportunity to exercise certain ri= ghts pertaining to it.
 
Similarly, a model based = on a concept of 'ownership' doesn't work well for informational resources t= hat can be 'stolen' from you, yet still leave you in possession of the data= . Think of copyright digital media=85 you own the CD of Beethoven's 5th., b= ut there are rights to do with the original work (or the performance) that = you don't enjoy.

Legally, there are distinctions b= etween the treatment of "personal property" (or personalty) and "real prope= rty" (or realty), and if you want to delve into that aspect, my own belief = is that we're better off treating personal data as if it were realty than a= s if it were personalty. (Happy to take that offline=85 ;^)

<= /div>
I know this is a rather terse and dense statement of the issue, a= nd my apologies again for that - there are doubtless points here that could= be unpacked ad infinitum - but suffice to say, I think an approach based o= n assumptions of 'rights' over data has fewer problems than one based on as= sumptions of 'ownership'. I think this is especially true of personal data = (including location/tracking/behavioural data): it makes little sense to cl= aim that I 'own' the data collected about my path through a shopping mall, = but it makes s lot of sense to claim that I have certain rights relating to= data about me.

Hope this is helpful - 
=


Robin

Robin Wilton
Technical Outreach Director - Identity and Privac= y
Internet Society

Phone: +44 705 00= 5 2931
Twitter: @futureidentity

=


On 1 Aug 2012, at 10:29, Ted Morgan wrote:<= /div>
Well= the venues will be unwilling to interchange their data if their is not som= e licensing model associated with it.  That ownership question has dra= matically slowed the adoption of indoor technologies.  In fact venue o= wners have told us data ownership is the single biggest factor keeping them= from deploying in-store location technology.  If not part of a standa= rd like this, where would that *promise* be accommodated?  

On Aug 1, 2012, at 12:03 PM, Martin Thomson wrote:

My own:

Given what I know of the deployment models for = this sort of
technology, I don't = see that license information is a) useful to an
automaton, and b) necessary for a standardized interchange f= ormat.

Also, I don't see the beacons as being relevant to the sur= vey, but
more to the venue.  = ;(You might also consider capturing ephemerides if
you are capturing EMEA sentences and if you want an archi= val format.)

There are privacy implications on the use of device = characteristics,
useful as they a= re.

To Adam's points:
<= br>
I believe that there is a fair de= gree of pre-arrangement involved in
this that may alleviate most of your concerns.  A description of th= e
two primary modes of operation = is important, because that makes the
considerations clearer.

<= /blockquote>
On 31 July 2012 14:02, Robin Wilton &= lt;wilton@isoc.org> wrote:
Thanks Adam -=

In the same spirit, here's a quick recap of my remarks at the= mic=85.

The 'venue survey' use-case is an interesting one in = its own right, but also
gives an opportunity to explore issues which = will be relevant to privacy in
other contexts. Three such issues are:=

1 - Opt-in versus opt-out by default. There have been a lot o= f
'opted-in-by-default' service deployments in recent years, with
corresponding concern about user notice and consent. The venue survey<= br>
use-case is an opportunity to explore the alternative of
'opted= -out-by-default' and to look at ways of encouraging the data subject
= to take part on the basis of an engaged awareness.

<= /blockquote>
2 - User tr= ansparency; as noted by another commenter, there's a potential
lack o= f transparency here, with the consequence that individuals may have no
<= /blockquote>
idea that their information is being collected or why=85 A paper that exp= lores
the various possible means of making users aware of what's goin= g on would be
of value.

3 - The need to take account of = possible third party access to the
geolocation data collected through= the survey. The temptation is to design
for the 'straight-through' u= se-case where the only parties involved are the
data subject, the ven= ue owner and the data collector. For privacy purposes,
the proposed d= ocument ought at least to acknowledge the risks arising out of
potent= ially malicious third-party access to data collected.

Hope thi= s helps -

Robin

Robin Wilton
Technical Out= reach Director - Identity and Privacy
Internet Society

e= mail: wilton@isoc.org
Pho= ne: +44 705 005 2931
Twitter: @futureidentity

=


On 31 Jul 2012, at 13:50, Adam Roach wrote:

This is= intended to be a reiteration of the points I made at the microphone
= today, for the purpose of stimulating discussion on the mailing list.

The document covers an aspect of something that I think is intere= sting and
has utility. At the moment, it covers a syntax for conveyin= g survey
information as well as a fairly rigorous description of what= each element in
that information means.

What appears to= be missing is a discussion of how these documents move
around the ne= twork. Based on the microphone discussion with the author, it
appears= that the current plan for moving this information around is
somethin= g like using PUT or POST requests over https. I think it would be of
= great use to cover this topic, either in this document or in a separate one= .

Key things to consider would be:

* What https= URL is used for the PUT or POST?
  o How is it provisioned= into survey devices?
  o Is it valid to use http instead o= f https?
* What kind of authentication is used? Basic? Digest? Client= certs?
S/MIME signatures? Something else?
* What can the clien= t infer from the HTTP response code regarding the
state of the inform= ation it has submitted?
* Is there utility in defining additional tra= nsport mechanisms?
<= blockquote type=3D"cite">  o SIP SUBCRIBE/NOTIFY?
 &nb= sp;o Is there value in distributing this information in Atom over HTTP?
=
* Do we need to define an inter-server protocol for exchanging
inf= ormation between survey aggregators?


In terms of permis= sions (which is related to the privacy question raised by
<= /blockquote>
the present= ation), it seems that this kind of document would be well suited
for = talking about using Common Policy (RFC 4745). However, without having a
=
better grip on the larger architecture in which these documents will be<= br>
used, I can't really come up with useful suggestions about how such
documents are conveyed/applied/etc.


/a

<= /blockquote>
_______________________________________________
Geopriv mailing lis= t
Geopriv@ietf.org
https://www.ietf.or= g/mailman/listinfo/geopriv


<= blockquote type=3D"cite">

_________________= ______________________________
Geopriv mailing list
<= /blockquote>
Geopriv@ietf.org
=
https://www.ietf.org/mailman/listinfo/ge= opriv

___= ____________________________________________
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



=
<= span class=3D"Apple-style-span" style=3D"color: rgb(192, 192, 192); font-fa= mily: Tahoma; font-size: 9px; ">...........................................= ... 
Kipp Jones<= /font>
Chief Architect/Privacy Cza= r
<= a href=3D"mailto:kjones@skyhookwireless.com">kjones@skyhookwireless.com=
m: 404.213.9293 | @skykipp

=
=
<= span class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: nor= mal; font-weight: normal; letter-spacing: normal; line-height: normal; orph= ans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows= : 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-bor= der-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webki= t-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">.......................= ....................... 
Kipp Jones
Chief Architect/= Privacy Czar
m: 404.213.9293 | @skykipp
=

= --_000_44A96F3A61ED42F38F7C36E1D650F392skyhookwirelesscom_-- From kjones@skyhookwireless.com Thu Oct 18 06:59:57 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC3B21F8807 for ; Thu, 18 Oct 2012 06:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAQX-Rhvpw8J for ; Thu, 18 Oct 2012 06:59:56 -0700 (PDT) Received: from server505.appriver.com (server505k.appriver.com [98.129.35.43]) by ietfa.amsl.com (Postfix) with ESMTP id AE02521F8732 for ; Thu, 18 Oct 2012 06:59:52 -0700 (PDT) X-Note-AR-ScanTimeLocal: 10/18/2012 8:59:52 AM X-Policy: GLOBAL - skyhookwireless.com X-Primary: kjones@skyhookwireless.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @skyhookwireless.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: X-Note-Return-Path: kjones@skyhookwireless.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G321 G322 G323 G324 G328 G329 G340 G436 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 41724102 for geopriv@ietf.org; Thu, 18 Oct 2012 08:59:52 -0500 Received: from MBX02.exg5.exghost.com ([169.254.2.43]) by HT04.exg5.exghost.com ([98.129.23.33]) with mapi; Thu, 18 Oct 2012 08:59:49 -0500 From: Kipp Jones To: GEOPRIV WG Date: Thu, 18 Oct 2012 08:59:47 -0500 Thread-Topic: draft-jones-geopriv-sigpos-survey Thread-Index: Ac2tONYJlwIg5kWrSPCumJRtID+VGQ== Message-ID: <6286B7FE-5345-4801-9E7B-1BC1087D8A52@skyhookwireless.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_6286B7FE534548019E7B1BC1087D8A52skyhookwirelesscom_" MIME-Version: 1.0 Subject: Re: [Geopriv] draft-jones-geopriv-sigpos-survey X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 13:59:57 -0000 --_000_6286B7FE534548019E7B1BC1087D8A52skyhookwirelesscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks again for all of the comments and apologies for a delayed response. = I've attempted to assimilate all of the comments and responses here and wi= ll provide an revision of the draft that incorporates these and cleans up a= couple of other nits. >>>Usage Models [Martin Thompson] There seem to be two verydifferent usage models: (1) crowd-source, (2) cont= racted to do asurvey with specialized equipment ... These models seem to b= e quite different, especially when one talks about licensing On reviewing the comments and discussions, I think this issue muddies the w= ater. The primary purpose of this specification is for 'formal' and 'semi-= formal' (directed) surveys of a given venue. Therefore, I'm stripping out = language and consideration for the 'crowdsourcing' of venue surveys and exp= licitly identifying this as not addressed. I believe there will be many di= fferent models that will be experimented with for the crowdsource model and= I think it is too early to try to nail down a specific model/specification= to encompass these use cases. However the process of performing a directed venue survey has been somethin= g that has been going on for years and should be able to be wrangled into a= structure that supports a more common model for interoperability, privacy,= and extensibility. >Licensing / Terms of Use There were several discussions on the topic of licensing, ownership and rel= ated topics. I'll try to summarize and respond below. The primary intent for including the licensing component in the specificati= on is to provide both data provenance as well as rights declarations for us= age of the data. I've simplified the structure to support a more focused se= t of licensing terms and clarified their meanings in this context. As several pointed out, the idea of data 'ownership' is a tricky one, espec= ially in light of the fact that this specification is covering signals that= are broadcast and in the public spectrum. However, it is not the signal i= nformation that is being addressed, rather the location information. To wh= it, the signals are associated with locations, some of which may be within = controlled access areas in a given venue. For example, it is reasonable th= at a corporation would desire to have accurate indoor location within it's = facilities, but they may not want this to be publicly accessible. The specific data is a product of the venue owner that either produced it o= r contracted to have it produced. Thus, there are no specific deterrents f= rom another person/company producing a similar dataset, excepting perhaps g= aining legal access to the facility for this purpose. To make this more clear, I've changed the wording from 'owner' to 'licensor= ', as this better describes the relationship and allows some flexibility as= to who the licensor is (venue owner, proprietor, leaser, etc.). >>>>[Martin Thompson]: This is a minor structuring point, but I think the location of the beacon is a property of the venue (at a point in time) instead of a property of the survey. I see a survey as a collection of measurements I agree with Martin's point, the intent is for the venue owner/manager to b= e able to retain rights to the location data that is generated during a ven= ue survey. Thus the rights to the location data generated by the survey is = the property of the licensor. It is feasible that somebody could surreptit= iously survey a venue without the consent of the venue owner, but I don't t= hink we want/should deal with that scenario within this specification. >Data Usage and Rights There is an additional issue having to do with derivative uses of the data.= Survey data at a high quality could be used to 'seed' a location system, = allowing an organization to build their own beacon location database over t= ime. At some point, the original data could be removed but the derived data= base could continue to be used. For data licensors who wish to protect fro= m this, the notion of derivative rights is included in the license structur= e. >>>>[Robin Wilton] I think the 'finesse' here might be to draw the distinction between i - the venue owner's entitlement to exercise their rights relating to the = premises, the private networks etc ii - the rights individuals might have relating to data about them that is = captured as a result of their presence/movement/actions in a given space This specification does not address the actual determination of end users l= ocations. Instead, it is concerned with the rights of the Venue data licen= sor with respect to their hardware and the location of that data and the re= lated signals. And, as I noted above, I am excluding the 'crowdsource' mod= el from this specification, thus eliminating the concerns (I hope) with res= pect to the location data of end users. >>>> [Martin Thompson] it may be possible to deal with licensing declaratio= ns out of band, I am interested in hearing a clear argument for why in-band= declaration of licensing in the interchange is the right way forward While I agree that it would be possible to deal with licensing in an out-of= -band model, the lack of connectivity between the data and the licensing is= at best disconcerting. Including the terms of use with the data means tha= t the terms travel with the data. There is no doubt about the terms. I'm l= eaning on my experience with software, wherein the license terms are either= spelled out within the code or have a reference to a specific license or s= et of terms of use. I believe the explicit linkage of data to the license provides a stronger b= ond between the two and thus more assurance that the terms will be honored. >>>Transport Mechanism [Adam Roach]What appears to be missing is a discussion of how these documen= ts move around the network. Based on the microphone discussion with the aut= hor, it appears that the current plan for moving this information around is= something like using PUT or POST requests over https. I think it would be = of great use to cover this topic, either in this document or in a separate = one. Thanks Adam, excellent call. I will add this to the new revision. The foc= us will be HTTP/TLS as transport. Key things to consider would be: * What https URL is used for the PUT or POST? I would expect the URL to be service provider dependent. Thus if Venue X p= roduced a survey of their Venue, they would likely already be in contact wi= th a location service provider to acquire the proper URL and credentials. I= t would also be reasonable for them to know their own URL in the case of se= lf-provisioning. o How is it provisioned into survey devices? The URL and credentials would be added during the configuration/set up for = the survey along with additional information (e.g. Licensor information, Bu= ilding location, Licensing info, etc.). o Is it valid to use http instead of https? HTTPS * What kind of authentication is used? Basic? Digest? Client certs? S/MIME = signatures? Something else? Basic over HTTPS * What can the client infer from the HTTP response code regarding the state= of the information it has submitted? Good question. I'm using RFC5985 (HELD) as a template for defining this sec= tion. If there is a better model, feel free to point it out. The draft re= vision will include this information. * Is there utility in defining additional transport mechanisms? Not currently, do you think there needs to be? o SIP SUBCRIBE/NOTIFY? Not sure why this would be necessary. o Is there value in distributing this information in Atom over HTTP? Again, not sure the value of this. Can you elaborate? * Do we need to define an inter-server protocol for exchanging information = between survey aggregators? I believe the same mechanism can be used for inter-aggregator communication= . >>>Capturing EMEA/Ephemerides [Martin Thompson] You might also consider capturing ephemerides if you are = capturing EMEA sentences and if you want an archival format. I'm looking into this to see what additional value the ephemeris data would= provide and how common this practice is. >>>Privacy Concerns wrt Device Characteristics [Martin Thompson] There are privacy implications on the use of device chara= cteristics, useful as they are. I believe the privacy concerns would be more applicable in a 'crowdsource' = model of survey. Do you still have concerns with respect to device charact= eristics in the directed survey model? Kipp .............................................. Kipp Jones Chief Architect/Privacy Czar kjones@skyhookwireless.com m: 404.213.9293 | @skykipp --_000_6286B7FE534548019E7B1BC1087D8A52skyhookwirelesscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks again for all= of the comments and apologies for a delayed response.  I've attempted= to assimilate all of the comments and responses here and will provide an r= evision of the draft that incorporates these and cleans up a couple of othe= r nits.
 

>>>Usage Models [Martin Thompson] 
There s= eem to be two verydifferent usage models: (1) crowd-source, (2) contracted = to do asurvey with specialized equipment  ... These models seem to be = quite different, especially when one talks about licensing

On reviewing the comments and discussions= , I think this issue muddies the water.  The primary purpose of this s= pecification is for 'formal' and 'semi-formal' (directed) surveys of a give= n venue.  Therefore, I'm stripping out language and consideration for = the 'crowdsourcing' of venue surveys and explicitly identifying this as not= addressed.  I believe there will be many different models that will b= e experimented with for the crowdsource model and I think it is too early t= o try to nail down a specific model/specification to encompass these use ca= ses.

However the process of performing a directed = venue survey has been something that has been going on for years and should= be able to be wrangled into a structure that supports a more common model = for interoperability, privacy, and extensibility.

=
>Licensing / Terms of Use 

=
There were several discussions on the topic of licensing, ownership an= d related topics.  I'll try to summarize and respond below. 

The primary intent for including the licensing c= omponent in the specification is to provide both data provenance as well as= rights declarations for usage of the data. I've simplified the structure t= o support a more focused set of licensing terms and clarified their meaning= s in this context.

As several pointed out, th= e idea of data 'ownership' is a tricky one, especially in light of the fact= that this specification is covering signals that are broadcast and in the = public spectrum.  However, it is not the signal information that is be= ing addressed, rather the location information.  To whit, the signals = are associated with locations, some of which may be within controlled acces= s areas in a given venue.  For example, it is reasonable that a corpor= ation would desire to have accurate indoor location within it's facilities,= but they may not want this to be publicly accessible.

=
The specific data is a product of the venue owner that either produced= it or contracted to have it produced.  Thus, there are no specific de= terrents from another person/company producing a similar dataset, excepting= perhaps gaining legal access to the facility for this purpose.
=

To make this more clear, I've changed the wording from = 'owner' to 'licensor', as this better describes the relationship and allows= some flexibility as to who the licensor is (venue owner, proprietor, lease= r, etc.).



>>>>[Martin Thompso= n]: This is a minor structuring point, but I think the
location= of the beacon is a property of the venue (at a point in time)
in= stead of a property of the survey. I see a survey as a collection of
<= div>measurements

I agree= with Martin's point, the intent is for the venue owner/manager to be able = to retain rights to the location data that is generated during a venue surv= ey. Thus the rights to the location data generated by the survey is the pro= perty of the licensor.  It is feasible that somebody could surreptitio= usly survey a venue without the consent of the venue owner, but I don't thi= nk we want/should deal with that scenario within this specification.
<= div>

>Data Usage and Rights
=
There is an additional issue having to do with derivati= ve uses of the data.  Survey data at a high quality could be used to '= seed' a location system, allowing an organization to build their own beacon= location database over time. At some point, the original data could be rem= oved but the derived database could continue to be used.  For data lic= ensors who wish to protect from this, the notion of derivative rights is in= cluded in the license structure.

>>>>[Robin Wilton]
= I think the 'finesse' here might be to draw the distinction between i - the venue owner's entitlement to exercise their rights relating to t= he premises, the private networks etc
ii - the rights individuals= might have relating to data about them that is captured as a result of the= ir presence/movement/actions in a given space
=
This specification does not address the actual = determination of end users locations.  Instead, it is concerned with t= he rights of the Venue data licensor with respect to their hardware and the= location of that data and the related signals.  And, as I noted above= , I am excluding the 'crowdsource' model from this specification, thus elim= inating the concerns (I hope) with respect to the location data of end user= s.


= >>>> [Martin Thompson] it may be possible to deal with licensin= g declarations out of band, I am interested in hearing a clear argument&nbs= p;for why in-band declaration of licensing in the interchange is the
rig= ht way forward

While I agree that it would = be possible to deal with licensing in an out-of-band model, the lack of con= nectivity between the data and the licensing is at best disconcerting. &nbs= p;Including the terms of use with the data means that the terms travel with= the data. There is no doubt about the terms.  I'm leaning on my exper= ience with software, wherein the license terms are either spelled out withi= n the code or have a reference to a specific license or set of terms of use= .

I believe the explicit linkage of data to the li= cense provides a stronger bond between the two and thus more assurance that= the terms will be honored.

>>>Transport Mechanism 
[Adam Roach]Wha= t appears to be missing is a discussion of how these documents move ar= ound the network. Based on the microphone discussion with the author, it&nb= sp;appears that the current plan for moving this information around is = ;something like using PUT or POST requests over https. I think it would be = of great use to cover this topic, either in this document or in a sepa= rate one.

Thanks Adam, excelle= nt call.  I will add this to the new revision.  The focus will be= HTTP/TLS as transport.


Key things to consider would be:
* What https URL is used for the P= UT or POST?

I w= ould expect the URL to be service provider dependent.  Thus if Venue X= produced a survey of their Venue, they would likely already be in contact = with a location service provider to acquire the proper URL and credentials.= It would also be reasonable for them to know their own URL in the case of = self-provisioning.

&nbs= p; o How is it provisioned into survey devices?


The URL and credentials would be added during the = configuration/set up for the survey along with additional information (e.g.= Licensor information, Building location, Licensing info, etc.).

  o Is it valid to use http instead of = https?

HTTPS


* What kind of authe= ntication is used? Basic? Digest? Client certs? S/MIME signatures? Som= ething else?

Basic over HTTPS

* What can the client infer from the HTTP= response code regarding the state of the information it has submitted= ?

Good question. I'm using RFC5985 (HELD) = as a template for defining this section.  If there is a better model, = feel free to point it out.  The draft revision will include this infor= mation.

* Is there utility in def= ining additional transport mechanisms?

<= /blockquote>Not currently, do you think there needs to be?


  o SIP SUBCRIBE/= NOTIFY?

Not sure why this would be necessa= ry.

  o Is there val= ue in distributing this information in Atom over HTTP?

=
Again, not sure the value of this. Can you elaborate?



* D= o we need to define an inter-server protocol for exchanging informatio= n between survey aggregators?

= I believe the same mechanism can be used for inter-aggregator communication= .


>>>Capturing EMEA/Ephemerides
[Martin T= hompson] You might also consider capturing ephemerides if you are capt= uring EMEA sentences and if you want an archival format.
=

I'm looking into this to see what addition= al value the ephemeris data would provide and how common this practice is.<= /div>


>>>Privacy Concerns wrt Device Charact= eristics
[Martin Thompson] There are privacy implications = on the use of device characteristics, useful as they are.
=

I believe the privacy concerns would= be more applicable in a 'crowdsource' model of survey.  Do you still = have concerns with respect to device characteristics in the directed survey= model?



Kipp

<= span class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: nor= mal; font-weight: normal; letter-spacing: normal; line-height: normal; orph= ans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows= : 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-bor= der-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webki= t-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">.......................= ....................... 
Kipp Jones
Chief Architect/= Privacy Czar
m: 404.213.9293 | @skykipp
=

= --_000_6286B7FE534548019E7B1BC1087D8A52skyhookwirelesscom_-- From ammar.salih@auis.edu.iq Thu Oct 18 13:03:51 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353D021F8457 for ; Thu, 18 Oct 2012 13:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlwzoIvbKLKY for ; Thu, 18 Oct 2012 13:03:50 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with SMTP id F3DCB21F842F for ; Thu, 18 Oct 2012 13:03:49 -0700 (PDT) Received: from mail-ea0-f198.google.com ([209.85.215.198]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKUIBgpUyeffqgEC+Ly7M+nuubLO1lokRy@postini.com; Thu, 18 Oct 2012 13:03:50 PDT Received: by mail-ea0-f198.google.com with SMTP id c11so4027639eaa.1 for ; Thu, 18 Oct 2012 13:03:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=OyG2x55P+lFtjaUb/PxI62axM9pnyGJgzbgSiR+LRdE=; b=imN41AD/oPWmABBMdXxDVFENQotVi3wymsCCyqdaxeJs++0HOfXdwiz7u9OeT/EVHI iPHwRP+n8u0294PKhomTNghlWsSXeQ/k2ndpsluOPp1mDwvNavlEdBeKjU78r1rgMuIJ X9t/dby+ROqZYi2aYV7hUNB1F0NV3eXclgHGXZZH440GxzAbe3iFJ312E3gaX60bsRre QNcHJlLpxbsfVci1yeDkVK2GZMrcdd+9PItrmqlJNWlQfdqURWo5/TBt2NAuu6B7SIRK 0hyiVjToQzvgZuqUpjL0gbCqjii15ZZ48/VvKY7lSAXWkeLnA3JNH9L1WhGaZJxXZreD n/Rg== Received: by 10.14.214.2 with SMTP id b2mr25198665eep.32.1350590628031; Thu, 18 Oct 2012 13:03:48 -0700 (PDT) Received: by 10.14.214.2 with SMTP id b2mr25198655eep.32.1350590627885; Thu, 18 Oct 2012 13:03:47 -0700 (PDT) Received: from AMMARSALIH ([95.159.79.188]) by mx.google.com with ESMTPS id 42sm41504812eee.0.2012.10.18.13.03.40 (version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 13:03:44 -0700 (PDT) From: "Ammar Salih" To: , References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> In-Reply-To: Date: Thu, 18 Oct 2012 23:03:32 +0300 Message-ID: <508060a0.42020e0a.3ead.ffff9089@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2nYb9+B2JU5/S2TjaXUBla9dpJ1wAGEG4wAXry01A= Content-Language: en-us X-Gm-Message-State: ALoCoQnzy8wk6WyM11c/otxQ3BG3xHhtc1jsyYdB+c7k7/N/VFfrtYzuO51SGirfxPx18Fbba4LSEl0wROaERATli35fi0tDxQN9BS9rJUq6Bx0dcJiUkVpCJdbl6PZxWnccdLx/vZtHnosKupJwd9ey59W9eyA+mQ== X-Mailman-Approved-At: Fri, 19 Oct 2012 05:18:34 -0700 Subject: Re: [Geopriv] IPv6 modification suggestion X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 20:03:51 -0000 Hello everyone, I had a brief look at GEOPRIV and I was very much impressed, There has been so much work done by this amazing group! At the same time, I would like to raise my concern regarding the http location request which will not be detected by layer-3 devices (Routers), I am anticipating that in the future, GPS capability will be added to the router itself (just like smart phones) and packet marking and classification based on geo-location will be required. QoS, firewall and routing based on geo-location will be highly demanded when mobile routers move from one geo-location to another which has different regulations/electronic laws. Here is an example, if your router is within city-X and this city has very good electronic and copyright laws, then users will have relaxed network security settings, but what if the very same router moved to city-Y which according to its law, certain websites should be blocked (like facebook in china for example) .. these rules based on geographic location won't be feasible unless the mobile router has a GPS and can read/write coordinates to layer-3 packets. Best, Ammar -----Original Message----- From: Ammar Salih [mailto:ammar.salih@auis.edu.iq] Sent: Thursday, October 11, 2012 11:41 AM To: 'Bob Hinden' Cc: 'ipv6@ietf.org' Subject: RE: IPv6 modification suggestion Hello Bob, > That said, I don't think it is a good idea to add GPS position to every IPv6 header. It would add a lot of overhead. It does not have to be in every IPv6 header, only when there is location update, also it can be included in the first header (just like RTP and cRTP) > there are many privacy related issues (as others have pointed out). This can be set manually in case of any privacy concerns, just like other header's information like IP address. > An alternative would be to create a application layer protocols that could request and send GPS positions. Sounds awesom, but in this case all webpages, phone applications, server side scripting languages ... etc have to be modified to support the new application protocol. Not mensioning that layer 3 devices (like routers) won't be able to support the feature, let's say in the feature you want to do dynamic routing based on geo location. In anycase, I still feel quite interested about the new layer 7 protocol, will try to go through the GEOPRIV documentation this weekend in order to get more details. Thank you for your kind response, Ammar -----Original Message----- From: Bob Hinden [mailto:bob.hinden@gmail.com] Sent: Thursday, October 11, 2012 6:37 AM To: Ammar Salih Cc: Bob Hinden; ipv6@ietf.org Subject: Re: IPv6 modification suggestion Ammar, On Oct 10, 2012, at 7:52 AM, Ammar Salih wrote: > Hello Dears, > > I would like to suggest adding GPS coordinates to IPv6 header, as you know the current way of determining the location of the IP address is through the IP registration, which is not very accurate as it depends on how the ISP registers it's IP subnets, which is normally done based on country/city. I agree with you that IP addresses are not very reliable as a means of determining geographic location. That said, I don't think it is a good idea to add GPS position to every IPv6 header. It would add a lot of overhead, there are many privacy related issues (as others have pointed out), it doesn't need to be in every packet. An alternative would be to create a application layer protocols that could request and send GPS positions. That is a better way to to deal with the privacy issues and the GPS position would only need to be sent when desired or when requested. The GEOPRIV working group is doing some work in this area. See: http://datatracker.ietf.org/wg/geopriv/charter/ Bob > > Getting more accurate locations will enhance many services provided by the web, like targeted commercials (for example, I can get Ads regarding restaurants available in my neighborhood instead of all restaurants in the city), another good example would be webpage's language, my language will be detected more accurately based on my exact area rather than my countery, as there are many countries with more than one popular language. > > Maps, navigation, emergency calls and many other services will also get enhanced with accurate locations. > > I hope you will find my suggestion beneficial, and looking forward to hearing from you. > > > Best, > > Ammar Salih | B.Sc.Eng, CCNA-S, CCVP, CCIE-V written Technical Lead - > Voice and Data Support Services > > Mob: +964 (0) 770 533 0306 > Office: +964 (0) 53 511 2020 - Ext. 2221 > Email: ammar.salih@auis.edu.iq > The American University of Iraq - Sulaimani > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From rbarnes@bbn.com Fri Oct 19 05:46:07 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6674B21F8594 for ; Fri, 19 Oct 2012 05:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYcYwb42wTxV for ; Fri, 19 Oct 2012 05:46:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCC121F84F1 for ; Fri, 19 Oct 2012 05:46:06 -0700 (PDT) Received: from ros-dhcp192-1-51-103.bbn.com ([192.1.51.103]:63646) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TPBxj-000PSy-F7; Fri, 19 Oct 2012 08:46:03 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: <508060a0.42020e0a.3ead.ffff9089@mx.google.com> Date: Fri, 19 Oct 2012 08:46:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6CBCC380-E419-443C-88B1-17C85105E648@bbn.com> References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> <508060a0.42020e0a.3ead.ffff9089@mx.google.com> To: "Ammar Salih" X-Mailer: Apple Mail (2.1283) Cc: geopriv@ietf.org Subject: Re: [Geopriv] IPv6 modification suggestion X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 12:46:07 -0000 Hi Ammar, Thanks for your interesting use case. Adaptation of services based on = geolocation is something that GEOPRIV is intended to support. One = example you might consider is ECRIT [1]. In that system, the end device = or its proxy discovers how to direct an emergency call based on the = caller's geolocation.=20 Is your concern really at layer 3, or is it specific to certain = application-layer protocols? For example, if you are primarily = concerned with HTTP / web filtering, it might be that what you really = want is an HTTP header for geolocation, similar to the SIP Geolocation = header [2]. There have been proposals for such an HTTP header before, = and there was not much interest. But if you think there would be people = interested in using this header, then it could be something that we = could work on in GEOPRIV. =20 Keep in mind that in order to make these things useful, though, the end = host has to actually populate the field. So you'll need to convince = either OS vendors (for an IPv6 header) or browser vendors (HTTP header) = that this is a good idea. Cheers, --Richard [1] =20 [2] [3] = On Oct 18, 2012, at 4:03 PM, Ammar Salih wrote: > Hello everyone, I had a brief look at GEOPRIV and I was very much = impressed, > There has been so much work done by this amazing group! >=20 > At the same time, I would like to raise my concern regarding the http > location request which will not be detected by layer-3 devices = (Routers), I > am anticipating that in the future, GPS capability will be added to = the > router itself (just like smart phones) and packet marking and = classification > based on geo-location will be required. >=20 > QoS, firewall and routing based on geo-location will be highly = demanded when > mobile routers move from one geo-location to another which has = different > regulations/electronic laws. >=20 > Here is an example, if your router is within city-X and this city has = very > good electronic and copyright laws, then users will have relaxed = network > security settings, but what if the very same router moved to city-Y = which > according to its law, certain websites should be blocked (like = facebook in > china for example) .. these rules based on geographic location won't = be > feasible unless the mobile router has a GPS and can read/write = coordinates > to layer-3 packets. >=20 > Best, > Ammar >=20 >=20 > -----Original Message----- > From: Ammar Salih [mailto:ammar.salih@auis.edu.iq]=20 > Sent: Thursday, October 11, 2012 11:41 AM > To: 'Bob Hinden' > Cc: 'ipv6@ietf.org' > Subject: RE: IPv6 modification suggestion >=20 > Hello Bob, >=20 >> That said, I don't think it is a good idea to add GPS position to = every > IPv6 header. It would add a lot of overhead. >=20 > It does not have to be in every IPv6 header, only when there is = location > update, also it can be included in the first header (just like RTP and = cRTP) >=20 >=20 >=20 >> there are many privacy related issues (as others have pointed out). >=20 > This can be set manually in case of any privacy concerns, just like = other > header's information like IP address. >=20 >=20 >=20 >> An alternative would be to create a application layer protocols that = could > request and send GPS positions. =20 >=20 > Sounds awesom, but in this case all webpages, phone applications, = server > side scripting languages ... etc have to be modified to support the = new > application protocol. Not mensioning that layer 3 devices (like = routers) > won't be able to support the feature, let's say in the feature you = want to > do dynamic routing based on geo location. >=20 >=20 > In anycase, I still feel quite interested about the new layer 7 = protocol, > will try to go through the GEOPRIV documentation this weekend in order = to > get more details. >=20 > Thank you for your kind response, > Ammar >=20 >=20 >=20 > -----Original Message----- > From: Bob Hinden [mailto:bob.hinden@gmail.com] > Sent: Thursday, October 11, 2012 6:37 AM > To: Ammar Salih > Cc: Bob Hinden; ipv6@ietf.org > Subject: Re: IPv6 modification suggestion >=20 > Ammar, >=20 > On Oct 10, 2012, at 7:52 AM, Ammar Salih wrote: >=20 >> Hello Dears, >>=20 >> I would like to suggest adding GPS coordinates to IPv6 header, as you = know > the current way of determining the location of the IP address is = through the > IP registration, which is not very accurate as it depends on how the = ISP > registers it's IP subnets, which is normally done based on = country/city. >=20 > I agree with you that IP addresses are not very reliable as a means of > determining geographic location. That said, I don't think it is a = good idea > to add GPS position to every IPv6 header. It would add a lot of = overhead, > there are many privacy related issues (as others have pointed out), it > doesn't need to be in every packet. An alternative would be to create = a > application layer protocols that could request and send GPS positions. = That > is a better way to to deal with the privacy issues and the GPS = position > would only need to be sent when desired or when requested. >=20 > The GEOPRIV working group is doing some work in this area. See: >=20 > http://datatracker.ietf.org/wg/geopriv/charter/ >=20 > Bob >=20 >=20 >>=20 >> Getting more accurate locations will enhance many services provided = by the > web, like targeted commercials (for example, I can get Ads regarding > restaurants available in my neighborhood instead of all restaurants in = the > city), another good example would be webpage's language, my language = will be > detected more accurately based on my exact area rather than my = countery, as > there are many countries with more than one popular language. >>=20 >> Maps, navigation, emergency calls and many other services will also = get > enhanced with accurate locations. >>=20 >> I hope you will find my suggestion beneficial, and looking forward to > hearing from you. >>=20 >>=20 >> Best, >>=20 >> Ammar Salih | B.Sc.Eng, CCNA-S, CCVP, CCIE-V written Technical Lead -=20= >> Voice and Data Support Services >>=20 >> Mob: +964 (0) 770 533 0306 >> Office: +964 (0) 53 511 2020 - Ext. 2221 >> Email: ammar.salih@auis.edu.iq >> The American University of Iraq - Sulaimani >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From ammar.salih@auis.edu.iq Sun Oct 21 15:33:35 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39ADF21F88E3 for ; Sun, 21 Oct 2012 15:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZu1j3O2lOER for ; Sun, 21 Oct 2012 15:33:34 -0700 (PDT) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with SMTP id 4E30721F88F3 for ; Sun, 21 Oct 2012 15:33:33 -0700 (PDT) Received: from mail-fa0-f70.google.com ([209.85.161.70]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKUIR4PDr+VKW0S0TggTvOaDZ+/Sjz0sWn@postini.com; Sun, 21 Oct 2012 15:33:33 PDT Received: by mail-fa0-f70.google.com with SMTP id v1so1890707fav.1 for ; Sun, 21 Oct 2012 15:33:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=jqu/mTsjUkCOR9gVbsix7Mpb51XGJpwT+cY2Cs0nfBY=; b=W+wORXYYARtYcoK4fBTuHZQGNJDFuJSP3q7cPy4DmkPTpl9k8ImjxNPD8sxdNHkHYv 50ltyt5xZPfYP/5J9WlE63M0lm2sYyI2aFJ4/M3nCa/EhpOWzsOiG7Et3b4aLQksltVq g9O/z5wvMaTEoAeiF0xRM3LEtsmaUESQOva98uuDcPMxJvOaxmzhcImdrB3IcawkesIi 8nviotOo/ukuzBZAY9xLqEVH/p0pK4u1Bzk61fPkj3Uf7X2EHFun0z//W7e/9LcHJydU z8ZW6ko8dH5xdIlZi6vRHxHYiXaFaV0Lqeu3IEzd7IpO35LOLYiB3Z5hHUzpthk70XFF mTwA== Received: by 10.180.97.35 with SMTP id dx3mr16838412wib.14.1350858811390; Sun, 21 Oct 2012 15:33:31 -0700 (PDT) Received: by 10.180.97.35 with SMTP id dx3mr16838397wib.14.1350858811098; Sun, 21 Oct 2012 15:33:31 -0700 (PDT) Received: from AMMARSALIH ([95.159.78.55]) by mx.google.com with ESMTPS id dt9sm48041853wib.1.2012.10.21.15.33.27 (version=SSLv3 cipher=OTHER); Sun, 21 Oct 2012 15:33:30 -0700 (PDT) From: "Ammar Salih" To: "'Richard Barnes'" References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> <508060a0.42020e0a.3ead.ffff9089@mx.google.com> <6CBCC380-E419-443C-88B1-17C85105E648@bbn.com> In-Reply-To: <6CBCC380-E419-443C-88B1-17C85105E648@bbn.com> Date: Mon, 22 Oct 2012 01:33:21 +0300 Message-ID: <5084783a.a960b40a.0296.1ca1@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2t97k+fDxBmAiAQueZowHetvD9CwB4X5gQ Content-Language: en-us X-Gm-Message-State: ALoCoQmt4WHsiIIMJQpdJ+0XOZM8IxYuzU1E5k9UEsns3xB+81NdG3CvjS+C/cLiLaaziWt6uk/moQdSBMu8NjMzl2XnzvmCkHJcgGAPlieoISTR6gEoNEXlkUfQ9AvMAAyCQYvjguPaIQDLKQuqXU+rg9IQl8j3XA== X-Mailman-Approved-At: Mon, 22 Oct 2012 05:59:39 -0700 Cc: geopriv@ietf.org Subject: Re: [Geopriv] IPv6 modification suggestion X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 22:33:35 -0000 Hello Richard, My concern is that IETF is integrating location field in each application separatly, like GEOPRV, SIP Geo header .. etc, plus implementing application layer protocol is feasible in application servers only, network devices won't have the cabability to understand the feature. I've given few examples to IPv6 team regarding geo-location involvement, one would be location-based ACL, another would be location-based routing protocol. I anticipate that one day, layer 3-7 location-based policies will be integrated into one header, as GPS devices becoming smaller and accurate cooedinates are higly required. Thanks, Ammar -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com] Sent: Friday, October 19, 2012 3:46 PM To: Ammar Salih Cc: geopriv@ietf.org Subject: Re: [Geopriv] IPv6 modification suggestion Hi Ammar, Thanks for your interesting use case. Adaptation of services based on geolocation is something that GEOPRIV is intended to support. One example you might consider is ECRIT [1]. In that system, the end device or its proxy discovers how to direct an emergency call based on the caller's geolocation. Is your concern really at layer 3, or is it specific to certain application-layer protocols? For example, if you are primarily concerned with HTTP / web filtering, it might be that what you really want is an HTTP header for geolocation, similar to the SIP Geolocation header [2]. There have been proposals for such an HTTP header before, and there was not much interest. But if you think there would be people interested in using this header, then it could be something that we could work on in GEOPRIV. Keep in mind that in order to make these things useful, though, the end host has to actually populate the field. So you'll need to convince either OS vendors (for an IPv6 header) or browser vendors (HTTP header) that this is a good idea. Cheers, --Richard [1] [2] [3] On Oct 18, 2012, at 4:03 PM, Ammar Salih wrote: > Hello everyone, I had a brief look at GEOPRIV and I was very much > impressed, There has been so much work done by this amazing group! > > At the same time, I would like to raise my concern regarding the http > location request which will not be detected by layer-3 devices > (Routers), I am anticipating that in the future, GPS capability will > be added to the router itself (just like smart phones) and packet > marking and classification based on geo-location will be required. > > QoS, firewall and routing based on geo-location will be highly > demanded when mobile routers move from one geo-location to another > which has different regulations/electronic laws. > > Here is an example, if your router is within city-X and this city has > very good electronic and copyright laws, then users will have relaxed > network security settings, but what if the very same router moved to > city-Y which according to its law, certain websites should be blocked > (like facebook in china for example) .. these rules based on > geographic location won't be feasible unless the mobile router has a > GPS and can read/write coordinates to layer-3 packets. > > Best, > Ammar > > > -----Original Message----- > From: Ammar Salih [mailto:ammar.salih@auis.edu.iq] > Sent: Thursday, October 11, 2012 11:41 AM > To: 'Bob Hinden' > Cc: 'ipv6@ietf.org' > Subject: RE: IPv6 modification suggestion > > Hello Bob, > >> That said, I don't think it is a good idea to add GPS position to >> every > IPv6 header. It would add a lot of overhead. > > It does not have to be in every IPv6 header, only when there is > location update, also it can be included in the first header (just > like RTP and cRTP) > > > >> there are many privacy related issues (as others have pointed out). > > This can be set manually in case of any privacy concerns, just like > other header's information like IP address. > > > >> An alternative would be to create a application layer protocols that >> could > request and send GPS positions. > > Sounds awesom, but in this case all webpages, phone applications, > server side scripting languages ... etc have to be modified to support > the new application protocol. Not mensioning that layer 3 devices > (like routers) won't be able to support the feature, let's say in the > feature you want to do dynamic routing based on geo location. > > > In anycase, I still feel quite interested about the new layer 7 > protocol, will try to go through the GEOPRIV documentation this > weekend in order to get more details. > > Thank you for your kind response, > Ammar > > > > -----Original Message----- > From: Bob Hinden [mailto:bob.hinden@gmail.com] > Sent: Thursday, October 11, 2012 6:37 AM > To: Ammar Salih > Cc: Bob Hinden; ipv6@ietf.org > Subject: Re: IPv6 modification suggestion > > Ammar, > > On Oct 10, 2012, at 7:52 AM, Ammar Salih wrote: > >> Hello Dears, >> >> I would like to suggest adding GPS coordinates to IPv6 header, as you >> know > the current way of determining the location of the IP address is > through the IP registration, which is not very accurate as it depends > on how the ISP registers it's IP subnets, which is normally done based on country/city. > > I agree with you that IP addresses are not very reliable as a means of > determining geographic location. That said, I don't think it is a > good idea to add GPS position to every IPv6 header. It would add a > lot of overhead, there are many privacy related issues (as others have > pointed out), it doesn't need to be in every packet. An alternative > would be to create a application layer protocols that could request > and send GPS positions. That is a better way to to deal with the > privacy issues and the GPS position would only need to be sent when desired or when requested. > > The GEOPRIV working group is doing some work in this area. See: > > http://datatracker.ietf.org/wg/geopriv/charter/ > > Bob > > >> >> Getting more accurate locations will enhance many services provided >> by the > web, like targeted commercials (for example, I can get Ads regarding > restaurants available in my neighborhood instead of all restaurants in > the city), another good example would be webpage's language, my > language will be detected more accurately based on my exact area > rather than my countery, as there are many countries with more than one popular language. >> >> Maps, navigation, emergency calls and many other services will also >> get > enhanced with accurate locations. >> >> I hope you will find my suggestion beneficial, and looking forward to > hearing from you. >> >> >> Best, >> >> Ammar Salih | B.Sc.Eng, CCNA-S, CCVP, CCIE-V written Technical Lead - >> Voice and Data Support Services >> >> Mob: +964 (0) 770 533 0306 >> Office: +964 (0) 53 511 2020 - Ext. 2221 >> Email: ammar.salih@auis.edu.iq >> The American University of Iraq - Sulaimani >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From rbarnes@bbn.com Mon Oct 22 06:12:06 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D49D21F8B8C for ; Mon, 22 Oct 2012 06:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BUX6WKnL1vG for ; Mon, 22 Oct 2012 06:12:05 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 629D221F88C1 for ; Mon, 22 Oct 2012 06:12:05 -0700 (PDT) Received: from ros-dhcp192-1-51-103.bbn.com ([192.1.51.103]:55162) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TQHnY-000FEz-1F; Mon, 22 Oct 2012 09:12:04 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: <5084783a.a960b40a.0296.1ca1@mx.google.com> Date: Mon, 22 Oct 2012 09:12:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <78A28703-EFED-44B9-BC93-C0CF8729B1CB@bbn.com> References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> <508060a0.42020e0a.3ead.ffff9089@mx.google.com> <6CBCC380-E419-443C-88B1-17C85105E648@bbn.com> <5084783a.a960b40a.0296.1ca1@mx.google.com> To: Ammar Salih X-Mailer: Apple Mail (2.1283) Cc: geopriv@ietf.org Subject: Re: [Geopriv] IPv6 modification suggestion X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 13:12:06 -0000 Hi Ammar, I think that if you think through your examples more carefully, you'll = see that an IPv6 extension header for geolocation doesn't really solve = the problem you want. =20 For geolocation-based ACLs: you have the problem that if the geolocation = is attached by the endpoint, then it can't be trusted, since the = endpoint would lie to get past the ACL. If it's attached by a router, = the ACL needs to have proof that the router attached it (and not the = endpoint), which means that you would need a signed geolocation header. = The routing community is already having enough trouble implementing = signatures on BGP messages [1]; a signature on every packet would = probably not be viable. It would make the router do about as much as a = VPN concentrator. For location-based routing protocols: Why would you want this? = Geographical location isn't actually that important a metric for = routing; what you care about there is *topological* location, how far I = am away from you in terms of hops or latency. People will go to great = lengths to reduce topological distances (CDNs, cables under the arctic). = But prior proposals for geolocation-based routing in the IETF (going = back to 1996) have failed [2][3][4]. What would be the use case for = geography-based routing? Enforcement of local policies? I am also not as optimistic as you are about GPS being everywhere. For = example, GPS does a really poor job inside of buildings. That's why we = invented GEOPRIV in the first place, to help out where GPS fails!=20 Nonetheless, if you have written a paper or Internet-draft about your = proposed extension to IPv6, I would be glad to read it and provide = comments. Cheers, --Richard [1] [2] [3] [4] On Oct 21, 2012, at 6:33 PM, Ammar Salih wrote: > Hello Richard, >=20 > My concern is that IETF is integrating location field in each = application > separatly, like GEOPRV, SIP Geo header .. etc, plus implementing = application > layer protocol is feasible in application servers only, network = devices > won't have the cabability to understand the feature. I've given few = examples > to IPv6 team regarding geo-location involvement, one would be = location-based > ACL, another would be location-based routing protocol. >=20 > I anticipate that one day, layer 3-7 location-based policies will be > integrated into one header, as GPS devices becoming smaller and = accurate > cooedinates are higly required. >=20 > Thanks, > Ammar >=20 >=20 >=20 > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com]=20 > Sent: Friday, October 19, 2012 3:46 PM > To: Ammar Salih > Cc: geopriv@ietf.org > Subject: Re: [Geopriv] IPv6 modification suggestion >=20 > Hi Ammar, >=20 > Thanks for your interesting use case. Adaptation of services based on > geolocation is something that GEOPRIV is intended to support. One = example > you might consider is ECRIT [1]. In that system, the end device or = its > proxy discovers how to direct an emergency call based on the caller's > geolocation.=20 >=20 > Is your concern really at layer 3, or is it specific to certain > application-layer protocols? For example, if you are primarily = concerned > with HTTP / web filtering, it might be that what you really want is an = HTTP > header for geolocation, similar to the SIP Geolocation header [2]. = There > have been proposals for such an HTTP header before, and there was not = much > interest. But if you think there would be people interested in using = this > header, then it could be something that we could work on in GEOPRIV. =20= >=20 > Keep in mind that in order to make these things useful, though, the = end host > has to actually populate the field. So you'll need to convince either = OS > vendors (for an IPv6 header) or browser vendors (HTTP header) that = this is a > good idea. >=20 > Cheers, > --Richard >=20 >=20 > [1] > [2] > [3] = >=20 >=20 > On Oct 18, 2012, at 4:03 PM, Ammar Salih wrote: >=20 >> Hello everyone, I had a brief look at GEOPRIV and I was very much=20 >> impressed, There has been so much work done by this amazing group! >>=20 >> At the same time, I would like to raise my concern regarding the http=20= >> location request which will not be detected by layer-3 devices=20 >> (Routers), I am anticipating that in the future, GPS capability will=20= >> be added to the router itself (just like smart phones) and packet=20 >> marking and classification based on geo-location will be required. >>=20 >> QoS, firewall and routing based on geo-location will be highly=20 >> demanded when mobile routers move from one geo-location to another=20 >> which has different regulations/electronic laws. >>=20 >> Here is an example, if your router is within city-X and this city has=20= >> very good electronic and copyright laws, then users will have relaxed=20= >> network security settings, but what if the very same router moved to=20= >> city-Y which according to its law, certain websites should be blocked=20= >> (like facebook in china for example) .. these rules based on=20 >> geographic location won't be feasible unless the mobile router has a=20= >> GPS and can read/write coordinates to layer-3 packets. >>=20 >> Best, >> Ammar >>=20 >>=20 >> -----Original Message----- >> From: Ammar Salih [mailto:ammar.salih@auis.edu.iq] >> Sent: Thursday, October 11, 2012 11:41 AM >> To: 'Bob Hinden' >> Cc: 'ipv6@ietf.org' >> Subject: RE: IPv6 modification suggestion >>=20 >> Hello Bob, >>=20 >>> That said, I don't think it is a good idea to add GPS position to=20 >>> every >> IPv6 header. It would add a lot of overhead. >>=20 >> It does not have to be in every IPv6 header, only when there is=20 >> location update, also it can be included in the first header (just=20 >> like RTP and cRTP) >>=20 >>=20 >>=20 >>> there are many privacy related issues (as others have pointed out). >>=20 >> This can be set manually in case of any privacy concerns, just like=20= >> other header's information like IP address. >>=20 >>=20 >>=20 >>> An alternative would be to create a application layer protocols that=20= >>> could >> request and send GPS positions. =20 >>=20 >> Sounds awesom, but in this case all webpages, phone applications,=20 >> server side scripting languages ... etc have to be modified to = support=20 >> the new application protocol. Not mensioning that layer 3 devices=20 >> (like routers) won't be able to support the feature, let's say in the=20= >> feature you want to do dynamic routing based on geo location. >>=20 >>=20 >> In anycase, I still feel quite interested about the new layer 7=20 >> protocol, will try to go through the GEOPRIV documentation this=20 >> weekend in order to get more details. >>=20 >> Thank you for your kind response, >> Ammar >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Bob Hinden [mailto:bob.hinden@gmail.com] >> Sent: Thursday, October 11, 2012 6:37 AM >> To: Ammar Salih >> Cc: Bob Hinden; ipv6@ietf.org >> Subject: Re: IPv6 modification suggestion >>=20 >> Ammar, >>=20 >> On Oct 10, 2012, at 7:52 AM, Ammar Salih wrote: >>=20 >>> Hello Dears, >>>=20 >>> I would like to suggest adding GPS coordinates to IPv6 header, as = you=20 >>> know >> the current way of determining the location of the IP address is=20 >> through the IP registration, which is not very accurate as it depends=20= >> on how the ISP registers it's IP subnets, which is normally done = based on > country/city. >>=20 >> I agree with you that IP addresses are not very reliable as a means = of=20 >> determining geographic location. That said, I don't think it is a=20 >> good idea to add GPS position to every IPv6 header. It would add a=20= >> lot of overhead, there are many privacy related issues (as others = have=20 >> pointed out), it doesn't need to be in every packet. An alternative=20= >> would be to create a application layer protocols that could request=20= >> and send GPS positions. That is a better way to to deal with the=20 >> privacy issues and the GPS position would only need to be sent when > desired or when requested. >>=20 >> The GEOPRIV working group is doing some work in this area. See: >>=20 >> http://datatracker.ietf.org/wg/geopriv/charter/ >>=20 >> Bob >>=20 >>=20 >>>=20 >>> Getting more accurate locations will enhance many services provided=20= >>> by the >> web, like targeted commercials (for example, I can get Ads regarding=20= >> restaurants available in my neighborhood instead of all restaurants = in=20 >> the city), another good example would be webpage's language, my=20 >> language will be detected more accurately based on my exact area=20 >> rather than my countery, as there are many countries with more than = one > popular language. >>>=20 >>> Maps, navigation, emergency calls and many other services will also=20= >>> get >> enhanced with accurate locations. >>>=20 >>> I hope you will find my suggestion beneficial, and looking forward = to >> hearing from you. >>>=20 >>>=20 >>> Best, >>>=20 >>> Ammar Salih | B.Sc.Eng, CCNA-S, CCVP, CCIE-V written Technical Lead = -=20 >>> Voice and Data Support Services >>>=20 >>> Mob: +964 (0) 770 533 0306 >>> Office: +964 (0) 53 511 2020 - Ext. 2221 >>> Email: ammar.salih@auis.edu.iq >>> The American University of Iraq - Sulaimani >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv >=20 From ammar.salih@auis.edu.iq Mon Oct 22 11:05:47 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFE421F892E for ; Mon, 22 Oct 2012 11:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAIM9qUVldTg for ; Mon, 22 Oct 2012 11:05:45 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with SMTP id 39E9F21F897A for ; Mon, 22 Oct 2012 11:05:44 -0700 (PDT) Received: from mail-ee0-f70.google.com ([74.125.83.70]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKUIWK+MPeDielcYOPG7xBQnN0TLIsxe2Z@postini.com; Mon, 22 Oct 2012 11:05:45 PDT Received: by mail-ee0-f70.google.com with SMTP id b57so2582911eek.1 for ; Mon, 22 Oct 2012 11:05:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=+3Hdl6q6IYSwovsXpmMlBLb3Fohxz3VNzT4RE401Gq4=; b=hD97UU8AqMvKNei1dcPmxW98Uc27QwhwAk3SPLsg/m0YLU1t9aw9ULb9HSqS88wJvs 1xw143tGJLUeix0WeIeT+wRp7wq+zFabEQnBb2aplzzwqdDUp/SG7juhVQsMzEvhgV1C YmIU6PlHNUIAEoZcioKiB9r2Z/8VtR5K06vUeNsd9EZakiLpIhO9e5buzDMFqMwZ/0i9 S9mWoBZNmoxOobMrT+LFUWjue6bc7Y4JCKmVERYUxHEE7CmdNcG/jo4jGSHLMlJ/uwsX ZF9eGhyMVJGjty6TqzBgHXxPhFjIJE1U7BOsrTMgIeEoaj5x5J+0oQc3s5L7VKe5N91g FMLg== Received: by 10.204.3.214 with SMTP id 22mr2912380bko.108.1350929143078; Mon, 22 Oct 2012 11:05:43 -0700 (PDT) Received: by 10.204.3.214 with SMTP id 22mr2912375bko.108.1350929142859; Mon, 22 Oct 2012 11:05:42 -0700 (PDT) Received: from AMMARSALIH ([95.159.75.98]) by mx.google.com with ESMTPS id v14sm4363535bkv.10.2012.10.22.11.05.38 (version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 11:05:41 -0700 (PDT) From: "Ammar Salih" To: "'Richard Barnes'" References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> <508060a0.42020e0a.3ead.ffff9089@mx.google.com> <6CBCC380-E419-443C-88B1-17C85105E648@bbn.com> <5084783a.a960b40a.0296.1ca1@mx.google.com> <78A28703-EFED-44B9-BC93-C0CF8729B1CB@bbn.com> In-Reply-To: <78A28703-EFED-44B9-BC93-C0CF8729B1CB@bbn.com> Date: Mon, 22 Oct 2012 21:05:32 +0300 Message-ID: <50858af5.0e0ccc0a.2abc.6ca3@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2wVtWLtTzi891OT5SOYKnv6s4CnQAIIt5A Content-Language: en-us X-Gm-Message-State: ALoCoQkY1FQAGtWca0STYC48jwONpGsK+IZKtsjgZIEE/EnBhHIN+Mq+EKd98nlcrSs0HLovQ6j5ifc11tsDNUPA7UTNAwZRoErCs0nO0BPYypUmBvDiTwkY6HqxvrwSiGjjns0q2zVpBMgsTPZW9SkkcdJftFlYcA== X-Mailman-Approved-At: Mon, 22 Oct 2012 11:24:37 -0700 Cc: geopriv@ietf.org Subject: Re: [Geopriv] IPv6 modification suggestion X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:05:47 -0000 Hello Richard, > For geolocation-based ACLs: you have the problem that if the geolocation is attached > by the endpoint, then it can't be trusted, since the endpoint would lie to get past > the ACL. If it's attached by a router, the ACL needs to have proof that the router > attached it (and not the endpoint), which means that you would need a signed > geolocation header. The routing community is already having enough trouble > implementing signatures on BGP messages [1]; a signature on every packet would > probably not be viable. It would make the router do about as much as a VPN > concentrator. You could have the router modify the location field anyways, just like L2/L3 QoS fields, if you don't trust the host, no need for encryption or security, plus ACL is not only for security, it could be used for routing, QoS ..etc, so the host will not always has the motivation to hack the location field. > For location-based routing protocols: Why would you want this? Geographical location > isn't actually that important a metric for routing; what you care about there is > *topological* location, how far I am away from you in terms of hops or latency. > People will go to great lengths to reduce topological distances (CDNs, cables under > the arctic). For shortest path maybe yes, metric is important, not for policy-based routing, for example if you would like to do location-based routing, like, routing traffic coming from France to google.fr or youtube traffic to France youtube cashing server, there could be so many other applications. > But prior proposals for geolocation-based routing in the IETF (going > back to 1996) have failed [2][3][4]. I didn't go through those documents, but from the titles I would assume that they failed because they wanted to replace IP address with GPS locations, or create GPS-based addressing scheme, ignoring the "mobility" factor which is a huge deal in this discussion. I am suggesting to keep the IP address and attach GPS dynamically. > What would be the use case for geography-based routing? Enforcement of local > policies? implementing regulations, for example, certain regions does not allow VoIP calls over GSM/GPRS network. ITEF IPv6 team suggested that it is better to configure the policy on the router, I suggested that using "Mobile BTS" for example makes static configuration a nightmare, and implementing location-based policy makes the configuration more dynamic and easier to implement. > Nonetheless, if you have written a paper or Internet-draft about your proposed > extension to IPv6, I would be glad to read it and provide comments. Unfortunately, I did not, it was like 10 - 15 emails with IPv6 team. Thanks, Ammar -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com] Sent: Monday, October 22, 2012 4:12 PM To: Ammar Salih Cc: geopriv@ietf.org Subject: Re: [Geopriv] IPv6 modification suggestion Hi Ammar, I think that if you think through your examples more carefully, you'll see that an IPv6 extension header for geolocation doesn't really solve the problem you want. For geolocation-based ACLs: you have the problem that if the geolocation is attached by the endpoint, then it can't be trusted, since the endpoint would lie to get past the ACL. If it's attached by a router, the ACL needs to have proof that the router attached it (and not the endpoint), which means that you would need a signed geolocation header. The routing community is already having enough trouble implementing signatures on BGP messages [1]; a signature on every packet would probably not be viable. It would make the router do about as much as a VPN concentrator. For location-based routing protocols: Why would you want this? Geographical location isn't actually that important a metric for routing; what you care about there is *topological* location, how far I am away from you in terms of hops or latency. People will go to great lengths to reduce topological distances (CDNs, cables under the arctic). But prior proposals for geolocation-based routing in the IETF (going back to 1996) have failed [2][3][4]. What would be the use case for geography-based routing? Enforcement of local policies? I am also not as optimistic as you are about GPS being everywhere. For example, GPS does a really poor job inside of buildings. That's why we invented GEOPRIV in the first place, to help out where GPS fails! Nonetheless, if you have written a paper or Internet-draft about your proposed extension to IPv6, I would be glad to read it and provide comments. Cheers, --Richard [1] [2] [3] [4] On Oct 21, 2012, at 6:33 PM, Ammar Salih wrote: > Hello Richard, > > My concern is that IETF is integrating location field in each > application separatly, like GEOPRV, SIP Geo header .. etc, plus > implementing application layer protocol is feasible in application > servers only, network devices won't have the cabability to understand > the feature. I've given few examples to IPv6 team regarding > geo-location involvement, one would be location-based ACL, another would be location-based routing protocol. > > I anticipate that one day, layer 3-7 location-based policies will be > integrated into one header, as GPS devices becoming smaller and > accurate cooedinates are higly required. > > Thanks, > Ammar > > > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Friday, October 19, 2012 3:46 PM > To: Ammar Salih > Cc: geopriv@ietf.org > Subject: Re: [Geopriv] IPv6 modification suggestion > > Hi Ammar, > > Thanks for your interesting use case. Adaptation of services based on > geolocation is something that GEOPRIV is intended to support. One > example you might consider is ECRIT [1]. In that system, the end > device or its proxy discovers how to direct an emergency call based on > the caller's geolocation. > > Is your concern really at layer 3, or is it specific to certain > application-layer protocols? For example, if you are primarily > concerned with HTTP / web filtering, it might be that what you really > want is an HTTP header for geolocation, similar to the SIP Geolocation > header [2]. There have been proposals for such an HTTP header before, > and there was not much interest. But if you think there would be > people interested in using this header, then it could be something that we could work on in GEOPRIV. > > Keep in mind that in order to make these things useful, though, the > end host has to actually populate the field. So you'll need to > convince either OS vendors (for an IPv6 header) or browser vendors > (HTTP header) that this is a good idea. > > Cheers, > --Richard > > > [1] > [2] > [3] > > > > On Oct 18, 2012, at 4:03 PM, Ammar Salih wrote: > >> Hello everyone, I had a brief look at GEOPRIV and I was very much >> impressed, There has been so much work done by this amazing group! >> >> At the same time, I would like to raise my concern regarding the http >> location request which will not be detected by layer-3 devices >> (Routers), I am anticipating that in the future, GPS capability will >> be added to the router itself (just like smart phones) and packet >> marking and classification based on geo-location will be required. >> >> QoS, firewall and routing based on geo-location will be highly >> demanded when mobile routers move from one geo-location to another >> which has different regulations/electronic laws. >> >> Here is an example, if your router is within city-X and this city has >> very good electronic and copyright laws, then users will have relaxed >> network security settings, but what if the very same router moved to >> city-Y which according to its law, certain websites should be blocked >> (like facebook in china for example) .. these rules based on >> geographic location won't be feasible unless the mobile router has a >> GPS and can read/write coordinates to layer-3 packets. >> >> Best, >> Ammar >> >> >> -----Original Message----- >> From: Ammar Salih [mailto:ammar.salih@auis.edu.iq] >> Sent: Thursday, October 11, 2012 11:41 AM >> To: 'Bob Hinden' >> Cc: 'ipv6@ietf.org' >> Subject: RE: IPv6 modification suggestion >> >> Hello Bob, >> >>> That said, I don't think it is a good idea to add GPS position to >>> every >> IPv6 header. It would add a lot of overhead. >> >> It does not have to be in every IPv6 header, only when there is >> location update, also it can be included in the first header (just >> like RTP and cRTP) >> >> >> >>> there are many privacy related issues (as others have pointed out). >> >> This can be set manually in case of any privacy concerns, just like >> other header's information like IP address. >> >> >> >>> An alternative would be to create a application layer protocols that >>> could >> request and send GPS positions. >> >> Sounds awesom, but in this case all webpages, phone applications, >> server side scripting languages ... etc have to be modified to >> support the new application protocol. Not mensioning that layer 3 >> devices (like routers) won't be able to support the feature, let's >> say in the feature you want to do dynamic routing based on geo location. >> >> >> In anycase, I still feel quite interested about the new layer 7 >> protocol, will try to go through the GEOPRIV documentation this >> weekend in order to get more details. >> >> Thank you for your kind response, >> Ammar >> >> >> >> -----Original Message----- >> From: Bob Hinden [mailto:bob.hinden@gmail.com] >> Sent: Thursday, October 11, 2012 6:37 AM >> To: Ammar Salih >> Cc: Bob Hinden; ipv6@ietf.org >> Subject: Re: IPv6 modification suggestion >> >> Ammar, >> >> On Oct 10, 2012, at 7:52 AM, Ammar Salih wrote: >> >>> Hello Dears, >>> >>> I would like to suggest adding GPS coordinates to IPv6 header, as >>> you know >> the current way of determining the location of the IP address is >> through the IP registration, which is not very accurate as it depends >> on how the ISP registers it's IP subnets, which is normally done >> based on > country/city. >> >> I agree with you that IP addresses are not very reliable as a means >> of determining geographic location. That said, I don't think it is a >> good idea to add GPS position to every IPv6 header. It would add a >> lot of overhead, there are many privacy related issues (as others >> have pointed out), it doesn't need to be in every packet. An >> alternative would be to create a application layer protocols that >> could request and send GPS positions. That is a better way to to >> deal with the privacy issues and the GPS position would only need to >> be sent when > desired or when requested. >> >> The GEOPRIV working group is doing some work in this area. See: >> >> http://datatracker.ietf.org/wg/geopriv/charter/ >> >> Bob >> >> >>> >>> Getting more accurate locations will enhance many services provided >>> by the >> web, like targeted commercials (for example, I can get Ads regarding >> restaurants available in my neighborhood instead of all restaurants >> in the city), another good example would be webpage's language, my >> language will be detected more accurately based on my exact area >> rather than my countery, as there are many countries with more than >> one > popular language. >>> >>> Maps, navigation, emergency calls and many other services will also >>> get >> enhanced with accurate locations. >>> >>> I hope you will find my suggestion beneficial, and looking forward >>> to >> hearing from you. >>> >>> >>> Best, >>> >>> Ammar Salih | B.Sc.Eng, CCNA-S, CCVP, CCIE-V written Technical Lead >>> - Voice and Data Support Services >>> >>> Mob: +964 (0) 770 533 0306 >>> Office: +964 (0) 53 511 2020 - Ext. 2221 >>> Email: ammar.salih@auis.edu.iq >>> The American University of Iraq - Sulaimani >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > From kjones@skyhookwireless.com Mon Oct 22 17:25:15 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DCE1F0C5C for ; Mon, 22 Oct 2012 17:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nst62ZGLAltJ for ; Mon, 22 Oct 2012 17:25:14 -0700 (PDT) Received: from server505.appriver.com (server505l.appriver.com [98.129.35.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42F8911E80A2 for ; Mon, 22 Oct 2012 17:25:13 -0700 (PDT) X-Note-AR-ScanTimeLocal: 10/22/2012 7:25:13 PM X-Policy: GLOBAL - skyhookwireless.com X-Primary: kjones@skyhookwireless.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @skyhookwireless.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: X-Note-Return-Path: kjones@skyhookwireless.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G329 G330 G331 G332 G336 G337 G348 G444 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 42689100 for geopriv@ietf.org; Mon, 22 Oct 2012 19:25:13 -0500 Received: from MBX02.exg5.exghost.com ([169.254.2.43]) by HT04.exg5.exghost.com ([98.129.23.33]) with mapi; Mon, 22 Oct 2012 19:25:12 -0500 From: Kipp Jones To: GEOPRIV WG Date: Mon, 22 Oct 2012 19:25:11 -0500 Thread-Topic: updated draft-jones-geopriv-sigpos-survey Thread-Index: Ac2wtN1Ha752zxDhQ+GAf1WFkR8Z+g== Message-ID: 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_E2388AC280F34878A1E1B48DA67FCD1Askyhookwirelesscom_" MIME-Version: 1.0 Subject: [Geopriv] updated draft-jones-geopriv-sigpos-survey X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 00:25:15 -0000 --_000_E2388AC280F34878A1E1B48DA67FCD1Askyhookwirelesscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Darg... Nits and more nits...missed the deadline today, but will submit when it reo= pens on Nov. 5th. The intended draft update: https://dl.dropbox.com/u/54276671/draft-jones-ge= opriv-sigpos-survey-01.txt In this draft, I've attempted to address all of the comments that were subm= itted, including: - specification of HTTPS for transport - inclusion of response object for handling success/errors to client - initial XML schema (beacon location profile) - more IANA specifications - clarification of licensor and licenses Sorry about missing the deadline... Kipp .............................................. Kipp Jones Chief Architect/Privacy Czar kjones@skyhookwireless.com m: 404.213.9293 | @skykipp --_000_E2388AC280F34878A1E1B48DA67FCD1Askyhookwirelesscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Darg...

Nits and more nits...missed the deadline today, but will submit when it r= eopens on Nov. 5th.


In this draft, I've attempted to= address all of the comments that were submitted, including:

=
- specification of HTTPS for transport
- inclusion of = response object for handling success/errors to client
- initial X= ML schema (beacon location profile)
- more IANA specifications
- clarification of licensor and licenses

S= orry about missing the deadline...

Kipp
=
<= div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-= break: after-white-space; ">
<= span class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: nor= mal; font-weight: normal; letter-spacing: normal; line-height: normal; orph= ans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows= : 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-bor= der-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webki= t-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">..................................= ............ 
Kip= p Jones
Chief Architect/Privacy Czar<= /b>
m: 404.213.9= 293 | @skykipp

= --_000_E2388AC280F34878A1E1B48DA67FCD1Askyhookwirelesscom_-- From wwwrun@rfc-editor.org Wed Oct 24 21:20:53 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D93F11E80EA; Wed, 24 Oct 2012 21:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.958 X-Spam-Level: X-Spam-Status: No, score=-101.958 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asNG8LWHHdqV; Wed, 24 Oct 2012 21:20:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BAE3411E80E9; Wed, 24 Oct 2012 21:20:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3D58D72E038; Wed, 24 Oct 2012 21:15:08 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121025041508.3D58D72E038@rfc-editor.org> Date: Wed, 24 Oct 2012 21:15:08 -0700 (PDT) Cc: geopriv@ietf.org, rfc-editor@rfc-editor.org Subject: [Geopriv] RFC 6753 on A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 04:20:53 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6753 Title: A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD) Author: J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. Thomson Status: Standards Track Stream: IETF Date: October 2012 Mailbox: james.winterbottom@commscope.com, Hannes.Tschofenig@gmx.net, hgs@cs.columbia.edu, martin.thomson@skype.net Pages: 25 Characters: 49866 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-geopriv-deref-protocol-07.txt URL: http://www.rfc-editor.org/rfc/rfc6753.txt This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereference protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). This document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-Enabled Location Delivery (HELD) protocol to request the location of the Target. [STANDARDS-TRACK] This document is a product of the Geographic Location/Privacy Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC