Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-arch-00.txt

"James M. Polk" <jmpolk@cisco.com> Thu, 16 July 2009 04:28 UTC

Return-Path: <jmpolk@cisco.com>
X-Original-To: geopriv@core3.amsl.com
Delivered-To: geopriv@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD5C3A6A39 for <geopriv@core3.amsl.com>; Wed, 15 Jul 2009 21:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.358
X-Spam-Level:
X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT3WdhD4Q0S5 for <geopriv@core3.amsl.com>; Wed, 15 Jul 2009 21:28:00 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 342933A6906 for <geopriv@ietf.org>; Wed, 15 Jul 2009 21:27:55 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwFAPJIXkqrR7PE/2dsb2JhbACIQ69ZiCORCAWECw
X-IronPort-AV: E=Sophos;i="4.42,409,1243814400"; d="scan'208";a="214666153"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 16 Jul 2009 04:25:02 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6G4P2X5003509; Wed, 15 Jul 2009 21:25:02 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6G4P250029825; Thu, 16 Jul 2009 04:25:02 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 21:25:02 -0700
Received: from jmpolk-wxp01.cisco.com ([10.89.4.19]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 21:25:01 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 15 Jul 2009 23:24:57 -0500
To: "Winterbottom, James" <James.Winterbottom@andrew.com>, Alissa Cooper <acooper@cdt.org>, Ray.Bellis@nominet.org.uk
From: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <E51D5B15BFDEFD448F90BDD17D41CFF104A3441F@AHQEX1.andrew.com >
References: <20090713023001.765033A69A6@core3.amsl.com> <C6E87D0B-57D7-42B8-8A30-64E94757551C@cdt.org> <XFE-SJC-212win8ESig00007234@xfe-sjc-212.amer.cisco.com> <OF089E8BB2.29CD3C76-ON802575F3.002EFD37-802575F3.002F3AD4@nominet.org.uk> <120ECBB2-6BD5-4DA2-AFEC-8CD1D826D4FA@cdt.org> <E51D5B15BFDEFD448F90BDD17D41CFF104A3441F@AHQEX1.andrew.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-ID: <XFE-SJC-212kDDSLJ4x00007ddc@xfe-sjc-212.amer.cisco.com>
X-OriginalArrivalTime: 16 Jul 2009 04:25:01.0692 (UTC) FILETIME=[62C3E3C0:01CA05CD]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5086; t=1247718302; x=1248582302; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20<jmpolk@cisco.com> |Subject:=20RE=3A=20[Geopriv]=20Fwd=3A=20=20I-D=20Action=3A draft-ietf-geopriv-arch-00.txt |Sender:=20; bh=mCn45cQb1teKIS20oxXcK3xkvb5+rzvEHILTEuyt1MQ=; b=KbyinUjcAIOP6zVGZ7BdLW/qePraqnWPq1HqOY0PgVk2VZCOTDbfTiWsKS rXzj+P2JoqNQORz8jN81pMSSYursdDGtAn2uIyMwrVZ+VQU2A3KZblmoJQHr IdTAIhgXo8;
Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
Cc: GEOPRIV <geopriv@ietf.org>
Subject: Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-arch-00.txt
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/geopriv>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jul 2009 04:28:08 -0000

At 04:59 PM 7/14/2009, Winterbottom, James wrote:
>Hi Alissa,
>
>Please take a look at 
>http://tools.ietf.org/html/draft-winterbottom-geopriv-deref-protocol-03 
>that was accepted as a working group item in March of last year.

this is 16 months old and there isn't an updated version on the tools 
page for geopriv?

how are we wg members supposed to keep up with docs that are this old?


>This document is all about a LIS also providing a dereference 
>service for location URIs.

so a HELD doc (that's this old) defines how a general Geopriv entity 
is to be defined.

ummmm-k


>Cheers
>James
>
>
>-----Original Message-----
>From: geopriv-bounces@ietf.org on behalf of Alissa Cooper
>Sent: Tue 7/14/2009 1:53 PM
>To: Ray.Bellis@nominet.org.uk; James M. Polk
>Cc: GEOPRIV
>Subject: Re: [Geopriv] Fwd:  I-D Action:draft-ietf-geopriv-arch-00.txt
>
>James, Ray,
>
>The last time we were discussing lo-sec, it was obvious that some
>clarity was needed about a single entity performing multiple Geopriv
>roles. Throughout the new version of the document, we've tried to make
>that clear, both by stating it explicitly ("It is not uncommon for the
>same entity to perform both the LG and LS roles, or both the LR and LS
>roles." in section 2), and by consistently referring to "the entity
>acting as L_" or the "the entity performing the role of L_".
>
>This holds true for LIS as much as any other Geopriv role. Nothing
>prevents an entity acting as a LIS from also acting as an LS. Perhaps
>my one-sentence description was more confusing/objectionable than the
>text itself. From section 3.2.2:
>
> > Some performing the Location Generator role are designed only to
> > provide Targets with their own locations (as opposed to distributing
> > a Target's location to others). The process of providing a Target
> > with its own location is known within Geopriv as Location
> > Configuration, and the LG that provides such location is often
> > described as a Location Information Server (LIS). Protocols used
> > exclusively to communicate location from a LIS to a Target are known
> > as Location Configuration Protocols [8]. Several such protocols have
> > been developed within Geopriv [9][10][11][12].
> >  By definition, a LIS needs only to follow a simple privacy-
> > preserving policy: transmit a Target's location only to the Target
> > itself. This is known as the "LCP policy."
> > Importantly, if an LS is also serving in the role of LG and it has
> > not been provisioned with Privacy Rules for a particular Target, it
> > MUST follow the LCP policy, whether it is a LIS or not. In the
> > positioning phase, an entity serving the roles of both LG and LS
> > that has not received Privacy Rules must follow this policy. The
> > same is true for any LS in the distribution phase.
>The notion of a LIS in the role that provides a Target with its own
>location seems to be supported in the rest of our existing geopriv
>documents (lis-discovery, lbyr-requirements, held, l7-lcp-ps). Can you
>provide references that instead point to LIS as a dereference server
>that responds to any LR's request?
>Also, we will get authors/acknowledgements squared away in a
>subsequent draft.
>Alissa
>On Jul 14, 2009, at 4:35 AM, Ray.Bellis@nominet.org.uk wrote:
>
> >
> > > >* Location configuration is called out explicitly. LIS is defined
> > as a
> > > >special case of LG that only provides a Target with its own
> > location.
> > >
> > > err, this is yet another definition change in the grand scheme of
> > Geopriv...
> > >
> > > so, a LIS is an LCP server, and what is the destination of
> > > subscriptions for dereferences - but only by the target itself, not
> > > dereferences by other entities?
> >
> > I'm not happy with this either.
> >
> > What are the motives for this change?  It seems to me that
> > generically a "LIS" is widely taken to mean anything that implements
> > HELD (or similar?) regardless of who is requesting the location and
> > to restrict the terminology now seems rather odd.
> >
> > Ray
> >
> > --
> > Ray Bellis, MA(Oxon) MIET
> > Senior Researcher in Advanced Projects, Nominet
> > e: ray@nominet.org.uk, t: +44 1865 332211
> >
> >
> > _______________________________________________
> > 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
>
>
>------------------------------------------------------------------------------------------------
>This message is for the designated recipient only and may
>contain privileged, proprietary, or otherwise private information.
>If you have received it in error, please notify the sender
>immediately and delete the original.  Any unauthorized use of
>this email is prohibited.
>------------------------------------------------------------------------------------------------
>[mf2]