>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 mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
