Re: [Geopriv] draft-ietf-geopriv-policy-uri-00 WGLC

On 4/29/11 00:07, Apr 29, Thomson, Martin wrote:
> On 2011-04-29 at 14:56:11, Adam Roach wrote:
>>
>> After thinking about this a bit, there is a possibility that the
>> server is having to allocate specific resources on a per-protocol
>> basis, in which case you'd want the ability for the client to hint at
>> a preferred protocol (so as to avoid unnecessary allocation of
>> resources for unwanted protocols).
> I'm inclined to classify this as an optimization. So three reasons not to add the parameter:
> 1. laziness
> 2. it's probably not too much extra load to create a resource for most types of resources, especially if you optimize for the case where the resource isn't accessed
> 3. DHCP won't have any hinting

Fair enough.

/a
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] FW: TAC and E-CID (draft-ietf-geopriv-held-measurements)

Hi all,

Keith asked a question about the tracking area code (TAC) in LTE cellular measurements at the last meeting. I did some reading on the subject, but the email exchange that I've included below was far more helpful.

As I understand it, each LTE cell is assigned to a tracking area, identified by a TAC. This code is known to devices and it could be used as a coarse substitute for the cell identifier. Other than that, it's not particularly relevant as a measurement parameter, other than as a potential shortcut for identifying a serving MME (if that is at all interesting to you). If you know about the cell id, then it's usually fairly trivial to find the TAC.

There's little harm in adding TAC to the measurement set, but equally marginal gain. I'm inclined to omit it at this stage, though I could easily be convinced to change my mind. Note that this is a different conclusion than was reached for 3GPP 24.229 or SUPL 2.0.

What occupied the rest of the discussion was the physical cell identifier (PCI), an identifier that is used to identify cells locally. Unless a device is actively interacting with a cell, it likely only sees this 9 bit code. In all likelihood, a device is only going to be able to provide a cell id for its serving cell and a PCI for a handful of neighbours. Thus, including PCI in measurements (and other such "colour codes" like PSC for UTRAN or ARFCN/BSIC for GERAN) allows the possessor of a cell database the ability to identify neighbouring cells.

The original intent of the cellular measurement section was to provide the absolute minimum measurement capability for cellular networks. The range of options available for cellular positioning are pretty crazy and starting down that slippery slope didn't sound like a good idea. For instance, adding ARFCN/BSIC means that it's logical to add the rest of a network measurement report, which includes signal strengths.

As above, I'm inclined to add nothing, but would be interested to hear dissenting opinions. It's not so hard to change either way.

--Martin

The below is forwarded with permission.
_____________________________________________
From: Pawson, Darren
Sent: Thursday, 14 April 2011 1:37 PM
To: Thomson, Martin; Tran, Khiem
Subject: RE: TAC and E-CID

Inline...

-----Original Message-----
From: Thomson, Martin
Sent: Thursday, 14 April 2011 12:17 PM
To: Pawson, Darren; Tran, Khiem
Subject: RE: TAC and E-CID

So let me get this straight:

MCC + MNC + EUCID is sufficient to identify an eNodeB.
[DP] Correct

MCC + MNC + EUCID + PCI is needed to identify the physical transmitter.
[DP] Not really, since MCC + MNC + EUCID should basically identify the transmitter. The main point is that for neighbour measurements, we may only get PCI for a neighbour cell, and not the MCC/MNC/EUCID. The PCI will be unique among cells within a given hearability area, but given there are only 512 values obviously they are re-used frequently in other areas of the network.
So, think of it more like the ARFCN/BSIC combo for GSM neighbour reporting. Getting just a PCI, in conjunction with knowing the MCC/MNC/EUID of the serving cell, needs to be enough to get us to the MCC/MNC/EUID in our DB of that particular neighbour cell (whether it be via a provisioned neighbour list on the serving cell or a nice spatial query to look for the PCIs of the cells near the serving cell 8-).

And each MCC + MNC + EUCID is allocated to an MCC + MNC + TAC. MCC + MNC + TAC represents a group of cells, so you can use it for location, but it's not hugely important (other than perhaps helping us identify the MME if we needed to talk to the eNodeB for some reason).
[DP] Correct

If I keyed cells on MCC + MNC + EUCID [ + PCI ], where PCI is optional, would that work? SUPL makes PCI mandatory.
[DP] As discussed above, I don't think you need the PCI within the key.
Just make sure you have a way to get to the MCC + MNC + EUID given only a PCI and the MCC + MNC + EUID of another nearby cell.

For CID measurements, adding an optional additional TAC parameter might be helpful, but it doesn't sound critical. SUPL has it as mandatory though - I suppose that a SET will always be able to measure it, so there's no harm in making it mandatory for measurements.

--Martin

-----Original Message-----
From: Pawson, Darren
Sent: Wednesday, 13 April 2011 2:17 PM
To: Thomson, Martin; Tran, Khiem
Subject: RE: TAC and E-CID

By the way, have you got the PhysicalCellId (PCI) in your cell database? This is the equivalent of the PrimaryScramblingCode (PSC) in UTRAN and is essentially the local colour code of the cell. We'll probably need this for E-CID to identify the reported neighbour cells.

DArren

-----Original Message-----
From: Pawson, Darren
Sent: Wednesday, 13 April 2011 2:14 PM
To: Thomson, Martin; Tran, Khiem
Subject: RE: TAC and E-CID

A TA (Tracking Area) basically serves the same purpose as a Routing Area and Location Area in UMTS/GSM.

That is, it identifies a group of cells to the core network within which the UE is known to be located. There are the usual opposing forces at play of minimising the tracking area so that you don't have to page too many cells for mobile terminated operations, as well as maximising the tracking area so the UE doesn't need to send too many Tracking Area Update messages as it moves around.

Each cell will have a tracking area code, but I guess the question you are asking is do we really need it for any purpose in positioning?
We shouldn't need it for any CellID, E-CID or A-GPS operations (or any other method that utilises connection-oriented messaging on SLs). The only thing I can think of why we may potentially need it is for OTDOA (or any other connectionless messaging to an eNB). In order to communicate using LPPa to an eNB outside of an active location session, we need to identify which MME to send the LCS-AP message to. We can basically use any MME that has a signalling relationship to the eNB. Knowing the TAC of the eNB we want to talk to may allow us to choose the MME.

Darren

-----Original Message-----
From: Thomson, Martin
Sent: Wednesday, 13 April 2011 12:08 PM
To: Pawson, Darren; Tran, Khiem
Subject: TAC and E-CID

Can either of you explain the role of the TAC in identifying a cell in the E-UTRAN? Someone pointed out that we'd omitted this in our cell identifiers. Is it useful/necessary?
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Review of draft-ietf-geopriv-held-measurements-03

Hi Geoff,

Responses inline.

On 2011-04-25 at 16:23:24, Geoff Thompson wrote:
> I was asked in Prague to review
> [draft-ietf-geopriv-held-measurements-03] for the IEEE 802
> considerations.

Thanks very much for the review.

> My comments follow:
>
> In section 5.1 LLDP Measurements regarding the note:
> I believe that technical capability originally specified in LLDP-MED
> is now included in the 2009 revision of 802.1AB (IEEE Std 802.1AB - 2009).
> Further, the 802.3 specific TLVs specified in 802.1AB clause 6.3 have
> been superceded by IEEE Std 802.3bc - 2009 (as anticipated in Note 2
> of that sub-clause). Thus I suspect that the reference to LLDP - MED
> and
> ANSI-TIA-1057 should be removed.

Thanks for the update. This draft actually predates all of that work, so I've obviously got to play a bit more catchup.

Looking at 802.1AB-2009 and 802.3BC, it doesn't look like the location TLVs are present. Since those TLVs are of the most interest, I've retained the ANSI reference until I find the right reference.

> In the text below Figure 6, the measurement set seems to assume that
> both the wifi end station and the access point are stationary. I'm not
> clear whether we are attempting fully cope with the "in motion" case.

Detecting the location of a mobile device is considerably more difficult, but still possible with the measurements provided. Since each measurement is timestamped, multiple measurements might be used to reveal motion.

I anticipate that to do moving devices justice, there are probably more parameters required than what are described. Though what is included is what I understand to be the "state of the art". This is universally true - the GPS parameters could also be used to determine velocity, but they probably aren't especially good at it.

> We
> can (at least) detect it and put in an indicator (e.g. some sort of
> flag, etc. for whether location is changing within some time/distance
> parameters).

The best way to indicate that parameters are changing is to include multiple values at different times.

As I understand it, implementations tend to make some assumptions about devices, including the (inadvisable) assumption that a device is stationary. I tend to think that a flag sends the wrong message - the default assumption should be that the target is moving, in the absence of strong evidence to the contrary. :)

> Re: Page 19, flightTime: I don't believe that the statement
> "Measurement of this value requires that stations synchronize their
> clocks" is correct, at least for the nominally static case. It would
> be true if the result were based on a 1 way measurement. However, if
> it is the average of a 2 way measurement then any difference in local
> time-of-day would be cancelled out (assuming matching clock rates). It
> would seem more useful to allow the lesser constrained case.

