GeoPriv R. Marshall, Ed.
Internet-Draft TCS
Intended status: Informational February 26, 2009
Expires: August 30, 2009
Requirements for a Location-by-Reference Mechanism
draft-ietf-geopriv-lbyr-requirements-07
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Marshall Expires August 30, 2009 [Page 1]
Internet-Draft GEOPRIV LbyR Requirements February 2009
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Marshall Expires August 30, 2009 [Page 2]
Internet-Draft GEOPRIV LbyR Requirements February 2009
Abstract
This document defines terminology and provides requirements relating
to Location-by-Reference approach using a location URI to handle
location information within signaling and other Internet messaging.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Overview of Location-by-Reference . . . . . . . . . . . . . . 8
3.1. Location URI Usage . . . . . . . . . . . . . . . . . . . . 9
3.2. Location URI Expiration . . . . . . . . . . . . . . . . . 9
3.3. Location URI Authorization . . . . . . . . . . . . . . . . 10
3.4. Location URI Construction . . . . . . . . . . . . . . . . 10
4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 12
4.1. Requirements for a Location Configuration Protocol . . . . 12
4.2. Requirements for a Location Dereference Protocol . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Marshall Expires August 30, 2009 [Page 3]
Internet-Draft GEOPRIV LbyR Requirements February 2009
1. Introduction
All location-based services rely on ready access to location
information. Using location information can be done one of two ways,
either in a direct, Location-by-Value (LbyV) approach, or using an
indirect, Location-by-Reference (LbyR) model.
For LbyV, location information is conveyed directly in the form of a
PIDF-LO ([RFC4119]). Using LbyV might either be infeasible or
undesirable in some circumstances. There are cases where LbyR is
better able to address location requirements for a specific
architecture or application. This document provides a list of
requirements for use with the LbyR approach, and leaves the LbyV
model explicitly out of scope.
As justification for a LbyR model, consider the circumstance that in
some mobile networks it is not efficient for the end host to
periodically query the LIS for up-to-date location information. This
is especially the case when power availability is a constraint or
when a location update is not immediately needed. Furthermore, the
end host might want to delegate the task of retrieving and publishing
location information to a third party, such as to a presence server.
Additionally, in some deployments, the network operator may not want
to make location information widely available. These kinds of
location scenarios provided, and others, such as whether a Target is
mobile and whether a mobile device needs to be located on demand or
according to some pre-determined interval, together, form the basis
of motivation for the LbyR model.
The concept of an LbyR mechanism is simple. It is made up of a
reference identifier which indirectly references actual location
information using some combination of key value and fully qualified
domain name. This combination of data elements, in the form of a
URI, is referred to specifically as a "location URI".
A location URI is thought of as a dynamic reference to the current
location of the Target, yet the location value might remain unchanged
over specific intervals of time for several reasons. These include:
- Limitations in the process used to generate location information
mean that cached location might be used.
- Policy constraints that may dictate that the location provided
remains fixed over time for specified Location Recipients. Without
additional information, a Location Recipient cannot assume that the
location information provided by any location URI is static, and will
never change.
Marshall Expires August 30, 2009 [Page 4]
Internet-Draft GEOPRIV LbyR Requirements February 2009
The LbyR mechanism works according to an information lifecycle.
Within this lifecycle, location URIs are considered temporary
identifiers, each undergoing the following uses: Creation;
Distribution; Conveyance; Dereference; and Termination. The use of a
location URI according to these various states is generally applied
in one of the following ways:
1. Creation of a location URI, within a location server, based on
some request for its creation.
2. Distribution of a location URI, via a Location Configuration
Protocol, between a target and a location server.
3. Conveyance, applied to LbyR, in SIP, is the transporting of the
location URI, in this case, between any successive signaling nodes.
4. Dereference of a location URI, a request/response between a
client having a location URI and a location server holding the
location information that the location URI references.
5. Termination of a location URI, either due to expiration or
cancellation within a location server, and which is based on a target
cancellation request or some other action, such as timer
expiration.
Note that this document makes no differentiation between a LS, per
[RFC3693], and a LIS, as shown in [I-D.ietf-geopriv-l7-lcp-ps]), but
may refer to either of them as a location server interchangeably.
Location determination, different than location configuration or
dereferencing, often includes topics related to manual provisioning
processes, automated location calculations based on a variety of
measurement techniques, and/or location transformations, (e.g., geo-
coding), and is beyond the scope of this document.
Location Conveyance for either LbyR or LbyV as defined within SIP
signaling is considered out of scope for this document (see
[I-D.ietf-sip-location-conveyance] for an explanation of location
conveyance for either LbyR or LbyV scenarios.)
Except for location conveyance, the above stages in the LbyR
lifecycle fall into one of two general categories of protocols,
either a Location Configuration Protocol or a Location Dereference
Protocol. The stages of LbyR Creation, Distribution, and
Termination, are each found within the set of Location Configuration
Protocols (LCP). The Dereference stage belongs solely to the set of
Location Dereference Protocols.
Marshall Expires August 30, 2009 [Page 5]
Internet-Draft GEOPRIV LbyR Requirements February 2009
The issues around location configuration protocols have been
documented in a location configuration protocol problem statement and
requirements document [I-D.ietf-geopriv-l7-lcp-ps]. There are
currently several examples of a location configuration protocols
currently proposed, including, DHCP
[I-D.ietf-geopriv-dhcp-lbyr-uri-option], LLDP-MED, and HELD
[I-D.ietf-geopriv-http-location-delivery] protocols.
For dereferencing of a location URI, depending on the type of
reference used, such as a HTTP/HTTPS, or SIP Presence URI, different
operations can be performed. While an HTTP/HTTPS URI can be resolved
to location information, a SIP Presence URI provides further benefits
from the SUBSCRIBE/NOTIFY concept that can additionally be combined
with location filters [I-D.ietf-geopriv-loc-filters].
The structure of this document includes terminology, Section 2,
followed by a discussion of the basic elements that surround how a
location URI is used. These elements, or actors, are discussed in an
overview section, Section 3, accompanied by a graph, associated
processing steps, and a brief discussion around the use, expiration,
authorization, and construction of location URIs.
Requirements are outlined accordingly, separated as location
configuration requirements, Section 4.1, and location dereference
requirements, Section 4.2.
Marshall Expires August 30, 2009 [Page 6]
Internet-Draft GEOPRIV LbyR Requirements February 2009
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This document reuses the terminology of [RFC3693], such as Location
Server (LS), Location Recipient (LR), Rule Maker (RM), Target,
Location Generator (LG), Location Object (LO), and Using Protocol:
Location-by-Value (LbyV): Using location information in the form of
a location object (LO), such as a PIDF-LO.
Location-by-Reference (LbyR): Representing location information
indirectly using a location URI.
Location Configuration Protocol: A protocol which is used by a
client to acquire either location or a location URI from a
location configuration server, based on information unique to the
client.
Location Dereference Protocol: A protocol that is used by a client
to query a location server, based on the location URI input and
which returns location information.
Location URI: As defined within this document, an identifier that
serves as a reference to location information. A location URI is
provided by a location server, and is later used as input by a
dereference protocol to retrieve location information.
Marshall Expires August 30, 2009 [Page 7]
Internet-Draft GEOPRIV LbyR Requirements February 2009
3. Overview of Location-by-Reference
This section describes the entities and interactions involved in the
LbyR model.
+---------+---------+ Location +-----------+
| | | Dereference | Location |
| LIS - LS +---------------+ Recipient |
| | | Protocol | |
+----+----+----+----+ (3) +-----+-----+
| * |
| Policy * |
Location | Exchange * |
Configuration | (*) * | Location
Protocol | +----+----+ | Conveyance
(1) | | Rule | | Protocol
| | Maker | | (2)
+----+----+ +---------+ |
| | |
| Target +-------------------------------+
| |
+---------+
Figure 1: Location Reference Entities and Interactions
Figure 1 shows the assumed communication model for both a layer 7
location configuration protocol and a location dereference protocol.
1. The Target (a Device) uses a Location Configuration Protocol to
acquire a location reference from a LIS, which acts as (or is able to
access) an LS.
In the case where the Target is also a Rule Maker, the location
configuration protocol can be used to convey policy information. In
the case where possession of a location URI is the only required form
of authorization, (see, Section 3.3), a policy is implied whereby any
requester is granted access to location information. This does not
preclude other means of providing authorization policies.
A Target could also acquire a location URI from the LS directly using
alternative means, for example, the acquisition of a presence AoR to
be used for location information, in which case, it could be regarded
as a location URI.
Marshall Expires August 30, 2009 [Page 8]
Internet-Draft GEOPRIV LbyR Requirements February 2009
2. The Target conveys the location URI to the Location Recipient
(interface out of scope).
3. The Location Recipient dereferences the location URI to acquire
location information from the LS.
The LS controls access to location information based on the policy
provided by the Rule Maker.
Note A. There is no requirement for using the same protocol in (1)
and (3).
Note B. Figure 1 includes the interaction between the owner of the
Target and the LIS to obtain Rule Maker policies. This interaction
needs to happen before the LIS will authorize anything other than
what is allowed based on default policies in order to dereference a
location request of the Target. This communication path is out of
scope for this document.
Note C. The Target might take on the role of the Location Recipient,
in which case it could attempt to dereference the location URI
itself, in order to obtain its own location information.
3.1. Location URI Usage
An example scenario of how the above might work, is where the Target
obtains a location URI in the form of a subscription URI (e.g., a SIP
URI) via a location configuration protocol. In this case, the Target
is the same as the Recipient, therefore the Target can subscribe to
the URI in order to be notified of its current location based on
subscription parameters. In the example, parameters are set up for a
specific Target/Recipient along with an expressed geospatial
boundary, so that the Target/Recipient receives an updated location
notification once the boundary is crossed (see
[I-D.ietf-geopriv-loc-filters]).
3.2. Location URI Expiration
Location URIs may have an expiry associated with them, primarily for
security considerations, and generally so that the LIS is able to
keep track of the location URIs that have been handed out, to know
whether a location URI is still valid once the LIS receives it in a
request, and in order for a recipient of such a URI from being able
to (in some cases) permanently track a host. Expiration of a
location URI limits the time that accidental leaking of a location
URI introduces. Other justifications for expiration of location URIs
include the ability for a LIS to do garbage collection.
Marshall Expires August 30, 2009 [Page 9]
Internet-Draft GEOPRIV LbyR Requirements February 2009
3.3. Location URI Authorization
How a location URI is will ultimately be used within the dereference
step is an important consideration at the time that the location URI
is requested via a location configuration protocol. Since
dereferencing of location URIs can be done according to a variety of
authorization models it is important that location configuration
protocols indicate the type of a location URI that is being
requested, as well as which type is returned.
Location URIs manifest themselves in a few different forms. The
different ways that a location URI can be represented is based on
local policy, and are depicted in the following four scenarios.
1. No specific information at all: As is typical, a location URI is
used to get location information. However, in this case, the URI
representation itself does not need to reveal any specific
information at all. Location information is acquired by the
dereferencing operation a location URI.
2. No user specific information: By default, a location URI MUST NOT
reveal any information about the Target other than location
information. This is true for the URI itself, (or in the document
acquired by dereferencing), unless policy explicitly permits
otherwise.
3. Access control authorization model (unauthorized recipients can't
get the information): If the "access control authorization" model is
used, the location URI MUST NOT include any location information
in its representation. Location URIs operating under this model
could be widely published to recipients that are not authorized to
receive this information.
4. Possession authorization model (the URI itself is a secret): If
the "possession authorization" model is used, the location URI is
confidential information shared between the LIS/LS, the Device and
all authorized Location Recipients. In this case, possession
implies authorization. Because knowledge of the location URI is
used to authenticate and authorize access to location information,
the URI needs to include sufficient randomness to make guessing
its value difficult. A possession model URI can include location
information in its representation.
3.4. Location URI Construction
Depending on local policy, a location URI may be constructed in such
a way as to make it difficult to guess. Accordingly, the form of the
URI is then constrained by the degree of randomness and uniqueness
Marshall Expires August 30, 2009 [Page 10]
Internet-Draft GEOPRIV LbyR Requirements February 2009
applied to it. In this case, it may be important to protect the
actual location information from inspection by an intermediate node.
Construction of a location URI in such a way as to not reveal any
domain, user, or device specific information, with the goal of making
the location URI appear bland, uninteresting, and generic, may be
helpful to some degree in order to keep location information more
difficult to detect. Thus, obfuscating the location URI in this way
may provide some level of safeguard against the undetected stripping
off of what would otherwise be evident location information, since it
forces a dereference operation at the location dereference server, an
important step for the purpose of providing statistics, audit trails,
and general logging for many different kinds of location based
services.
Marshall Expires August 30, 2009 [Page 11]
Internet-Draft GEOPRIV LbyR Requirements February 2009
4. High-Level Requirements
This document outlines the requirements for an Location by Reference
mechanism which can be used by a number of underlying protocols.
Requirements here address two general types of such protocols, a
general location configuration protocol, and a general location
dereferencing protocol.
The requirements are broken into two sections.
4.1. Requirements for a Location Configuration Protocol
Below, we summarize high-level design requirements needed for a
location-by-reference mechanism as used within the location
configuration protocol.
C1. Location URI support: The location configuration protocol MUST
support a location reference in URI form.
Motivation: A standardized location reference mechanism increases
interoperability.
C2. Location URI expiration: When a location URI has a limited
validity interval, its lifetime MUST be indicated.
Motivation: A location URI may not intend to represent a location
forever, and the identifier eventually may need to be recycled, or
may be subject to a specific window of validity, after which the
location reference fails to yield a location, or the location is
determined to be kept confidential.
C3. Location URI cancellation: The location configuration protocol
MUST support the ability to request a cancellation of a specific
location URI.
Motivation: If the client determines that in its best interest to
destroy the ability for a location URI to effectively be used to
dereference a location, then there should be a way to nullify the
location URI.
C4. Location Information Masking: The location URI MUST, through
randomization and uniqueness, ensure that the location URI does
not contain location information specific components.
Motivation: It is important to keep any location information
masked from a casual observing node.
Marshall Expires August 30, 2009 [Page 12]
Internet-Draft GEOPRIV LbyR Requirements February 2009
C5. User Identity Protection: The location URI MUST NOT contain
information that identifies the user or device. Examples include
phone extensions, badge numbers, first or last names.
Motivation: It is important to protect caller identity or contact
address from being included in the form of the location URI itself
when it is generated.
C6. Reuse indicator: There SHOULD be a way to allow a client to
control whether a location URI can be resolved once only, or
multiple times.
Motivation: The client requesting a location URI may request a
location URI which has a 'one-time-use' only characteristic, as
opposed to a location URI having multiple reuse capability.
C7. Selective disclosure: The location configuration protocol MUST
provide a mechanism to control what information is being disclosed
about the Target.
Motivation: The Rule Maker has to be in control of how much
information is revealed during the dereferencing step as part of
the privacy features.
C8. Location URI Not guessable: As a default, the location
configuration protocol MUST return location URIs that are random
and unique throughout the indicated lifetime. A location URI with
128-bits of randomness is RECOMMENDED.
Motivation: Location URIs should be constructed in such a way that
an adversary cannot guess them and dereference them without having
ever obtained them from the Target.
C9. Location URI Optional: In the case of user-provided
authorization policies, where anonymous or non-guessable location
URIs are not warranted, the location configuration protocol MAY
support optional location URI forms, (such as embedded location
information within the location URI).
Motivation: Users don't always have such strict privacy
requirements, but may opt to specify their own location URI, or
components thereof.
4.2. Requirements for a Location Dereference Protocol
Below, we summarize high-level design requirements needed for a
location-by-reference mechanism as used within the location
dereference protocol.
Marshall Expires August 30, 2009 [Page 13]
Internet-Draft GEOPRIV LbyR Requirements February 2009
D1. Location URI support: The location dereference protocol MUST
support a location reference in URI form.
Motivation: It is required that there be consistency of use
between location URI formats used in an configuration protocol and
those used by a dereference protocol.
D2. Authentication: The location dereference protocol MUST include
mechanisms to authenticate both the client and the server.
Motivation: Although the implementations must support
authentication of both parties, any given transaction has the
option not to authenticate one or both parties.
D3. Dereferenced Location Form: The value returned by the
dereference protocol MUST contain a well-formed PIDF-LO document.
Motivation: This is in order to ensure that adequate privacy rules
can be adhered to, since the PIDF-LO format comprises the
necessary structures to maintain location privacy.
D4. Location URI Repeated Use: The location dereference protocol
MUST support the ability for the same location URI to be resolved
more than once, based on dereference server configuration.
Motivation: Through dereference server configuration, for example,
it may be useful to not only allow more than one dereference
request, but, in some cases, to also limit the number of
dereferencing attempts by a client.
D5. Location Confidentiality: The location dereference protocol MUST
support confidentiality protection of messages sent between the
Location Recipient and the location server.
Motivation: The location URI indicates what type of security
protocol has to be provided. An example is a location URI using a
HTTPS URI scheme.
Marshall Expires August 30, 2009 [Page 14]
Internet-Draft GEOPRIV LbyR Requirements February 2009
5. Security Considerations
The method of constructing the location URI to include randomized
components helps to prevent adversaries from obtaining location
information without ever retrieving a location URI. In the
possession model, a location URI, regardless of its construction, if
made publically available, implies no safeguard against anyone being
able to dereference and get the location. Care has to be paid when
distribution such a location URI to the trusted location recipients.
When this aspect is of concern then the authorization model has to be
chosen. Even in this model care has to be taken on how to construct
the authorization policies to ensure that only those parties have
access to location information that are considered trustworthy enough
to enforce the basic rule set that is attached to location
information in a PIDF-LO document.
Any location URI, by necessity, indicates the server (name) that
hosts the location information. Knowledge of the server in some
specific domain could therefore reveal something about the location
of the Target. This kind of threat may be mitigated somewhat by
introducing another layer of indirection: namely the use of a
(remote) presence server.
Marshall Expires August 30, 2009 [Page 15]
Internet-Draft GEOPRIV LbyR Requirements February 2009
6. IANA Considerations
This document does not require actions by the IANA.
Marshall Expires August 30, 2009 [Page 16]
Internet-Draft GEOPRIV LbyR Requirements February 2009
7. Acknowledgements
I would like to thank the present IETF GEOPRIV working group chairs,
Robert Sparks and Richard Barnes, past chairs, Andy Newton, Allison
Mankin and Randall Gellens, for establishing the design team which
initiated this requirements work. I'd also like to thank those
original design team participants for their inputs, comments, and
insightful reviews. The design team included the following folks:
Richard Barnes; Martin Dawson; Keith Drage; Randall Gellens; Ted
Hardie; Cullen Jennings; Marc Linsner; Rohan Mahy; Allison Mankin;
Roger Marshall; Andrew Newton; Jon Peterson; James M. Polk; Brian
Rosen; John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes
Tschofenig; Martin Thomson; and James Winterbottom.
Marshall Expires August 30, 2009 [Page 17]
Internet-Draft GEOPRIV LbyR Requirements February 2009
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.ietf-geopriv-dhcp-lbyr-uri-option]
Polk, J., "Dynamic Host Configuration Protocol (DHCP)
Option for a Location Uniform Resource Identifier (URI)",
draft-ietf-geopriv-dhcp-lbyr-uri-option-03 (work in
progress), November 2008.
[I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-13 (work in
progress), February 2009.
[I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-09 (work in
progress), February 2009.
[I-D.ietf-geopriv-loc-filters]
Mahy, R. and B. Rosen, "A Document Format for Filtering
and Reporting Location Notications in the Presence
Information Document Format Location Object (PIDF-LO)",
draft-ietf-geopriv-loc-filters-03 (work in progress),
November 2008.
[I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol",
draft-ietf-sip-location-conveyance-12 (work in progress),
November 2008.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
Marshall Expires August 30, 2009 [Page 18]
Internet-Draft GEOPRIV LbyR Requirements February 2009
Appendix A. Change log
Changes to this draft in comparison to the previous version (-07 vs.
-06):
1. deleted text and reference to ID.ietf-geopriv-policy (Thomson
2/26/09).
2. replaced text in Introduction referring to SIP (Thomson).
3. reworded section 3.4 on location URI authorization (Thomson).
Changes to this draft in comparison to the previous version (-06 vs.
-05):
1. replaced diagram (Thomson).
2. redefined term, "Location-by-Value" (1/08/2009, Tschofenig).
3. redefined term, "Location-by-Reference" (Tschofenig).
4. redefined term, "Location Dereference Protocol" (Tschofenig).
5. reworded term, "Location URI" (Tschofenig).
6. modified steps, text, Figure 1 (Tschofenig).
7. deleted redundant text in paragraph, "Because a location URI..."
(Tschofenig).
8. modified Authorization model text paragraphs, (Tschofenig).
9. added qualifying sentence before sentence, "Thus, obfuscating the
location URI..." (Marshall based on question from Tschofenig).
10. replaced diagram with one that contains both "LIS - LS" labeling
(Martin).
11. added text to Introduction that a location URI is dynamic and may
change over time (Martin, 2/23/09).
12. section 3 text changed to make the makeup of a location URI less
stringent as to being guessable, etc. (Martin, 2/23/09).
13. reordered "C" requirements from those remaining: C8-->C7;
C9-->C8; C10-->C9.
14. reordered "D" requirements: D3-->D2; D4-->D3; D5-->D4; D10-->D5.
Marshall Expires August 30, 2009 [Page 19]
Internet-Draft GEOPRIV LbyR Requirements February 2009
15. section-ized the overview, (section 3), for pointing to (Martin,
2/23/09)
16. edited section 3.4 to make clear that some default requirements
may be relaxed ONLY if explicit local policy exists. (RSM based on
Martin, 2/23/09).
17. added an citation for the geopriv-policy draft reference.
18. reworded first couple of paragraphs of Introduction for
readability.
Changes to this draft in comparison to the previous version (-05 vs.
-04):
1. Fixed minor spelilng errors.
Changes to this draft in comparison to the previous version (-04 vs.
-03):
1. Changed wording of section 1 "Introduction", (Thomson ~ 7/09/08
list comments).
1. Relocated text in section 3 "Overview of Location-by-Reference"
to section 1 (Intro), (Thomson comments).
2. (Sect. 3, con't) Fixed Figure 1. Label, based on (Thomson
comments).
3. Fixed minor spelling errors, incl. Note B., Note C., etc., based
on (Thomson comments).
4. Added some qualifying text (security) around possession model,
based on (Thomson comments).
5. Replaced "use type" labels with "authorization models", "access
authorization model", and "possession authorization model", (Thomson
comments).
6. Changed the entity role of applying security from LIS (Server-
side authentication), to the Rule Maker (owner/Target) providing
policies to the LIS, (Thomson comments).
7. Changed requirement C3 to a MUST, (Thomson comments).
8. Added new requirement, C12, "C12. Location URI Lifetime:" as a
SHOULD for all, and MUST for possession auth model, (Thomson
comments).
Marshall Expires August 30, 2009 [Page 20]
Internet-Draft GEOPRIV LbyR Requirements February 2009
9. Changed name of requirement C8 to "Location Only", (Thomson
comments).
10. Reworded C7 and D6 to be less implementation specific, (Thomson
comments).
11. Changed requirements C11, D11 to SHOULD, (Thomson comments).
12. (Section 5:) Removed lead in sentence for readibility, (Thomson
comments).
13. Remove "pawn ticket" reference - replaced with "possession
authorization model", (Thomson comments).
14. Added new paragraph to the security section (Thomson, 7/09/08
comments).
15. Corrected other minor spelling and wording errors and
deficiencies (refer to diff 04/03) (-Editor).
Changes to this draft in comparison to the previous version (-03 vs.
-02):
1. Changed wording of section 3 "Overview of Location-by-Reference"
(Polk, Thomson, Winterbottom ~ 4/1/08 list comments).
2. Added new requirement C4. "Location Information Masking:", based
on (Thomson ~4/1/08 list comment).
3. Added new requirement C11. "Location URI Use Type:", based on
(~4/1/08 list comments).
4. Added new requirement D11. "Location URI Use Type:", for deref.
based on (~4/1/08 list comments).
5. Replaced requirement D8. "Location URI Non-Anonymized" with
"Location Information Masking:".
Changes to this draft in comparison to the previous version (-02 vs.
-01):
1. Reworded Introduction (Barnes 12/6 list comments).
2. Changed name of "Basic Actors" section to "Overview of Location
by Reference" (Barnes).
3. Keeping the LCP term away (for now) since it is used as Link
Control Protocol elsewhere (IETF).
Marshall Expires August 30, 2009 [Page 21]
Internet-Draft GEOPRIV LbyR Requirements February 2009
4. Changed formatting of Terminology section (Barnes).
5. Requirement C2. changed to indicate that if the URI has a
lifetime, it has to have an expiry (Barnes)
6. C7. Changed title and wording based on suggested text and dhcp-
uri-option example (Polk).
7. The new C2 req. describing valid-for, was also added into the
deref section, as D6
8. Changed C4 based on much list discussion - replaced by 3 new
requirements...
9. Reworded C5 based on the follow-on C4 thread/discussion on list
(~2/18).
10. Changed wording of D3 based on suggestion (Barnes).
11. Reworded D4 per suggestion (Barnes).
12. Changed D5 based on comment (Barnes), and additional title and
text changes for clarity.
13. Added D9 and D10 per Richard Barnes suggestions - something
needed in addition to his own security doc.
14. Deleted reference to individual Barnes-loc-sec draft per wg list
suggestion (Barnes), but need more text for this draft's security
section.
Marshall Expires August 30, 2009 [Page 22]
Internet-Draft GEOPRIV LbyR Requirements February 2009
Author's Address
Roger Marshall (editor)
TeleCommunication Systems, Inc.
2401 Elliott Avenue
2nd Floor
Seattle, WA 98121
US
Phone: +1 206 792 2424
Email: rmarshall@telecomsys.com
URI: http://www.telecomsys.com
Marshall Expires August 30, 2009 [Page 23]
