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

["James M. Polk" <[e-mail]>]

and here's the rub...

3 consecutive active WG participants give 3 different answers with 3 
consecutive messages to the Geopriv list 8 years after the WG was formed.

(sarcastically) that's brilliant!

Alissa says LISes give location URIs out.

Ray says LISes give LI out.

Brian says LISes give LOs and location URIs out.

these are THREE different behaviors folks.

LI has zero identity, therefore LISes cannot give out PIDF-LOs (so 
they are not dereference servers).

If LISes only gave out location URIs, then that makes a Proxy that 
inserts location a LIS, which I don't believe anyone agrees with (but 
I could be wrong, there might be one or two that believe this).

Brian says LISes give everything out, except LI (i.e., that has no 
identity associated).

We need a single entity defined and labelled that location URIs point 
to, that provides PIDF-LOs when a LR subscribes to it to get that 
PIDF-LO of a Target (and I don't care whether it's the target itself 
or a 3rd party that's subscribing - a dereference transaction is a 
dereference transaction).

This makes this a specific purpose entity within the Geopriv 
Architecture - and I believe it ought to be called what it does, a 
Dereference Server (DS).

James

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.
>
>Brian
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Alissa Cooper
> > Sent: Thursday, July 16, 2009 10:23 AM
> > To: James M. Polk; [e-mail]
> > 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, [e-mail] 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: [e-mail], t: [phone]
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> Geopriv mailing list
> > >>> [e-mail]
> > >>> https://www.ietf.org/mailman/listinfo/geopriv
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Geopriv mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/geopriv