I'm not the expert in this, but I'm assured by those who are (I've spoken to both Gabor Bajko and internal experts on this) that this is the current direction. This is consistent with my reading of Annex of V of the 802.11v specifications.

The draft originally used a round trip time measurement, but the problem with using round trip timing is that scheduling delays add a random offset to the response. It turns out that it's easier to use flight time for WiFi. There are still challenges in measuring flight time and acquiring good synchronization, but I'm told that there are various solutions that reduce the errors to the point that the resulting range measurement is accurate enough to use (i.e., sub-metre).

> In section 5.6, DSL Measurements {Full 2 paragraphs of text is
> reproduced, my comments are in curly brackets}:

Thanks.

> RE: 5.6.3. Ethernet VLAN Tag Measurements There are several types of
> Ethernet VLANs in the world. This information seems to be specific to
> a particular VLAN specification that does not seem to be referenced.

You can find these labels defined in DSL Forum TR-101. They aren't labels that would be known to someone with IEEE background. The Ethernet deployments for DSL use multiple layers of VLAN for various reasons beyond my ken, but here's what TR-101 defines these as:

C-Tag The innermost VLAN tag as defined in IEEE 802.1ad and having an EtherType value of 0x8100
S-Tag The outermost or single VLAN tag as defined in IEEE 802.1ad.

> RE: 11.2. Informative References
> [ANSI-TIA-1057] I think this can be deleted now that the capability is
> included in 802.1AB

See above.

> [IEEE.8021AB] To both update the citation and correct its form, it
> should be:
> "IEEE Standard for Local and metropolitan area networks- Station and
> Media Access Control Connectivity Discovery" IEEE Std 802.1AB(tm)-2009

The (tm) is a bit of a challenge, but I got the rest. I'll let the lawyers sort out the trademarks.

> Since the specifications for the 802.3 TLVs in 802.1AB-2009 have been
> superceded by IEEE Std 802.3bc - 2009 a citation should be added for
> it.

I don't think that a specific 802.3bc reference is necessary, given the nature of the parameters defined therein.

Cheers,
Martin

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] draft-ietf-geopriv-policy-uri-00 WGLC

On 2011-04-29 at 14:56:11, Adam Roach wrote:
> On 4/28/11 8:11 PM, Thomson, Martin wrote:
> > This is the right idea, but I don't think that a request parameter
> > is
> going to help. It would be unlikely that a server is able to support
> a new policy URI scheme because a client asks for that scheme.
> Instead, we can simply suggest that the server provide a policy URI
> for every scheme that it supports. The client can then pick the one
> that suits it best.
>
> After thinking about this a bit, there is a possibility that the
> server is having to allocate specific resources on a per-protocol
> basis, in which case you'd want the ability for the client to hint at
> a preferred protocol (so as to avoid unnecessary allocation of
> resources for unwanted protocols).

I'm inclined to classify this as an optimization. So three reasons not to add the parameter:
1. laziness
2. it's probably not too much extra load to create a resource for most types of resources, especially if you optimize for the case where the resource isn't accessed
3. DHCP won't have any hinting

If another editor manages to overcome #1, then I'm OK with having the hint.

--Martin

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] draft-ietf-geopriv-policy-uri-00 WGLC

On 4/28/11 8:11 PM, Thomson, Martin wrote:
> This is the right idea, but I don't think that a request parameter is going to help. It would be unlikely that a server is able to support a new policy URI scheme because a client asks for that scheme. Instead, we can simply suggest that the server provide a policy URI for every scheme that it supports. The client can then pick the one that suits it best.

After thinking about this a bit, there is a possibility that the server
is having to allocate specific resources on a per-protocol basis, in
which case you'd want the ability for the client to hint at a preferred
protocol (so as to avoid unnecessary allocation of resources for
unwanted protocols).

But I don't really have a strong opinion on the issue -- it's just
another point worth considering.

/a
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] draft-ietf-geopriv-policy-uri-00 WGLC

On 4/28/11 8:11 PM, Thomson, Martin wrote:
>
>> What would be really nice would be adding an
>> attribute to the "requestPolicyUri"
>> element that indicated the preferred URI scheme. For example:
>>
>> <requestPolicyUri scheme="https"/>
> This is the right idea, but I don't think that a request parameter is going to help. It would be unlikely that a server is able to support a new policy URI scheme because a client asks for that scheme. Instead, we can simply suggest that the server provide a policy URI for every scheme that it supports. The client can then pick the one that suits it best.

Yep, that works too.

/a
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] DHCP lbyr extensibility additions

draft-ietf-geopriv-dhcp-lbyr-uri-option claims that it is "highly extensible". In order to make that claim more plausible, I think that two things need to be done.

1. The sub-option length could use a fixed unit.

The current definition is:

LuriLength: The length of the LuriValue, not including the
LuriLength field itself, up to a maximum of 255
units. The unit of measurement is defined by the
LuriType field definition. The LuriLength itself is
always a one-byte unsigned integer.

Defining length as being dependent on extension type makes this a lot less extensible. Any LuriType that follows an unsupported LuriType cannot be interpreted because the length of the unsupported LuriType is unknown.

I suggest changing this to use bytes:

LuriLength: LuriLength is a one-byte unsigned integer
containing the length of the LuriValue in bytes,
up to a maximum of 255 bytes.

2. The rules for handling multiple sub-options with the same LuriType need to be defined.

This is less important, because extensions can make their own rules about how multiple sub-options with the same LuriType, but the rules need to be defined for LuriType=1 at least.

I suggest something like:

Unless specified in the definition of a LuriType, multiple
values for the same LuriType are invalid. Multiple values for
an unknown or unsupported LuriType MUST be ignored.

Followed by either:

Multiple values for a LuriType of 1 (location URI) are allowed.
Each LuriValue for LuriType=1 represents a different location URI.

Or:

Multiple values for a LuriType of 1 (location URI) are concatenated.

I prefer the former, but understand that restricting URI length to 255 bytes is potentially troublesome.

On a related point, the following text is inaccurate and should be removed:

Per [RFC2131], subsequent LocationURI Options, which are
non-concatenated, overwrite the previous value.

RFC 3396 is pretty clear on this point:

[...] RFC 2131 [3] specifies that when more than
one option with a given type code appears in the DHCP packet, all
such options should be concatenated together.

--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #49: Review of Deref Protocol document

On 2011-04-29 at 11:31:27, Bernard Aboba wrote:
> > A Location Recipient MAY infer from a response containing the HELD
> content type, "application/held+xml", that a URI references a resource
> that supports HELD.
>
>
> [BA] Thanks.
>
> Some questions:
>
> a. In the above are you referring to the response in the original HELD
> exchange, or to a response to a dereference request (e.g. a GET or
> POST)?

I'm adding this to the discussion on GET, so that would be the implication. I suppose that if you get a HELD response to a HELD request, then you are pretty safe in assuming that the resource supports HELD.

> b. If this would apply to a dereference using a GET, is the
> implication that a HELD-capable client might subsequently choose to
> upgrade its requests to HELD (for error resilience or other reasons?)

Right. Say you dereference using GET and get a geodetic location. You could then upgrade and send a HELD request to get a civic address.

> c.. Should a de-reference request using GET specify the content types
> it prefers/is prepared to handle in the GET via an Accept: header?

Accept is always optional. In the absence of Accept:, the server gets to choose content type. A HELD server should always support application/held+xml, though they might also support application/pidf+xml as noted in S4.2.

