Subject: [Geopriv] lo-sec way forward

From: Alissa Cooper <[email-masked]>
Date: Fri, 20 Mar 2009 06:59:26 -0700

Based on the list discussions about lo-sec over the past week or two,  
it seems as though there is a set of potentially uncontroversial  
changes that could be made to the draft, and a smaller but more  
challenging set of outstanding issues to be resolved. A summary of  
both sets is below. What is missing or off-base?

Proposed further changes that are hopefully uncontroversial:

Better integrate security considerations from lo-sec-04

Discuss the role of identity/pseudonyms throughout -- we had avoided  
this for brevity, but that decision is causing confusion given how  
integral identity is to privacy

Clarify who has location at the end of the positioning process (LG vs.  
Target)

Call out the special case of LCPs in their own section and confine the  
discussion of LCPs to that section to the greatest extent possible

Limit example rules to things that are expressible by Common Policy  
and Geopriv Policy

Add a quick intro to privacy rules in section 1

Attempt to shorten the document

Incorporate the other small changes suggested on the mailing list (by  
Martin and Hannes in particular) that are not relevant to the  
outstanding issues below or referenced above

Outstanding issues:

Can an LG also be an LS?
i.	Should we invoke the term LIS to describe an entity that is both an  
LG and an LS?
ii.	No matter what the answer is, we need to clarify our usage of LG,  
LS-init, "first LS," and LS.

Is what LGs transmit to LSes better characterized as LI, or as "LOs  
without Rules?" Put differently, do LOs exist as part of Positioning  
or not?

Can an LR also be an LS? Put differently, is the idea of an LR as an  
"ultimate" endpoint impractical?

Is there utility in classifying protocols and giving them labels, or  
does it just muddy the waters further at this point in the Geopriv  
WG's history? Do labels provide meaningful descriptions or distinctions?
i.	If there is utility, what should the labels be? Which labels apply  
to which existing protocols?
ii.	In addition to protocol labels, should we consider whether the  
life-cycle labels are right? Is "Use" better than "Receipt?" Is  
"Acquisition" better than "Positioning?"

Is there utility in the distinction between Local Rules and Forwarded  
Rules?
i.	If there is utility, are Forwarded Rules better named "Sticky Rules?"

Should we be using 2119 language? If so, do we need to do so more  
consistently?

Alissa

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 20 Mar 2009 14:02:32 -0500

>Clarify who has location at the end of the positioning process (LG vs.

this bullet is confusing. The LG is the generator of the first 
PIDF-LO. How can it "have location at the end of any transaction". 
Further, the Target is whose is described in that PIDF-LO, so it 
shouldn't have location at the end of any transaction. An LR is who 
has the location at the end of a transaction.

If it is the case in which you are talking about the Target 
requesting its own location, then the target being the Target is 
separable from the target being the LR.

In either case above, the LR is who receives location.

>outstanding issues below or referenced above

the answer is "of course".

If the LS is the entity that is asked for the location of a target it 
knows about, and generates the first PIDF-LO for that target, the 
this LS is also the LG for that target.

This is basic, and covered in RFC 3693. I hope we are not trying to 
change that.

>i.      Should we invoke the term LIS to describe an entity that is both an

for a particular target, I think this is appropriate, so long as 
there can be more than one LIS in a network or domain (because any 
LIS may not have knowledge about all targets within that network or domain)

>LS-init, "first LS," and LS.

see above (for my view to help clarify this text)

>without Rules?"

an LG is by definition the initial creator of a PIDF-LO

LI is carried by LCPs into LGs to turn that information into a PIDF-LO

>Put differently, do LOs exist as part of Positioning or not?

Positioning is location determination, which is a Sighter function.

>Can an LR also be an LS?

sure, but those are completely separate - and logical - functions.

Similar to a SIP server. Can a SIP server be an endpoint. Answer: yes.

>Put differently, is the idea of an LR as an "ultimate" endpoint impractical?

An LR is an entity that understands a PIDF-LO, and receives a PIDF-LO 
that it understands. This is not necessarily the "ultimate" endpoint. 
An ESRP (Emergency Services Routing Proxy) is an excellent example of 
a intermediate entity that receives and understands any PIDF-LO, then 
forwards that PIDF-LO towards the PSAP call-taker as the ultimate 
destination - in which the PIDF-LO is included in the message (for 
dispatching emergency responders)

>WG's history?

I think if we talk in general terms, it is ok.  If we are rigid about 
forcing every classified protocol to adhere to every requirement to 
that classification - IMO - we're way past the point of usefulness, 
given the history of this WG.

>Do labels provide meaningful descriptions or distinctions?

in general terms, I think so

>i.      If there is utility, what should the labels be?

configuration
conveyance
retrieval (which covers at least 2 subcategories)
         - dereference
         - solicited request

one KEY to this is that any protocol can be in more than one 
category, though some cannot.

>Which labels apply to which existing protocols?

configuration
         - DHCP
         - HELD
         - LLDP-MED

conveyance
         - SIP
         - ?

retrieval
         - SIP
         - ? (but I believe HELD is here too, right?)

>life-cycle labels are right? Is "Use" better than "Receipt?"

not sure yet on this one

>Is

as a protocol label, "positioning" is a location determining 
function, in which any entity requires additional information from 
another entity to determine the location of a particular target. A 
"positioning" protocol is used to transport that information.

LCPs are NOT positioning protocols, because they transport LI in 
whole to an LG.

>Should we be using 2119 language?

if this is purely information, and not a requirements document, 2119 
doesn't apply IMO.

I think, as this point, it's hard to argue this is anything other 
than informational in nature.

James

>If so, do we need to do so more
>consistently?
>
>
>Alissa
>
>
>
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 21 Mar 2009 19:56:03 +0200

>Further, the Target is whose is described in that PIDF-LO, so 
>it shouldn't have location at the end of any transaction. An 
>LR is who has the location at the end of a transaction.

The LG shouldn't be the entity that creates the first LO since LO, per
definition, is location information + policies. The LG cannot have policies
in the style of PIDF-LO sticky policies since where should they come from
given that the Rule Maker has no protocol to send those to the LG (unless
you call the LG also a LS/LIS). 

I suggest to treat the LG as an entity that provides location measurements.

---

From: John Morris <[email-masked]>
Date: Sat, 21 Mar 2009 23:49:13 -0400

+1

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 22 Mar 2009 00:03:07 -0500

At 12:56 PM 3/21/2009, Hannes Tschofenig wrote:
>definition, is location information + policies.

The PIDF-LO is the XML geopriv schema defined in RFC 4119, and it is 
indeed what the LG creates the first instance of, per RFC 3693, and 
transmits said object in a "Using Protocol" (again, per RFC 3693) 
however that protocol transmits location.

>The LG cannot have policies
>given that the Rule Maker

the "rule maker" _can_ be the Target, and that Target _can_ send - or 
respond to another entity's request for - its location.

BTW - which RFC defines "sticky policies"?

>  has no protocol to send those to the LG (unless you call the LG 
> also a LS/LIS).

"a" protocol for this policy exchange is not necessary, and a LIS is 
an LG if it is acting on behalf of the Target wrt location queries.

>I suggest to treat the LG as an entity that provides location measurements.

that's a location determiner, which is the same as a Location 
Sighter, which is a different beast, altogether.