Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-arch-00.txt
"James M. Polk" <jmpolk@cisco.com> Thu, 16 July 2009 22:35 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 6D9783A6DED for <geopriv@core3.amsl.com>; Thu, 16 Jul 2009 15:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.363
X-Spam-Level:
X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 pLHjEDAQbRaw for <geopriv@core3.amsl.com>; Thu, 16 Jul 2009 15:35:52 -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 E98FE3A6961 for <geopriv@ietf.org>; Thu, 16 Jul 2009 15:35:51 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao0IAHVIX0qrR7O6/2dsb2JhbACIQ7A0iCOREgWEDQ
X-IronPort-AV: E=Sophos;i="4.42,413,1243814400"; d="scan'208";a="215200487"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 16 Jul 2009 22:36:25 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6GMaPtQ016223; Thu, 16 Jul 2009 15:36:25 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6GMaPaY000764; Thu, 16 Jul 2009 22:36:25 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); Thu, 16 Jul 2009 15:36:24 -0700
Received: from jmpolk-wxp01.cisco.com ([10.89.4.15]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 15:36:24 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 16 Jul 2009 17:36:22 -0500
To: Brian Rosen <br@brianrosen.net>, 'Alissa Cooper' <acooper@cdt.org>, Ray.Bellis@nominet.org.uk
From: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <022501ca062f$f31ca210$d955e630$@net>
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> <XFE-SJC-211e5HXC9xu00002cc5@xfe-sjc-211.amer.cisco.com> <7085685A-1A3B-4944-88AE-88612852E699@cdt.org> <022501ca062f$f31ca210$d955e630$@net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-ID: <XFE-SJC-212mwzZXWNV00008091@xfe-sjc-212.amer.cisco.com>
X-OriginalArrivalTime: 16 Jul 2009 22:36:24.0386 (UTC) FILETIME=[D97E0A20:01CA0665]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8448; t=1247783785; x=1248647785; c=relaxed/simple; s=sjdkim2002; 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=q2PBZSEsrou6Zg9tv8cInBjuMqWuABW4erskjphmoNw=; b=Y3ELYmpjcAiDRop4Sc4/673zo4moIeMTLcSxnJYo1v83o2IyejYbTK+DsS OOyEv56dXLf5J1Iim/6FtmA1VtQP382M2EdbOuSxvyZ/02ulKem3Lknb0XUf eQ9TyHugVa;
Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 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 22:35:53 -0000
At 11:10 AM 7/16/2009, Brian Rosen wrote: >Generally, we call things that deliver location values as well as URIs to be >LISses. I thought so too, until I was mercilessly corrected on the SIPCORE list by Martin -- to the point of him saying: "It's becoming more and more apparent that you (James) don't understand how location by reference is deployed. " Add this to Alissa's bullet about the changes to the draft-ietf-geopriv-arch-00 ID from the original loc-sec-05 stating the LIS was used to dereference a PIDF-LO, but only if it is the target that's doing the dereferencing. color me confused (still) James >Brian > > > -----Original Message----- > > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On > > Behalf Of Alissa Cooper > > Sent: Thursday, July 16, 2009 10:23 AM > > To: James M. Polk; Ray.Bellis@nominet.org.uk > > Cc: GEOPRIV > > Subject: Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-arch-00.txt > > > > I was asking about other docs because the conception of what a LIS is > > has to come from somewhere, and I wanted to know what comes to > > people's minds when they think of it. Deref was useful in that respect. > > > > On the LIS point, a simple way to solve this could be to define LIS as > > follows (unless there's another document out there that directly > > contradicts this definition), in 3.2.3 of geopriv-arch: > > > > "A LIS provides location URIs to LRs." > > > > And then the discussion of the LIS in 3.2.2 could be taken out. > > > > This doesn't address the issue of dereferencing, but does it get the > > job done on defining a LIS? > > > > Alissa > > > > On Jul 15, 2009, at 11:11 PM, James M. Polk wrote: > > > > > At 01:53 PM 7/14/2009, Alissa Cooper wrote: > > >> 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. > > > > > > I agree that a single entity can perform multiple roles - but that's > > > the opposite of what you're suggesting here; as you're changing the > > > same function and definition of the entity based on who's asking for > > > the same information -- which is what I object to. > > > > > >> 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_". > > > > > > again - that's the opposite of what's happening here. > > > > > > What you are saying is that a LIS is the dereference server and > > > destination of a location URI from the target *only*. > > > > > > If a 3rd party wants that same target's PIDF-LO using the _same_ > > > location URI it is no longer contacting the LIS, it is contacting a > > > Location Server. > > > > > > This is nuts. > > > > > > LISs should be used for 1 purpose, as should Location Servers. > > > > > > A LIS should be used to provide LI to a Target via an LCP. > > > > > > Location Servers are location inserters (i.e., the SIP UA or Proxy > > > that inserts location into the SIP request). > > > > > > We need to have another singular purpose term defined as the > > > destination of the location URI, call it a Dereference Server (DS) > > > which provides PIDF-LOs from Location Recipients that were given a > > > location URI from or of a target. > > > > > > This means everything is clearly singular in > > > > > > > > >> 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). > > > > > > "...the rest of our existing geopriv documents..." > > > > > > These are all HELD originated and HELD only documents. Surely > > > Geopriv has produced more documents that just about HELD, hasn't it? > > > > > > If so, then this quote isn't so accurate, is it? > > > > > > BTW - which of these documents define how HELD returns a PIDF-LO in > > > a response? > > > > > >> Can you provide references that instead point to LIS as a > > >> dereference server > > >> that responds to any LR's request? > > > > > > Can you? > > > > > > A LIS has always been our least defined entity. > > > > > > As suggested above, why get into a discussion about an acronym (LIS) > > > that does a function that accurately describes what we're talking > > > about just fine (i.e., Dereference Server (DS)). > > > > > > This would solve all our problems and minimize or eliminate > > > everyone's confusion. > > > > > >> Also, we will get authors/acknowledgements squared away in a > > >> subsequent draft. > > > > > > yeah -- and the 2 chairs are part of that author team... so who's > > > running this document (as a matter of process)? > > > > > >> 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 > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www.ietf.org/mailman/listinfo/geopriv
- [Geopriv] I-D Action:draft-ietf-geopriv-arch-00.t… Internet-Drafts
- [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-arch… Alissa Cooper
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… James M. Polk
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… Ray.Bellis
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… Ray.Bellis
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… Alissa Cooper
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… Winterbottom, James
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… James M. Polk
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… James M. Polk
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… Thomson, Martin
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… Alissa Cooper
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… Ray.Bellis
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… James M. Polk
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… Ray.Bellis
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… Brian Rosen
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… Dawson, Martin
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… James M. Polk
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… Thomson, Martin
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… James M. Polk
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… Thomson, Martin
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… James M. Polk
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… Alissa Cooper
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… Thomson, Martin
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… Thomson, Martin
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… James M. Polk
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… James M. Polk
- Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-… Thomson, Martin