All,
This is the current list of issues identified in the draft
<draft-ietf-geopriv-reqs-01.txt>.
The goal of this list is to identify the changes required to further
advance this document. Please submit comments to the presented issues,
or send more issues to the mailing list. Please refer to the text in
the draft that relates to the issue. If possible, supply also the
suggested text that you would like to see.
Regards,
Jorge
################################################
Current Issues:
Nov 18, 2002
Issue 8b: "Accuracy flag": Closed
It is not useful to provide an accuracy attribute in
object, i.e., a flag saying "I'm not telling you the whole
truth."
But: if the LO is used for requesting a position, an
accuracy level may be requested.
This is an open *protocol issue*: outside of the scope of
this document.
Issue 13: "LO fields": a) Closed
What are the contents (fields/attributes) of the LO?
(This is a "MUST implement", not all location objects
have to contain all fields)
1 Target Identifier
2 Location Recipient Identity
May be multicast or group identity
3 Location Recipient Credential
4 Proof-of-Possession of the Credential
5 (One or more*) Location Field(s) each containing one or
more Location Representations, which can be in different
formats.
*Issue 15: Out of scope: For privacy reasons, there is
no need for multiple locations
6 Location Data Type
Formats for both lat/long/altitude and "civil" locations
7 Motion and direction vectors
8 Timing information:
a When was the LI accurate? (sighting time)
b Until when considered current? TTL (Time-to-live)
9 Policy Field (See also Issue 17)
MAY be a pointer, e.g. an URI, to a full policy
or it MAY contain a Limited Policy
or both
10 Security-headers and -trailers, e.g. encryption
information, hashes, or signatures
11 Version number
Issue 17: "(Limited) Policy Language" = "Core Set": Closed
Do we want to define a simple policy language?
Yes, but it may be very simple, say "delete-by date"
In the Draft: replace the text:
"The LO should be able to carry a limited but core set of
privacy policies. This core set is defined below and
discussed more extensively in a separate document. Beyond
the core set of privacy policies, the user or Rule Maker
should be able to define a more robust and complex set of
policies. "
By:
"The LO should be able to carry a limited but core set of
privacy policies. The exact form or expressiveness of
policies in the core set or in the full set is not further
discussed in this paper, but is discussed more extensively
in a separate document."
Issue 15: " Multiple locations issue": Out of scope
Is it necessary for the geopriv object(s) to be able to
carry multiple locations for the target?
Out of scope: For privacy reasons, there is no need for
multiple locations
Issue 16: "Full integrity issue": Closed
Is there a provision in the protocol to prohibit the users
to send false location information?
SHOULD the protocol support transformations that introduce
errors?
Both: No. There are no such requirements. For more
discussion, see
"draft-morris-geopriv-location-object-issues-00.txt"
Issue 18, 19: "Generic policies" (used by LoSi)
Location Sighters (LoSi) and Ultimate Location Recipient
(ULR) need in general no full rule-maker defined policies?
Req. 7. (LoSi Policies) Even if a Location Sighter is
unaware of and lacks access to the full Privacy Policies
defined by the Rule Maker, the Location Sighter MUST
transmit Location Information in compliance with
instructions set by the Rule Maker. Such compliance MAY be
accomplished by the Location Sighter transmitting LI only
to a URI designated by the Rule Maker.
Issue 18, 19: "Generic policies" (used by ULR)
Location Sighters (LoSi) and Ultimate Location Recipient
(ULR) need in general no full rule-maker defined policies?
Req. 8. (ULR Policies) An Ultimate Location Recipient does
not need to be aware of the full policies defined by the
Rule Maker (because an ULR SHOULD NOT retransmit Location
Information), and thus an ULR SHOULD receive only the
subset of Privacy Policies necessary for the ULR to handle
the LI in compliance with the full Privacy Policies (such
as, for example, an instruction on the time period for
which then LI can be retained).
Issue 20: "Who defines the Identities (Identity Management Issue)"
Out of scope, see draft Section 9.7
May the using protocol define the Identifiers or must the
using protocol use and authenticate Pseudonyms proposed by
the policies, chosen independently of the using protocol?
Of course, if the using protocol has an appropriate
namespace, containing many unused names that may be used as
pseudonyms and may be replaced by new ones regularly, then
the Location Object may be able to use the name space. For
this purpose, the user would probably have to write his
policies using this name space. Note that it is necessary
to change the used pseudonyms regularly, because
identifying the user behind an unlinked pseudonym can be
very simple.
Issues 21, 22: "Group or role identifiers": Out of scope
Will the protocol support Role identifiers (like
"administrator", "member-of-club-A", etc.) Also with
context dependent meaning?
Identities may be used to represent groups or multicast,
but this is outside of our scope. Nevertheless, group or
role identifiers are probably not somehow explicitly
supported (at least in V1)
Issue 23: "Disallow anonymous location-requests": Closed
Need requirement:
if location recipients decline revealing their identity,
==> this must be a designated type of identity,
allowing the policy to prohibit anonymous location-getting.
This is not a requirement
Issue 24 b): "Law enforcement issue": Closed
Law enforcement policies are not under user-control
Issue 25: "Emergency Call Authentication": a) Closed
Req. 14.3) The protocol SHOULD allow a bypass if
authentication fails in an emergency call.
The issue addressed in the last point is that an emergency
call in some very unfavorable situations my not be
completed if the minimal authentication fails. This is
probably not what the user would like to see. The user may
prefer an unauthenticated call to an unauthenticated
emergency server than no call completion at all, even at
the risk that he is talking to an attacker or that his
information is not secured.
Issue 25: "Emergency Call Authentication": b) Open
Making an emergency call on a VoIP phone that is not
"logged in". In the mobile world, you have to be able to
make a call to emergency services even if the phone is not
authorized (i.e. it has no service agreement). Problem: if
the user may not authenticate itself, whose policy to use?
A default one: this loc information can only be sent to an
emergency center. Problem: it also the emergency center is
not authenticable?
Issue 26: " Security Features": closed
Req. 13. The LO MUST support fields suitable for protecting
the Object to provide the following security features:
Mutual end-point authentication
Data object integrity
Data object confidentiality
Replay protection
Issue 27 ("Single Packet Exchange"): Out of scope
Tracking a small object has several implications:
1. small device
2. delta format
3. The "geopriv protocol" needs to be at most a single
packet exchange. The first transaction in a tracking
application could be more than this, but we need a low
overhead mechanism for incremental update
Only 2 is now a requirement, but all should be possible.
Issue 28 (Multicast Issue): Closed
Include the location object in multicast-based using
protocols.
Yes
Issue 29 (new): "Full Policy": Out of scope
Do we want to define a full policy language?
Perhaps.
Note: It is outside of our scope how Privacy Policies are
managed, how a Location Server has access to the Privacy
Policies, and if he is or not aware of the full set of
rules desired by the Rule-Maker. Note that it might be that
some rules contain private information not intended for
untrusted parties.
Issue 14: "Implementation of a Location Format": Closed
Location Data Formats?
The embedded protocol MUST define data type format for
location data that must be supported by all geopriv
receivers.
But not all geopriv LOs have to contain data in this
format.
Key questions:
Open issues that are not *protocol* open issues
Any requirements missing from draft?
Ready for WGLC?
______________________________________________________________________________
Nutzen Sie Ihre Zeit fur wirklich wichtige Dinge! Alle E-Mail-Adressen
zentral verwalten unter: http://freemail.web.de/features/?mc=021121
Received on Mon Nov 18 15:48:33 2002
This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:23 EST