> d. If so, are there content types that could be provided in the de-
> reference request other than "application/held+xml"? (e.g. to indicate
> whether the de-reference requester does/doesn't support HELD).

If Accept didn't include */* or application/* or application/held+xml, then the server would have to infer that they didn't support HELD and should send a 406 (Not Acceptable) response.

> e. Should a LIS be prepared to support content types other than
> "application/held+xml" in a request Accept: header?

A compliant HTTP server should act as above. I can see this not happening for various reasons (lazy implementation primarily). Most HTTP clients either send */* or omit Accept entirely so I can see a LIS implementation just ignoring Accept. RFC 2616 uses SHOULD for the 406 response, so that's arguably permissible behaviour.

--Martin

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #49: Review of Deref Protocol document

> A location URI can be acquired using a location configuration protocol, such as HTTP-Enabled Location Delivery (HELD) [RFC5985] or the Dynamic Host Configuration Protocol (DHCP) location URI option [I-D.ietf-geopriv-dhcp-lbyr-uri-option]. 
>
> > [BA] So how does the dereferencer know that HELD is to be used to
> > dereference rather than generic HTTP??
>
> They might use the content type of the response entity. The draft now makes this observation in S4.2, along with the other GET semantics.
>
> A Location Recipient MAY infer from a response containing the HELD content type, "application/held+xml", that a URI references a resource that supports HELD.

[BA] Thanks.  

Some questions:

a. In the above are you referring to the response in the original HELD exchange, or to a response to a dereference request (e.g. a GET or POST)?  

b. If this would apply to a dereference using a GET, is the implication that a HELD-capable client might subsequently choose to upgrade its requests to HELD (for error resilience or other reasons?)

c.. Should a de-reference request using GET specify the content types it prefers/is prepared to handle in the GET via an Accept: header?  

d. If so, are there content types that could be provided in the de-reference request other than "application/held+xml"? (e.g. to indicate whether the de-reference requester does/doesn't support HELD).    

e. Should a LIS be prepared to support content types other than "application/held+xml" in a request Accept: header?  

Re: [Geopriv] draft-ietf-geopriv-policy-uri-00 WGLC

Thanks for the input Adam,

I agree on the generalization.

On 2011-04-29 at 07:58:31, Adam Roach wrote:
> On a separate topic, I note that the document implies that multiple
> clients are capable of updating the document via PUT and DELETE
> operations, but without mentioning the use of etags.

Updating the examples is good, maybe even pointing out that conditional requests are the safest way to update resources. In practice there is probably only one client updating the resource, so I expect that anything more than this would be overkill.

> Section 4.1 claims 'A policy URI MUST use the "http:" or "http:"
> scheme...' I suspect that one of those should be "https," but the
> more relevant comment here is that this seems an unnecessary
> restriction. As I mentioned above, I think it would be short-sighted
> to close the door to using other protocols in the future. I suggest
> that we instead define clear behavior if the client does not
> understand the URI scheme (e.g., it is treated the same as if there
> were no URI present). What would be really nice would be adding an
> attribute to the "requestPolicyUri"
> element that indicated the preferred URI scheme. For example:
>
> <requestPolicyUri scheme="https"/>

This is the right idea, but I don't think that a request parameter is going to help. It would be unlikely that a server is able to support a new policy URI scheme because a client asks for that scheme. Instead, we can simply suggest that the server provide a policy URI for every scheme that it supports. The client can then pick the one that suits it best.

Note that for DHCP, this implies the need for some changes to draft-ietf-geopriv-lbyr-uri-option. I'll have to follow up on that separately.

--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #49: Review of Deref Protocol document

Good feedback, thanks for the review Bernard.

On 2011-04-22 at 09:35:12, geopriv issue tracker wrote:
> #49: Review of Deref Protocol document
>
> Overall, I think that this document could be clearer that the deref
> protocol defined can be used with any LCP, and that support for
> generic deref via GET is supported (e.g. I'd make that a mandatory to
> implement).

That can be (and has been) done. The first as part of addressing the next comment, the latter as a new introduction paragraph.

> [...] A location URI might
> identify
> a temporary resource, created in response to a HTTP-Enabled
> Location
> Delivery (HELD) [RFC5985] request.
>
> [BA] might? This left me wondering what else it might be used for.
> For example, could it represent a temporary resource created in
> response to another protocol request (e.g. DHCP), or maybe a non-
> temporary resource?

There's certainly nothing preventing the resource from being non-temporary, but that's a tricky arrangement to get right without some special access controls. In either case, I've removed the offending clause and replaced it with:

A location URI can be acquired using a location configuration protocol, such as HTTP-Enabled Location Delivery (HELD) [RFC5985] or the Dynamic Host Configuration Protocol (DHCP) location URI option [I-D.ietf-geopriv-dhcp-lbyr-uri-option].

> A location URI does not
> intrinsically include location information, instead the URI is
> "dereferenced" by a Location Recipient to acquire location
> information. This document specifies how a holder of a location
> URI
> uses that URI to retrieve location information.
>
> [BA] This raised the question for me of how general the deref
> mechanism is. Is it just for HELD, or is it a generic mechanism for
> dereferencing?

Good point. We could discuss the use of HTTP to dereference URIs in other schemes, which is theoretically possible and practically infeasible. Better to properly constrain scope:

[...] This document specifies how the holder of an "http:" or "https:" location URI [...]

> Use of HELD as a dereferencing protocol has the advantage that the
> Location Recipient can indicate the type of location information it
> would like to receive. This functionality is already available
> with
> the HELD base specification, described in [RFC5985]. Furthermore,
> the HELD response from the LIS towards the Location Recipient not
> only provides the PIDF-LO but also encapsulates supplementary
> information, such as error messages, back to the Location
> Recipient.
>
> [BA] There are other ways of indicating the type of location info
> that the recipient wants to receive (think REST). Are there benefits
> of using HELD here really worth sacrificing generality? Personally, I
> think not. Many of the error cases can probably be handled in
> generic HTTP/TLS.

You are right, content negotiation could be made to work. Given the composite nature of PIDF, the limitations of content negotiation become evident. Ultimately, what we're looking for is the richness of expression available in location filters [draft-ietf-geopriv-loc-filters], including the referenced RFC 4661 capabilities. That becomes unwieldy very quickly when expressing it in a media type.

> Location URIs created for use with HELD dereferencing use the
> "https:" or "http:" scheme. The behaviour described in this
> document
> can be used by Location Recipients that are aware of the fact that
> the URI is a location URI.
>
> [BA] So how does the dereferencer know that HELD is to be used to
> dereference rather than generic HTTP??

They might use the content type of the response entity. The draft now makes this observation in S4.2, along with the other GET semantics.

A Location Recipient MAY infer from a response containing the HELD content type, "application/held+xml", that a URI references a resource that supports HELD.

> 1. The Target acquires a location URI from the LIS. This might use
> HELD as a location configuration protocol (LCP).
>
> [BA] "might" again. If it could be from another LCP, please say so.

Done.

> Depending on the URI
> scheme of the location URI dereferencing might, as is the case
> for "https:" or "http:" URIs, be performed as described in this
> document.
>
> [BA] Are you saying that deferencing of an https: or http: URI might
> be performed in some other way than is described here? If so, how??

Yeah, that's clumsy. How about:

An "https:" or "http:" URI is dereferenced as described in this document; other URI schemes might be dereferenced using another method.

> Using possession as a basis for authorization means that, once
> granted, authorization cannot be easily revoked.
>
> [BA] Well, at least without changing to the "Access Control" model.

Right. Or you could say that there is always access control, but use of "possession model" implies an expansively liberal access control policy. That policy might be changed to become more restrictive, which is exactly what the policy URI document does.

> In order to control access to location information based on the
> identity of the Location Recipient, use of authorization by
> possession is employed. By controlling which Location Recipients
> receive location URIs, access to location information is
> controlled.
>
> [BA] There are other possibilities that come to mind, too (e.g.
> firewall filter rules)

Sure. Though describing such options probably doesn't add enough value to justify the extra bytes required.

> Section 4.2
>
> GET is the method assumed by generic HTTP user agents, therefore
> unless context identifies an "https:" URI as a HELD URI, such a
> user
> agent might simply send an HTTP GET. Rather than providing an HTTP
> 405 (Method Not Allowed) response indicating that POST is the only
> permitted method, this document describes a way for a LIS to
> provide
> a HELD location response if it receives an HTTP GET request.
>
> [BA] It's nice that GET is supported, and I suspect that
> implementation of this will be quite popular, to enable generic
> dereferencing. Given that, I'd try to align some of the earlier
> discussion to point out that generic deref via GET is supported. In
> particular, I'd make GET support mandatory-to-implement.

That's a good point. I certainly would expect GET to be the most common case, so I've made it mandatory as you suggest. I think that a similar sentiment was expressed by Julian Reschke as well, but I failed to translate it into a MUST.

--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] draft-ietf-geopriv-policy-uri-00 WGLC

On 4/8/11 12:35 AM, Alissa Cooper wrote:
> We have WGLCs open for draft-ietf-geopriv-deref-protocol-02 and
> draft-ietf-geopriv-policy-uri-00 until next Tuesday, April 12. Please
> send your comments to the appropriate threads (even if you're just
> giving a thumbs-up). Thus far there have been no responses.

Although I'm not following GEOPRIV (and so don't know if there are
relevant threads to comment on), Richard asked me to perform a review of
this document. I'm doing this in kind of a hurry, so please excuse the
fact that my comments are mostly in the order I encountered them when
reading through the document.

The first thing that I notice is that the document rather tightly scopes
policy URIs to being HTTP-only. I'm not suggesting that this document
should go about defining other mechanisms; but it probably should leave
the door open for future documents to do so without redefining key
terms. (For example, if there were a good reason to use SIP to deliver
policy information in the future, we should be able to do so without
having to change the definition of "Policy URI.")

Specifically, I would suggest re-crafting section 3 to read more like:

A policy URI is a URI that identifies a policy resource that
contains the authorization policy for a linked location resource.
Access to the location resource is governed by the contents of
the authorization policy. This document defines the behavior of
clients and servers using HTTP [RFC2616] policy URIs.

A policy URI identifies a resource that a Rule Maker can use to
inspect and install policy documents that tell a Location Server
how it should protect the associated location resource.

This would also have minor impacts elsewhere in the document so that
statements specific to the HTTP usage were qualified to indicate that
the statements are specific to the HTTP usage (e.g. changing the title
of section 3.1 to "HTTP Policy URI Usage").

On a separate topic, I note that the document implies that multiple
clients are capable of updating the document via PUT and DELETE
operations, but without mentioning the use of etags. This can cause
races in the multi-client case (client A GETs the policy, appends a
rule; client B PUTs a set of rules; and then client A PUTs his modified
policy in place, overwriting B's policy). I believe the document needs
to address this case by mentioning etags as a means for avoiding races.
I would suggest that we even go so far as to require servers to return
Etag header fields for all HTTP Policy URIs, so as to ensure that
clients can use this mechanism. (This has impacts on the examples in
section 5.3: add an "ETag" to the 200, and an "If-Match" to the PUT).

[Minor editorial nit in the first paragraph of section 3.2: I believe
"different to" is a uniquely British usage, while "different from" is
used in all English dialects]

Section 3.2 states: "A HELD-specific extension also allows a requester
to specifically ask for a policy URI." I think this needs a citation
(e.g., "See section 4.1").

Section 4.1 claims 'A policy URI MUST use the "http:" or "http:"
scheme...' I suspect that one of those should be "https," but the more
relevant comment here is that this seems an unnecessary restriction. As
I mentioned above, I think it would be short-sighted to close the door
to using other protocols in the future. I suggest that we instead define
clear behavior if the client does not understand the URI scheme (e.g.,
it is treated the same as if there were no URI present). What would be
really nice would be adding an attribute to the "requestPolicyUri"
element that indicated the preferred URI scheme. For example:

<requestPolicyUri scheme="https"/>

(The same comments apply to section 4.2, minus the bit about
requestPolicyUri).

/a
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] WGLC: draft-ietf-geopriv-policy-uri-00

Hey Hannes,

Always nice when co-authors submit comments :)

> In the document we do not use Target but instead host. Is this intentional?

The host in this case is being both a Target and a Rule Maker. I don't see a need to replace all the terms, but we could insert some text to clarify.

> We also use the term LS rather than LIS. Is this intentional?

This makes sense, since the location server in question really is acting as a Location Server in the sense of RFC 3693 and geopriv-arch.

>
> A few minor comments inline:
>
> FROM:
> TO:
> "
> their flexibility, in that they do not provide hosts (the clients
> ...
> LCP server (acting for the LIS) can inform a host as to
> which policy document controls a given location resource, and the LCP
> client (in its Rule Maker role) can inspect this document and modify
> it as necessary.
> "

Agree to change Device / client to "host". Think that Location Server is better than LIS here.

>
> The following figure, which is based on Figure 1 of RFC 5808, illustrates the interactions:

Added the figure to the Introduction, but changed the letters to numbers to correspond to 5808.

> In Section 3 I noticed that we only talk about HTTP URIs. We may want to use HTTP/HTTPS instead.

Done, in first sentence.

> The current text gives the impression that the policy URI is bound to location itself. Location, however, is an always changing element in the architecture. Instead, the policy URI follows the lifecycle of it the location URI: when all the location URI are destroyed the policy URI becomes invalid as well.
> As the text later says each location URI is associated with zero or one policy URIs. This is not correct given the example in Section 5.1 where a single policy URI is associated with two location URIs.

You've got the constraint backwards: Each location URI has at most one policy URI, but each policy URI can control multiple location URIs. As Martin notes, in light of that, the example in Section 5.1 is fine.

I agree with Martin that the diagram is unnecessary.

> Now, the only question is how the lifetime of each of these objects relate to each other.
> For example, a policy may contain a validity element. For example, do you expert the location URI to be invalid when the validity time expires?

Yes, by definition. But not necessarily permanently; the RM can send a new policy that re-opens the validity period. The validity ends permanently when the HELD validity time is reached or the RM sends a DELETE request. Added a note:
"
A location URI can thus become valid in three ways: By the expiration of a validity interval in policy, by the removal of a policy document with a DELETE request, or by the expiry of the HELD-specified validity interval. The former is temporary, since the policy URI can be used to update the validity interval in the policy; the latter two are permanent.
"

> TO:
> "
> A DELETE request to a policy URI is a request to delete the
> referenced policy document. The LS MUST also terminate access to
> location information referenced by any of the location URIs
> previously distributed.
> "

How is this different from the current text?
"
the Location Server deletes the policy referenced by the URI and disallows any further access to the location resources it governs.
"
I've added a MUST here, if that helps.

> There is a small typo in the following sentence:
>
> A policy URI MUST NOT be provided to an entity that is not
> authorized to view or set policy. This document does not describe
> how policy might be provided to entities other than for location
> configuration. in responses to dereferencing requests
> ˆˆˆˆ
> [I-D.ietf-geopriv-deref-protocol] or requests from third parties
> [I-D.ietf-geopriv-held-identity-extensions].

Fixed.

> TO:
> "
> From a security point of view a policy URI has to be treated like a
> secret shared between Location Server and each of its
> clients. Knowledge of a policy URI is all that is required to
> perform any operations allowed on the policy. Thus, a policy URI is
> constructed so that it is hard to predict (see Section 8) and
> confidentiality protected while in transit.
> "

Agree with Martin. Made the latter change, but not the former.

> s/5.3. Basic access control policy/5.3. Basic Access Control Policy

Fixed.

> Section 5.3 says:
>
> "
> Consider a user that gets the policy URI
> <https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, as in the
> above LCP example. The first thing this allows the user to do is
> inspect the default policy that the LS has assigned to this URI:
> "
>
> I would suggest not to talk about the user but instead talk about the LCP client software since otherwise one might get the impression that a human would do any of this.

Done. s/user/client/g

> From:
> "
> Finally, after using the URI for a period, the user wishes to
> permanently invalidate the URI.
> "

Leaving this as "user", since clients don't make authorization decisions.

> Section 7.1:
> The text says "URI: urn:ietf:params:xml:ns:grip" but it has to be "urn:ietf:params:xml:ns:geopriv:held:policy".

Fixed.

> Security considerations: Wouldn't it be more useful to always require HTTPS to be used? Are there really cases where it wouldn't be used? Do we feel OK with the requirement that every LCP has to confidentiality protect the transmission of the policy URI to the host given that DHCP does not meet this confidentiality requirement?

I agree with Martin's comments here.

> Regarding the policy capabilities: In HELD context we had the functionality for limited use URIs and Snapshot URIs. A limited use URI can only be accessed a fixed number of times to yield the location of the Target. A snapshot URI points to the location of the Target at a specific point in time, and no matter how many times the URI is accessed it will always yield the same location.
>
> Did we loose this functionality?

I agree with Martin's comments here, with one revision: These should be common-policy extensions rather than HELD extensions. For example:
<transformations>
<provide-at-time>2011-04-29T12:34</provide-at-time>
</transformations>

But in any case, not in this document.

--Richard

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] geopriv-policy algorithm constraints and goals

I'm not sure that I can map your description of the indistinguishability property onto my mental model, but your description of the "location indistinguishability" and "destination indistinguishability" made sense.

This discussion might make sense as a preface to the discussion on assumptions. Can I request that you draft a few paragraphs that introduces the subject and how we're planning to apply it?

On 2011-04-22 at 19:23:55, Jorge Cuellar wrote:
> > Discrete location assumption: An algorithm SHOULD protect a discrete
> > location that is remote from adjacent known locations. This
> assumption
> > might be useful to an adversary if the location of the Target is
> known
> > only at discrete points without known locations in between. For
> > example, a person that disables location tracking in transit between
> > two points might only have known locations at either end of the
> > journey.
>
> It looks good, but did not understand it fully: How far is "remote"?
> What is an "adjacent known location"? If the location of a target is
> known at discrete points, then the locations visited in the meantime
> should also be protected, you mean something like that?

Yeah, that text doesn't read so well to me either. It might be necessary to handle contiguous and non-contiguous paths in some other part of the discussion.

--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] WGLC: draft-ietf-geopriv-policy-uri-00

Hi Hannes,

I think that most of your comments are good feedback, I'll pick out a few that I think need response.

On 2011-04-23 at 01:43:42, Hannes Tschofenig wrote:
> TO:
> "
> From a privacy perspective, however, current LCPs are limited in
> their flexibility, in that they do not provide hosts (the clients
[...]
> policy references. Using the mechanisms defined in this document,
> an
> LCP server (acting for the LIS) can inform a host as to

I think that the original "(active for the Location Server)" was correct in this context. Policy is enforced by the Location Server and so policy is created for the benefit of the LS. I consider LIS and LCP server to be synonymous.

The other edits are good.

> which policy document controls a given location resource, and the
[...]
> "
>
>
> In Section 3 I noticed that we only talk about HTTP URIs. We may want
> to use HTTP/HTTPS instead.

I tend to use "HTTP URI" as the general and "http: or https: URI" as the specific. HTTPS isn't a protocol, though the contemporary etymologists might disagree given its widespread use.

On the other hand, that degree of pedantry doesn't help a casual or lazy reader. The goal is to make it clear that a secured resource is important. Without making Section 3 any less succinct.

> The text in Section 3.2 says:
>
> "
> A Location Server creates a policy URI for a specific location
> resource at the time that the location resource is created; that is,
> a policy URI is created at the same time as the location URI that it
> controls. The URI of the policy resource MUST be different to the
> location URI.
> "
>
>
> The current text gives the impression that the policy URI is bound to
> location itself. Location, however, is an always changing element in
> the architecture. Instead, the policy URI follows the lifecycle of it
> the location URI: when all the location URI are destroyed the policy
> URI becomes invalid as well.
> As the text later says each location URI is associated with zero or
> one policy URIs. This is not correct given the example in Section 5.1
> where a single policy URI is associated with two location URIs.

There might need to be a clarification, but there is an important distinction between _resource_ and _URI_. A better way to describe it might be:

There is exactly one policy resource for each location resource. For a given resource, there are zero or more URIs that can be used to identify that resource.

Section 3.2 might need to be updated with text to this effect.

Based on this model, Section 5.1 shows an example where location URIs = 2 and policy URIs = 1.

> So, I suggest to add a picture to illustrate the case. Here is a
> proposal:

That's a good picture - though I'd not use the term "Context Handler" without better context [sic]. I'm inclined not to include the picture. If we did include such a picture, I'd include two things: policy resource/URI separation, and location resource/location snapshot distinction - that is, noting that the location resource is tied to a particular device and that the value/representation of the resource changes as the location of the device changes.

> Now, the only question is how the lifetime of each of these objects
> relate to each other.
> For example, a policy may contain a validity element. For example, do
> you expert the location URI to be invalid when the validity time
> expires?

Policy and location resources are irrevocably tied. Their lifetimes are the same.

Any policy needs to be enforced against the location URI until the location URI expires. If the policy includes validity statements, then those need to be respected.

>
> We have to describe the followingI believe it should instead say:

[[Missed something here?]]
>
> "
> A Location Server creates a policy URI at the same time as the
> location URI
> that it controls. Internally to the Location Server the policy URI
> refers to
> the location URIs. The URI of the policy resource MUST be different
> to the
> location URI since they refer to different information elements.
> "

I'd prefer not to include this. See above discussion on URIs and resources in respect to the first two sentences.

For the last sentence, the reason you give is only the smallest part. There's actually more reason than the fact that they are different resources. The security considerations section explains why you shouldn't be able to go from location URI to policy URI in any way: the policy URI is primarily protected by the fact that it isn't known.

> TO:
>
> "
> [1: From a security point of view a policy URI has to be treated like a
> secret shared between Location Server and each of its
> clients.] Knowledge of a policy URI is all that is required to
> perform any operations allowed on the policy. Thus, a policy URI is
> constructed so that it is hard to predict (see Section 8) [2: and
> confidentiality protected while in transit.]
> "

I'm not sure what the first edit adds. The addition to the end of the paragraph is a good pickup.

> Security considerations: Wouldn't it be more useful to always require
> HTTPS to be used? Are there really cases where it wouldn't be used? Do
> we feel OK with the requirement that every LCP has to confidentiality
> protect the transmission of the policy URI to the host given that DHCP
> does not meet this confidentiality requirement?

DHCP weasels around that by relying on layer 1 or layer 2 measures - they assume that the wire is secured somehow. That gives DHCP the ability to claim confidentiality. It's fairly clear that open WiFi wrecks that, but you could say that RFC 3825^H^H^H^H 3825bis and RFC 4676^H^H^H^H 4776 do have the proper "caveat lector" sections.

> Regarding the policy capabilities: In HELD context we had the
> functionality for limited use URIs and Snapshot URIs. A limited use
> URI can only be accessed a fixed number of times to yield the location
> of the Target. A snapshot URI points to the location of the Target at
> a specific point in time, and no matter how many times the URI is
> accessed it will always yield the same location.
>
> Did we loose this functionality?

If you want to think about it in those terms, yes. Conceptually, those are still possible, though I've been convinced that limited use is hard enough to implement that adding it would be a waste of effort. Snapshot might still be addressed through a HELD extension.

> Ciao
> Hannes

--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] Review of draft-ietf-geopriv-held-measurements-03

I was asked in Prague to review
[draft-ietf-geopriv-held-measurements-03] for the IEEE 802 considerations.
My comments follow:

In section 5.1 LLDP Measurements regarding the note:
I believe that technical capability originally specified in LLDP-MED is
now included in the 2009 revision of 802.1AB (IEEE Std 802.1AB - 2009).
Further, the 802.3 specific TLVs specified in 802.1AB clause 6.3 have
been superceded by IEEE Std 802.3bc - 2009 (as anticipated in Note 2 of
that sub-clause). Thus I suspect that the reference to LLDP - MED and
ANSI-TIA-1057 should be removed.

In the text below Figure 6, the measurement set seems to assume that
both the wifi end station and the access point are stationary. I'm not
clear whether we are attempting fully cope with the "in motion" case. We
can (at least) detect it and put in an indicator (e.g. some sort of
flag, etc. for whether location is changing within some time/distance
parameters).

Re: Page 19, flightTime: I don't believe that the statement "Measurement
of this value requires that stations synchronize their clocks" is
correct, at least for the nominally static case. It would be true if the
result were based on a 1 way measurement. However, if it is the average
of a 2 way measurement then any difference in local time-of-day would be
cancelled out (assuming matching clock rates). It would seem more useful
to allow the lesser constrained case.

In section 5.6, DSL Measurements {Full 2 paragraphs of text is
reproduced, my comments are in curly brackets}:

Digital Subscriber Line (DSL) networks rely on a range of network
technology {"technology" should be plural}. DSL deployments regularly
require cooperation between multiple organizations. These fall into two
broad categories: infrastructure providers and Internet service
providers (ISPs).
Infrastructure providers manage the bulk of the physical infrastructure
including cabling. End users obtain their service from an ISP {Insert:
"(Who may or may not be be the same entity as the infrastructure
provider)"}, which manages all aspects visible to the end user including
IP address allocation and operation of a LIS. See [DSL.TR025] and
[DSL.TR101] for further information on DSL network deployments and the
parameters that are available.

Exchange of measurement information between these organizations is
necessary for location information to be correctly generated. The
ISP LIS needs to acquire location information from the infrastructure
provider. However, {Insert: "since"} the infrastructure provider has
{Replace" "has" with "may have"} no knowledge of Device identifiers, it
can only identify a stream of data that is sent to the ISP. This is
resolved by passing measurement data relating to the Device to a LIS
operated by the infrastructure provider.

RE: 5.6.3. Ethernet VLAN Tag Measurements
There are several types of Ethernet VLANs in the world. This information
seems to be specific to a particular VLAN specification that does not
seem to be referenced.

RE: 11.2. Informative References
[ANSI-TIA-1057] I think this can be deleted now that the capability is
included in 802.1AB

[IEEE.8021AB] To both update the citation and correct its form, it
should be:
"IEEE Standard for Local and metropolitan area networks— Station and
Media Access Control Connectivity Discovery" IEEE Std 802.1AB™-2009

Since the specifications for the 802.3 TLVs in 802.1AB-2009 have been
superceded by IEEE Std 802.3bc - 2009 a citation should be added for it.
Since the current correct name for that standard is SO long and
unwieldly (and the next revision will shorted the 802.3 title to
"Standard for Ethernet") I suggest
"IEEE Standard for Local and metropolitan area networks— Part 3:
Amendment 2: Ethernet Organizationally Specific Type, Length, Value
(TLVs)" IEEE Std 802.3bc™-2009

Both 802.1AB - 2009 and 802.3bc - 2009 can be obtained at no charge from
http://standards.ieee.org/about/get/

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] WGLC: draft-ietf-geopriv-policy-uri-00

Hi Alissa, 

here are a few review comments. 

In the document we do not use Target but instead host. Is this intentional? 
We also use the term LS rather than LIS. Is this intentional? 

A few minor comments inline:

FROM:

"
   From a privacy perspective, however, current LCPs are limited in
   their flexibility, in that they do not provide the Device (the client
   in an LCP) with a way to inform the Location Server with policy for
   how his location information should be handled.  This document
   addresses this gap by defining a simple mechanism for referring to
   and manipulating policy, and by extending current LCPs to carry
   policy references.  Using the mechanisms defined in this document, an
   LCP server (acting for the Location Server) can inform a client as to
   which policy document controls a given location resource, and the LCP
   client (in its Rule Maker role) can inspect this document and modify
   it as necessary.
"
TO:
"
   From a privacy perspective, however, current LCPs are limited in
   their flexibility, in that they do not provide hosts (the clients
   in an LCP) with a way to inform the Location Server with 
   policy for how his location information should be handled.  This document
   addresses this gap by defining a simple mechanism for referring to
   and manipulating policy, and by extending current LCPs to carry these
   policy references.  Using the mechanisms defined in this document, an
   LCP server (acting for the LIS) can inform a host as to
   which policy document controls a given location resource, and the LCP
   client (in its Rule Maker role) can inspect this document and modify
   it as necessary.
"

The following figure, which is based on Figure 1 of RFC 5808, illustrates the interactions:

    +---------+---------+   Location    +-----------+
    |         |         |  Dereference  | Location  |
    |      LIS/LS       +---------------+ Recipient |
    |         |         |   Protocol    |           |
    +----+----+----+----+      (d)      +-----+-----+
         |         |                          |
         |         |                          |
   Policy|         |Location                  |Location
 Exchange|         |Configuration             |Conveyance
      (b)|         |Protocol                  |Protocol
         |         |(a)                       |(c)
         |         |                          |
  +------+----+----+----+                     |
  |  Rule     | Target/ |                     |
  |  Maker    | Host    +---------------------+
  |           |         |
  +-----------+---------+



In Section 3 I noticed that we only talk about HTTP URIs. We may want to use HTTP/HTTPS instead. 

The text in Section 3.2 says: 

"
   A Location Server creates a policy URI for a specific location
   resource at the time that the location resource is created; that is,
   a policy URI is created at the same time as the location URI that it
   controls.  The URI of the policy resource MUST be different to the
   location URI.
"


The current text gives the impression that the policy URI is bound to location itself. Location, however, is an always changing element in the architecture. Instead, the policy URI follows the lifecycle of it the location URI: when all the location URI are destroyed the policy URI becomes invalid as well. 
As the text later says each location URI is associated with zero or one policy URIs. This is not correct given the example in Section 5.1 where a single policy URI is associated with two location URIs.

So, I suggest to add a picture to illustrate the case. Here is a proposal:


                     +----------+
                     | Actual   |
                     | Location |
                     +----+-----+
                          |
                     +----+-----+
                     | Device   |
                     | Identity |          +-----------+
                     +----+-----+          | Policy    |
                          |                | Reference |
                          |                +-----+-----+
                          |                      |
                     +----+-----+          +-----+-------+
                     | Context  |          | Policy      |
                     | Handler  |----------+ Information |
                     +----=+----+          +-------------+
                       ,-'  '-.
                    ,-'        `-.
                _.-'              `..
             ,,'                     `._
     +------'---------+      +---------+------+
     | Location URI-1 | ...  | Location URI-n |
     +----------------+      +----------------+

A few words about the picture: 

- There is some progressing engine in the location server that maps the input identifiers to some location. This figure is about the location URIs being provided as input to the entire process. 

- There is an implementation internal data structure that glues everything together - the context handler. The policy information is bound to this handler since it is not bound to a specific identifier per se (at least not in the way how the document is written).

Now, the only question is how the lifetime of each of these objects relate to each other. 
For example, a policy may contain a validity element. For example, do you expert the location URI to be invalid when the validity time expires? 

In particular, the following statement needs to be strong: 

FROM:
"
   A DELETE request to a policy URI is a request to delete the
   referenced policy document and terminate access to the protected
   resource. 
"

TO:
"
   A DELETE request to a policy URI is a request to delete the
   referenced policy document. The LS MUST also terminate access to 
   location information referenced by any of the location URIs 
   previously distributed. 
"

We have to describe the followingI believe it should instead say:

"
   A Location Server creates a policy URI at the same time as the location URI 
   that it controls. Internally to the Location Server the policy URI refers to 
   the location URIs. The URI of the policy resource MUST be different to the
   location URI since they refer to different information elements. 
"

There is a small typo in the following sentence:

A policy URI MUST NOT be provided to an entity that is not
   authorized to view or set policy.  This document does not describe
   how policy might be provided to entities other than for location
   configuration. in responses to dereferencing requests
                ˆˆˆˆ
   [I-D.ietf-geopriv-deref-protocol] or requests from third parties
   [I-D.ietf-geopriv-held-identity-extensions].




FROM:

"
   A policy URI is a shared secret between Location Server and its
   clients.  Knowledge of a policy URI is all that is required to
   perform any operations allowed on the policy.  Thus, a policy URI is
   constructed so that it is hard to predict (see Section 8).
"

TO:

"
   From a security point of view a policy URI has to be treated like a 
   secret shared between Location Server and each of its
   clients.  Knowledge of a policy URI is all that is required to
   perform any operations allowed on the policy.  Thus, a policy URI is
   constructed so that it is hard to predict (see Section 8) and
   confidentiality protected while in transit. 
"


s/5.3.  Basic access control policy/5.3.  Basic Access Control Policy


Section 5.3 says:

"
   Consider a user that gets the policy URI
   <https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, as in the
   above LCP example.  The first thing this allows the user to do is
   inspect the default policy that the LS has assigned to this URI:
"

I would suggest not to talk about the user but instead talk about the LCP client software since otherwise one might get the impression that a human would do any of this. 



From:

"
   Finally, after using the URI for a period, the user wishes to
   permanently invalidate the URI.
"

Section 7.1: 

The text says "URI: urn:ietf:params:xml:ns:grip" but it has to be "urn:ietf:params:xml:ns:geopriv:held:policy". 

Security considerations: Wouldn't it be more useful to always require HTTPS to be used? Are there really cases where it wouldn't be used? Do we feel OK with the requirement that every LCP has to confidentiality protect the transmission of the policy URI to the host given that DHCP does not meet this confidentiality requirement? 



Regarding the policy capabilities: In HELD context we had the functionality for limited use URIs and Snapshot URIs. A limited use URI can only be accessed a fixed number of times to yield the location of the Target.  A snapshot URI points to the location of the Target at a specific point in time, and no matter how many times the URI is accessed it will always yield the same location.

Did we loose this functionality? 

Ciao

Hannes

On Mar 29, 2011, at 10:20 AM, Alissa Cooper wrote:

This is a GEOPRIV Working Group Last Call for comments on
draft-ietf-geopriv-policy-uri-00

Please send your comments to the list by 12 April 2011.  As always, please remember to send a note in if you've read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem."








_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] geopriv-policy algorithm constraints and goals

> I think it is useful. What would be a "later" note?
>Something attached to introductory or explanatory text,
>rather than a specific point in the discussion. For
>instance,

Fine.

>>>> And also I would add a new assumption:

>>>> Indistinguishability assumption:

>> Up to jere it is only a definition: any protocol defines
>> an indistinguishability region, there is no way to avoid
>> it. (But perhaps, it is not trivial to calculate what is
>> the indistinguishability region for a given algorithm).
>> It is close to well known notions of
>> indistinguishability, like
>> http://en.wikipedia.org/wiki/Ciphertext_indistinguishability
>> or, even more, the one used in information flow, see for
>> instance: http://www.cse.chalmers.se/~andrei/jsac.pdf So
>> this is not solution space.

> The indistinguishability property might be generalized as:
> given a set of N (chosen) plaintexts T[1], ...T[N], then
> any ciphertext from the set produced by the algorithm
> E(T[x]) cannot be identified as being produced by any of
> the set of plaintexts with a probability greater than 1/N.

This is not a generalization (If T[i], T[j] are
indistinguisable, for all i,j, then T[1], ...T[N] are
indistinguishable in the sense you mention.

> There's two ways this principle is being applied. The most
> important is where the plaintext is the location of a
> target as a function of time. That is T is the location of
> the Target as it varies over time. Addressing this form of
> indistinguishability has to be the primary goal.

If you think of T(t) as the continous path, and you are
looking at the values O(T(t)) of obscured locations
(assuming that the algorithm is active each instant of
time), then you get unrealistic versions of
inditinguishability.

> You are talking about a second case where each discrete
> location for the same target is treated as a separate
> plaintext.

Not exactly. Let me rephrase:

We have high sensitive information (the real location ofr
locations of the target) and low sensitive information (the
obscured location, which is the output of the algorithm).
The "attacker" is simply anyone who is trying to deduce
information about the real location of the target based on the
outputs of the algorithm and perhaps some further information
about the past real locations of the target. We have a notion of
two points being "indistinguishable as locations"
and "indistinguishable as destinations".

For the first one, assume a static (i.e: not moving) target. We
call two points "indistinguishable as locations" for an
algorithm, if an attacker can not infer from the outputs of the
algorithm any information about which of the two points is the
location of a static target. In particular, if the algorithm
provides the same distribution of responses for the two
locations, those locations are indistinguishable.

For the second one, consider the paths starting at one given
point. Two points B1, B2 are "indistinguishable as destinations"
if for any path starting in a point A and ending in B1
there is a path starting in a point A and ending in B2,
such that the attacker can not infer from the outputs of the
algorithm any information about which of the two paths the
target is travelling and in particular, which destination
the target has eventually arrived to.

> The point under debate is not indistinguishability, but
> whether this property forms part of the attack options we
> wish to address (the "assumptions"). Indistinguishability
> is a tool for analyzing an algorithm, but not part of the
> set of attacks. Thus, neither part of the solution space or
> the set of goals, but a framework for understanding if
> we've achieved our goals.

Just as ciphertext_indistinguishability is the corect concept for
anylyzing if aen encryption algorithm is ok, I think the
indistinguishability of locations is the correct concept here. It
creally relates to the possibilities of attackers learning
infromation from obscured locations.

> If you are looking for an assumption, then we're still
> talking about the "frequent destination" or "same location"
> assumption. That is, the attacker assumes that the known
> location is the same as the known location that was
> previously acquired. The question of how much information
> the attacker gains when making this assumption is a matter
> for the analysis of the algorithm.

> Incidentally, there's another assumption that's important
> in analyzing the algorithm that I proposed:

> Discrete location assumption: An algorithm SHOULD protect a
> discrete location that is remote from adjacent known
> locations. This assumption might be useful to an adversary
> if the location of the Target is known only at discrete
> points without known locations in between. For example, a
> person that disables location tracking in transit between
> two points might only have known locations at either end of
> the journey.

It looks good, but did not understand it fully: How far
is "remote"? What is an "adjacent known location"? If the
location of a target is known at discrete points, then the
locations visited in the meantime should also be protected,
you mean something like that?

> Goal. Let us not place constraints that we cannot provably
> meet.

I agree. I think indistinguishability (as stated above) is
achievable.

> As an aside, in relation to this work, I've been acutely
> aware of the effect of "Schneier's Law":
> <http://www.schneier.com/crypto-gram-1104.html#10>.
Me too.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] [geopriv] #49: Review of Deref Protocol document

#49: Review of Deref Protocol document

Overall, I think that this document could be clearer that the deref
protocol defined can be used with any LCP, and that support for generic
deref via GET is supported (e.g. I'd make that a mandatory to implement).

Detailed comments:

Provision of location information by reference [RFC5808] involves the
creation of a resource that is identified by a "location URI". A
"location URI" is a URI [RFC3986] that identifies a resource
containing the location of an entity. A location URI might identify
a temporary resource, created in response to a HTTP-Enabled Location
Delivery (HELD) [RFC5985] request.

[BA] might? This left me wondering what else it might be used for.
For example, could it represent a temporary resource created in
response to another protocol request (e.g. DHCP), or maybe a non-temporary
resource?

A location URI does not
intrinsically include location information, instead the URI is
"dereferenced" by a Location Recipient to acquire location
information. This document specifies how a holder of a location URI
uses that URI to retrieve location information.

[BA] This raised the question for me of how general the deref mechanism
is. Is it just for HELD, or is it a generic mechanism for dereferencing?

Use of HELD as a dereferencing protocol has the advantage that the
Location Recipient can indicate the type of location information it
would like to receive. This functionality is already available with
the HELD base specification, described in [RFC5985]. Furthermore,
the HELD response from the LIS towards the Location Recipient not
only provides the PIDF-LO but also encapsulates supplementary
information, such as error messages, back to the Location Recipient.

[BA] There are other ways of indicating the type of location info that
the recipient wants to receive (think REST). Are there benefits of
using HELD here really worth sacrificing generality? Personally, I
think not. Many of the error cases can probably
be handled in generic HTTP/TLS.

Location URIs created for use with HELD dereferencing use the
"https:" or "http:" scheme. The behaviour described in this document
can be used by Location Recipients that are aware of the fact that
the URI is a location URI.

[BA] So how does the dereferencer know that HELD is to be used to
dereference
rather than generic HTTP??

1. The Target acquires a location URI from the LIS. This might use
HELD as a location configuration protocol (LCP).

[BA] "might" again. If it could be from another LCP, please say so.

Depending on the URI
scheme of the location URI dereferencing might, as is the case
for "https:" or "http:" URIs, be performed as described in this
document.

[BA] Are you saying that deferencing of an https: or http: URI might be
performed in some other way than is described here? If so, how??

Using possession as a basis for authorization means that, once
granted, authorization cannot be easily revoked.

[BA] Well, at least without changing to the "Access Control" model.

In order to control access to location information based on the
identity of the Location Recipient, use of authorization by
possession is employed. By controlling which Location Recipients
receive location URIs, access to location information is controlled.

[BA] There are other possibilities that come to mind, too (e.g. firewall
filter rules)

Section 4.2

GET is the method assumed by generic HTTP user agents, therefore
unless context identifies an "https:" URI as a HELD URI, such a user
agent might simply send an HTTP GET. Rather than providing an HTTP
405 (Method Not Allowed) response indicating that POST is the only
permitted method, this document describes a way for a LIS to provide
a HELD location response if it receives an HTTP GET request.

[BA] It's nice that GET is supported, and I suspect that implementation of
this
will be quite popular, to enable generic dereferencing. Given that, I'd
try to align some of the earlier discussion to point out that generic
deref via GET is supported. In particular, I'd make GET support
mandatory-to-implement.

--
---------------------------------------+------------------------------------
Reporter: bernard_aboba@… | Owner:
Type: defect | Status: new
Priority: critical | Milestone:
Component: deref-protocol | Version: 1.0
Severity: In WG Last Call | Keywords:
---------------------------------------+------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/geopriv/trac/ticket/49>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] FYI: iPhone and location tracking - potential major privacy issues

And some counterpoint:
<https://alexlevinson.wordpress.com/2011/04/21/3-major-issues-with-the-latest-iphone-tracking-discovery/>

On Apr 21, 2011, at 11:26 AM, Carl Reed wrote:

> http://www.cnn.com/2011/TECH/mobile/04/20/iphone.tracking/index.html?hpt=T2
>
> Carl Reed, PhD
> CTO and Executive Director Specification Program
> Open Geospatial Consortium
> www.opengeospatial.org
>
> The OGC: Making Location Count!
>
> ---------------------
>
> This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
>
> "The important thing is not to stop questioning." -- Albert Einstein
> "Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller
> _______________________________________________
> 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] FYI: iPhone and location tracking - potential major privacy issues

http://www.cnn.com/2011/TECH/mobile/04/20/iphone.tracking/index.html?hpt=T2

 

Carl Reed, PhD
CTO and Executive Director Specification Program
Open Geospatial Consortium
www.opengeospatial.org

 

The OGC: Making Location Count!

 

---------------------

 

This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender  immediately by return email and delete this communication and destroy all copies.

 

"The important thing is not to stop questioning." -- Albert Einstein
"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller

Re: [Geopriv] geopriv-policy algorithm constraints and goals

On 2011-04-16 at 16:35:47, Jorge Cuellar wrote:
> > If you think that the text is useful, I'd add it as a later note.
>
> I think it is useful. What would be a "later" note?

Something attached to introductory or explanatory text, rather than a specific point in the discussion. For instance,

Keeping the details of an algorithm secret does not serve any useful purpose. At best, it means that there is another secret that you need to maintain. At worst, it denies you the expertise of other interested individuals with skills that might otherwise be applied to strengthening the algorithm.

> > > And also I would add a new assumption:
> > >
> > > Indistinguishability assumption:
>
> Up to jere it is only a definition: any protocol defines an
> indistinguishability region, there is no way to avoid it.
> (But perhaps, it is not trivial to calculate what is the
> indistinguishability region for a given algorithm). It is close to
> well known notions of indistinguishability, like
> http://en.wikipedia.org/wiki/Ciphertext_indistinguishability
> or, even more, the one used in information flow, see for instance:
> http://www.cse.chalmers.se/~andrei/jsac.pdf
> So this is not solution space.

The indistinguishability property might be generalized as: given a set of N (chosen) plaintexts T[1], ...T[N], then any ciphertext from the set produced by the algorithm E(T[x]) cannot be identified as being produced by any of the set of plaintexts with a probability greater than 1/N.

There's two ways this principle is being applied. The most important is where the plaintext is the location of a target as a function of time. That is T is the location of the Target as it varies over time. Addressing this form of indistinguishability has to be the primary goal.

You are talking about a second case where each discrete location for the same target is treated as a separate plaintext.

The point under debate is not indistinguishability, but whether this property forms part of the attack options we wish to address (the "assumptions"). Indistinguishability is a tool for analyzing an algorithm, but not part of the set of attacks. Thus, neither part of the solution space or the set of goals, but a framework for understanding if we've achieved our goals.

If you are looking for an assumption, then we're still talking about the "frequent destination" or "same location" assumption. That is, the attacker assumes that the known location is the same as the known location that was previously acquired. The question of how much information the attacker gains when making this assumption is a matter for the analysis of the algorithm.

Incidentally, there's another assumption that's important in analyzing the algorithm that I proposed:

Discrete location assumption:
An algorithm SHOULD protect a discrete location that is remote from adjacent known locations. This assumption might be useful to an adversary if the location of the Target is known only at discrete points without known locations in between. For example, a person that disables location tracking in transit between two points might only have known locations at either end of the journey.

> > That's a more verbose version of what I intended with the second
> > paragraph. What you have described is something that is part of the
> > solution space more than the goals. I considered having an
> > additional assumption for indistinguishable locations, but it's not
> > really related to an assumption that an recipient makes, more just a
> > product of the algorithm.
>
> And this last part is the requirement. It is not solution space, it
> just says that the attacker should gain as little as possible
> information from the outputs of the algorithm.

Goal. Let us not place constraints that we cannot provably meet.

> -Jorge

As an aside, in relation to this work, I've been acutely aware of the effect of "Schneier's Law": <http://www.schneier.com/crypto-gram-1104.html#10>.

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] geopriv-policy algorithm constraints and goals

> > Thanks Martin for the input. I would add to stationary and frequent
> > destination:
> >
> > > Stationary assumption: An algorithm SHOULD obscure the location of a
> > > stationary target. More specifically, when a target does not move, a
> > > location recipient should be unable to determine the known location
> > > using only the reported locations that are output from the algorithm.
> > In particular, the algorithm SHOULD obscure the location even if the
> > attacker knows the details of the protocol and is able to simulate it.
>
> That's a more general constraint. As a general rule, security by
> obscurity doesn't work. I don't see that this is any different.

I think, it only makes explicit something that is
already included.

> If you think that the text is useful, I'd add it as a later note.

I think it is useful. What would be a "later" note?

> > And also I would add a new assumption:
> >
> > Indistinguishability assumption:
> >
> > We call two points "indistinguishable as locations" for an algorithm,
> > if an attacker can not infer from the outputs of the algorithm any
> > information about which of the two points is the location of a static
> > target. In particular, if the algorithm provides the same response for
> > two locations, those locations are indistinguishable. Similarly two
> > points are called "indistinguishable as destinations" if an attacker
> > can not infer from the outputs of the algorithm any information about
> > which of the two points was the destination of a moving target. This
> > is true in particular, if every path that ends in one of the two
> > points can be extended to a path ending on the other point, without
> > changing the outputs of the algorithm.
> >
> > Two points are in the same indistinguishability region if and only if
> > they are indistinguishable as locations and destinations. An algorithm
> > SHOULD provide a description of the indistinguishability regions it
> > defines. A theoretical analysis of the size and shape of the
> > indistinguishability regions of the algorithm is desirable.

Up to jere it is only a definition: any protocol defines an
indistinguishability region, there is no way to avoid it.
(But perhaps, it is not trivial to calculate what is the
indistinguishability region for a given algorithm). It is
close to well known notions of indistinguishability, like
http://en.wikipedia.org/wiki/Ciphertext_indistinguishability
or, even more, the one used in information flow, see for instance:
http://www.cse.chalmers.se/~andrei/jsac.pdf
So this is not solution space.

> That's a more verbose version of what I intended with the second
> paragraph. What you have described is something that is part of
> the solution space more than the goals. I considered having an
> additional assumption for indistinguishable locations, but it's
> not really related to an assumption that an recipient makes, more
> just a product of the algorithm.

And this last part is the requirement. It is not solution
space, it just says that the attacker should gain as little
as possible information from the outputs of the algorithm.

-Jorge
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] FYI: got geoint? » Article » Creepy: Stalker’s Dream App Allows Tracking of Anyone’s Location

http://www.gotgeoint.com/archives/creepy-stalkers-dream-app-allows-tracking-of-anyones-location/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+GotGeoint+%28got+geoint%3F%29

 

If anyone ever doubts the relevance of this WG's effort!

 

Carl Reed, PhD
CTO and Executive Director Specification Program
Open Geospatial Consortium
www.opengeospatial.org

 

The OGC: Making Location Count!

 

---------------------

 

This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender  immediately by return email and delete this communication and destroy all copies.

 

"The important thing is not to stop questioning." -- Albert Einstein
"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller

Re: [Geopriv] geopriv-policy algorithm constraints and goals

On 2011-04-15 at 05:34:02, Jorge Cuellar wrote:
> Thanks Martin for the input. I would add to stationary and frequent
> destination:
>
> > Stationary assumption: An algorithm SHOULD obscure the location of a
> > stationary target. More specifically, when a target does not move, a
> > location recipient should be unable to determine the known location
> > using only the reported locations that are output from the algorithm.
> In particular, the algorithm SHOULD obscure the location even if the
> attacker knows the details of the protocol and is able to simulate it.

That's a more general constraint. As a general rule, security by obscurity doesn't work. I don't see that this is any different.

If you think that the text is useful, I'd add it as a later note.

> > Frequent destination assumption: An algorithm SHOULD obscure the
> > details of a frequently visited location or path. For a destination
> > that is regularly visited, the algorithm cannot provide the precise
> > location of the frequented location.
>
> > Any description SHOULD indicate whether the algorithm prevents a
> > recipient from identifying whether different reported locations
> > correspond to the same known location, and under what circumstances.
> In particular if the attacker knows the details of the protocol and is
> able to simulate it.
>
> And also I would add a new assumption:
>
> Indistinguishability assumption:
>
> We call two points "indistinguishable as locations" for an algorithm,
> if an attacker can not infer from the outputs of the algorithm any
> information about which of the two points is the location of a static
> target. In particular, if the algorithm provides the same response for
> two locations, those locations are indistinguishable. Similarly two
> points are called "indistinguishable as destinations" if an attacker
> can not infer from the outputs of the algorithm any information about
> which of the two points was the destination of a moving target. This
> is true in particular, if every path that ends in one of the two
> points can be extended to a path ending on the other point, without
> changing the outputs of the algorithm.
>
> Two points are in the same indistinguishability region if and only if
> they are indistinguishable as locations and destinations. An algorithm
> SHOULD provide a description of the indistinguishability regions it
> defines. A theoretical analysis of the size and shape of the
> indistinguishability regions of the algorithm is desirable.

That's a more verbose version of what I intended with the second paragraph. What you have described is something that is part of the solution space more than the goals. I considered having an additional assumption for indistinguishable locations, but it's not really related to an assumption that an recipient makes, more just a product of the algorithm.

>
> -- Jorge
>
> On Tue, Apr 12, 2011 at 3:23 AM, Thomson, Martin
> <Martin.Thomson@commscope.com> wrote:
> > With the idea that we want -geopriv-policy finished sometime this
> millennium, here's my first, rough attempt at describing constraints
> and goals for location obscuring.
> >
> > I'd sorely like to add additional goals that rely on topology,
> routing, or behavioral information.  But, I'm afraid that we'll never
> get an algorithm deployed based on something that complex.  All
> current indications are that such a method is necessary, but more
> research is necessary before anything concrete could be proposed.
> >
> > --Martin
> >
> > ----
> >
> > The purpose of a location obscuring algorithm is to provide a
> location recipient (LR) with location information of reduced quality.
>  The intent is to provide an LR with location information that is
> correct, but insufficient to identify the known location without a
> chosen amount of uncertainty.
> >
> > The obscuring algorithm takes a series of _known locations_, which
> might have greater accuracy than the recipient is permitted to receive.
>  The obscuring process produces a series of _reported locations_.
> >
> > Algorithm Constraints
> >
> > Each algorithm MUST be assigned a label.  This label is used to
> identify the algorithm.  Algorithm labels are added to the location
> obscuring algorithm registry (see Section x.x).
> >
> > The algorithm MUST accept known locations with uncertainty and
> produce reported locations with uncertainty that encloses the known
> location at that time.  That is, the reported location is no less
> correct than the known location.
> >
> > Any obscuring algorithm MUST accept a single input parameter of a
> distance in meters.  Any other tuning parameters for the algorithm
> MUST be fixed in the definition of the algorithm.
> >
> > Algorithm Goals
> >
> > In assessing any algorithm, the information that a recipient can
> recover determines how effective that algorithm is.  When a recipient
> (or adversary) makes assumptions [Duckham05] about the movement of the
> target, they may be able to recover more information than is intended.
> >
> > The assumptions that a recipient is forced to make to recover
> information determines how effective an algorithm is.  The more
> assumptions that are necessary, the more difficult it is to reliably
> recover the known location.  While it cannot be assumed that the
> complexity of applying multiple assumptions would prevent a recipient
> from applying those assumptions, the probability that a given set of
> assumptions is incorrect increases with number.
> >
> > The following assumptions are considered important for the
> development of an algorithm that obscures location.  These assumptions
> are considered to have a high probability of being correct and are
> therefore the most important assumptions to protect against.
> >
> > Stationary assumption:
> >        An algorithm SHOULD obscure the location of a stationary
> target.  More specifically, when a target does not move, a location
> recipient should be unable to determine the known location using only
> the reported locations that are output from the algorithm.
> >
> > Continuous movement assumption:
> >        An algorithm SHOULD obscure the location of a moving target.
>  More specifically, when a target moves, a location recipient should
> be unable to determine the known location of the target at any point
> in time using only the reported locations that are output from the
> algorithm.
> >
> > Frequent destination assumption:
> >        An algorithm SHOULD obscure the details of a frequently
> visited location or path.  For a destination that is regularly
> visited, the algorithm cannot provide the precise location of the
> frequented location.
> >
> >        Any description SHOULD indicate whether the algorithm
> > prevents
> a recipient from identifying whether different reported locations
> correspond to the same known location, and under what circumstances.
>  This would permit a recipient to learn that the same location is
> being visited, even if the identity of that location is obscured.
> >
> > High accuracy assumption:
> >        An algorithm SHOULD obscure location when the known location
> has low uncertainty or a high frequency update rate.  A theoretical
> analysis of the algorithm based on a continuous series of perfect
> known locations is desirable.
> >
> > An algorithm may also provide protection for the speed or velocity
> > of
> a target.  It is desirable that the precise speed of a target cannot
> be easily learned.  The following assumptions are also important in
> assessing an algorithm:
> >
> > Constant velocity assumption:
> >        An algorithm SHOULD obscure the speed of a target under the
> assumption of constant velocity or constant speed along a predefined
> path (such as a road).
> >
> > Other assumptions that a location recipient might use to improve
> their ability to recover a known location might include: upper and
> lower bounds to speed or acceleration, constrained movement along
> specific thoroughfares, or inability to be located in areas that are
> designated inaccessible.
> >
> > Discussion of any additional assumptions that are either rendered
> ineffective or especially effective is useful in evaluating an
> algorithm.
> >
> > _______________________________________________
> > 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