GeoPriv R. Marshall, Ed.
Internet-Draft TCS
Intended status: Informational November 28, 2008
Expires: June 1, 2009
Requirements for a Location-by-Reference Mechanism
draft-ietf-geopriv-lbyr-requirements-05
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 June 1, 2009.
Marshall Expires June 1, 2009 [Page 1]
Internet-Draft GEOPRIV LbyR Requirements November 2008
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview of Location-by-Reference . . . . . . . . . . . . . . 7
4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 10
4.1. Requirements for a Location Configuration Protocol . . . 10
4.2. Requirements for a Location Dereference Protocol . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Marshall Expires June 1, 2009 [Page 2]
Internet-Draft GEOPRIV LbyR Requirements November 2008
1. Introduction
Since all location-based services rely on ready access to location
information, this can accomplished through some direct means, or
alternatively, through some indirect means as a pointer to location
information. The direct vs. indirect approach we characterize as
either Location-by-Value (LbyV), or Location-by-Reference (LbyR).
While it is the case that within SIP, location can be handled in a
direct manner, (i.e., passing the actual location information around
in the form of a PIDF-LO*), there are additional location
requirements which apply to certain applications and/or location
architectures that are only satisfied by specifying an indirect
location mechanism. This document puts forth a set of requirements
for such an indirect location approach, namely, the LbyR location
model.
As justification for a LbyR model, consider the following. 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 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, and more, 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 concept.
The concept of an LbyR mechanism is simple. It is made up of a
pointer which makes reference to the actual location information by
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".
The LbyR mechanism itself works according to an information
lifecycle. Within the LbyR mechanism, location URIs are 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:
Marshall Expires June 1, 2009 [Page 3]
Internet-Draft GEOPRIV LbyR Requirements November 2008
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.
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.
*The standard mechanism for LbyV has been defined around the use of
the PIDF-LO (Presence Information Document Format - Location Object
[RFC4119]]), and is explicitly out of scope in this document.
**This document make no differentiation between a LS, per RFC3693,
and a LIS [ref. draft-ietf-geopriv-l7-lcp-ps], but may refer to
either of them as a location server interchangeably.
***Location Conveyance for either LbyR or LbyV, 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.
The issues around location configuration protocols have been
documented in a location configuration protocol problem statement and
Marshall Expires June 1, 2009 [Page 4]
Internet-Draft GEOPRIV LbyR Requirements November 2008
requirements document [I-D.ietf-geopriv-l7-lcp-ps]. There are
currently several examples of a location configuration protocols
currently proposed, including, DHCP, 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 and associated
processing steps.
Requirements are outlined accordingly, separated as location
configuration requirements, Section 4.1, and location dereference
requirements, Section 4.2.
Marshall Expires June 1, 2009 [Page 5]
Internet-Draft GEOPRIV LbyR Requirements November 2008
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): The mechanism of representing location
either in configuration or conveyance protocols, (i.e., the actual
included location value).
Location-by-Reference (LbyR): The mechanism of representing location
by means of a location URI for use in either a location
configuration, conveyance, or dereferencing protocol, and which
refers to a fully specified location.
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 which is used by a client
to query a location dereference server, based on location URI
input and which returns location information.
Location URI: An identifier which serves as a pointer to a location
record on a remote host (e.g., LIS). Used within an Location-by-
Reference mechanism, a location URI is provided by a location
configuration server, and is used as input by a dereference
protocol to retrieve location from a dereference server.
Marshall Expires June 1, 2009 [Page 6]
Internet-Draft GEOPRIV LbyR Requirements November 2008
3. Overview of Location-by-Reference
This section describes the entities and interactions involved in the
LbyR model.
+-----------+ Geopriv +-----------+
| | Location | Location |
| LIS +---------------+ Recipient |
| | Dereference | |
+-+---+-----+ Protocol (3) +----+------+
* | --
Rulemaker * | Geopriv --
Policy * | Location --
Exchange * | Configuration --
(1b) * | Protocol --
* | (1a) -- Geopriv
* | -- Using Protocol
+ - - - -*- - - - - -|- - - -+ -- (e.g., SIP)
|+------+----+ +-----+-----+ |-- (2)
| Rulemaker | | Target / |--
|| / owner | | End Host + |
| | | |
|+-----------+ +-----------+ |
| User of 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.
(1a). Target requests reference from server; and receives back, a
location URI in server response
(1b). Rulemaker policy is consulted (interface out of scope)
(2). Target conveys reference to recipient (out of scope)
(3). Recipient dereferences location URI, by a choice of methods,
including a request/response (e.g., HTTP) or publish/subscription
(e.g., SIP SUBSCRIBE/NOTIFY)
Note A. There is no requirement for using the same protocol in (1a)
and (3).
Marshall Expires June 1, 2009 [Page 7]
Internet-Draft GEOPRIV LbyR Requirements November 2008
Note B. Figure 1 includes the interaction between the owner of the
Target and the LIS to establish Rulemaker policies. This is
communications path (1b). This interaction needs to be done before
the LIS will authorize anything other than default policies to a
dereference request for location of the Target.
Note C. The Target may take on the role of the Location Recipient
whereby it would dereference the location URI to obtain its own
location information.
An example scenario of how this might work, is where the Target
obtains a location URI in the form of a subscription URI (e.g., a SIP
URI) via HELD (a Geopriv layer 7 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]).
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.
Because a location URI is a pointer to the Target's location, it is
important that it be constructed in such a way that it does not
unintentionally reveal any usable information about the Target it
represents. For example, it is important to prevent adversaries from
obtaining any information that may be revealed about a Target by
direct examination of the location URI itself, (e.g., names,
identifiers, etc.), some determinable pattern or syntax (e.g.,
sequence of numbers), or guessable codes (e.g., weak encryption).
Therefore, each location URI must be constructed with security
safeguards in mind.
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 could be done according to one of two
authorization models, either an "access control authorization model"
or a "possession authorization model" (see definitions, below), it is
Marshall Expires June 1, 2009 [Page 8]
Internet-Draft GEOPRIV LbyR Requirements November 2008
important that location configuration protocols indicate the type of
a location URI that is being requested, (and also which type is
returned).
1. Access control authorization model: Access to the location URI is
limited by policy. In this case, the Rule Maker (owner/Target) is
able to provide authorization policies to the LIS during this
stage, or through some other parallel mechanism (e.g., interface
1b., Figure 1.). Policies are attached to a location URI through
an (undisclosed) mechanism.
2. Possession authorization model: The possession authorization
model is described as having no authentication and/or
authorization requirement aside from only possessing the location
URI itself. In this case, possession implies authorization.
Access to the location URI is limited by distribution only.
Whoever possesses the location URI has the ability to dereference
it. Possession authorization models may be used within specified
domains only, or might be used across wide open public networks.
In either of the above cases, a location URI needs to be constructed
is such a way as to make it difficult to guess. The form of the URI
is constrained by the degree of randomness and uniqueness applied to
it. It is important to protect the actual location information from
an intermediate node (despite the fact that in the possession model
there would be nothing to prevent an interceptor from seeking to
dereference the location URI). Obfuscating the location URI
safeguards against the undetected stripping off of what would
otherwise be evident location information, since it forces a
dereference operation by 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 June 1, 2009 [Page 9]
Internet-Draft GEOPRIV LbyR Requirements November 2008
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. Each of these two general protocols has
multiple specific protocol implementations. Location configuration
protocols include, HELD, DHCP, and LLDP-MED, whereas current location
dereferencing protocols include HELD Deref, HTTP GET, and SIP
SUBSCRIBE/NOTIFY. Because each of these specific protocol
implementations has its own unique client and server interactions,
the requirements here are not intended to state what a client or
server is expected to do, but rather which requirements must be met
separately by any location configuration protocol or location
dereference protocol, for the purposes of using a location URI.
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 configuration protocol MUST support a
location reference in URI form.
Motivation: It is helpful to have a consistent form of key for the
LbyR mechanism.
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.
Marshall Expires June 1, 2009 [Page 10]
Internet-Draft GEOPRIV LbyR Requirements November 2008
C4. Location Information Masking: The location URI form MUST,
through randomization and uniqueness, ensure that any location
specific information embedded within the location URI itself is
kept obscure during location configuration.
Motivation: It is important to keep any location information
masked from a casual observing node.
C5. User Identity Protection: The location URI MUST NOT contain any
user identifying information that identifies the user, device or
address of record, (e.g., which includes phone extensions, badge
numbers, first or last names, etc.), within the URI form.
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. Validity Interval Indication: A location configuration protocol
MUST provide an indication of the location URI validity interval
(i.e., expiry time) when present.
Motivation: It is important to be able to determine how long a
location URI is to remain useful for, and when it must be
refreshed.
C8. Location only: The location URI MUST NOT point to any
information about the Target other than it's location.
Motivation: A user should have the option to control how much
information is revealed about them. This provides that control by
not forcing the inclusion of other information with location,
(e.g., to not include any identification information in the
location URI.)
C9. Location URI Not guessable: Where location URIs are used
publicly, any location URI MUST be constructed using properties of
uniqueness and cryptographically random sequences so that it is
not guessable. (Note that the number of bits depends to some
extent on the number of active location URIs that might exist at
the one time; 128-bit is most likely enough for the near term.)
Marshall Expires June 1, 2009 [Page 11]
Internet-Draft GEOPRIV LbyR Requirements November 2008
Motivation: Location URIs need to guard against any observing node
or individual stripping off meaningful information about the
Target.
C10. 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.
Motivation: Users don't always have such strict privacy
requirements, but may opt to specify their own location URI, or
components thereof.
C11. Location URI Authorization Model: The location configuration
protocol SHOULD indicate whether the requested location URI
conforms to the access control authorization model or the
possession authorization model.
Motivation: Downstream dereference clients and servers need to
know whether a location URI provided by the location configuration
protocol conforms to an access control authorization model or a
possession authorization model.
C12. Location URI Lifetime: A location URI SHOULD have an
associated expiration lifetime (i.e., validity interval), and MUST
have an validity interval if used with the possession
authorization model.
Motivation: If a location URI is unintentionally leaked, then the
amount of time that the reference can be potentially used by an
unknown attacker (or, casual observer) needs to be limited.
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.
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.
Marshall Expires June 1, 2009 [Page 12]
Internet-Draft GEOPRIV LbyR Requirements November 2008
D2. Validity Interval Indication: A location dereference protocol
MUST provide an indication of the location URI validity interval
(i.e., expiry time) when present.
Motivation: It is important to be able to determine how long a
location URI is to remain useful for, and what time it will no
longer be usable.
D3. 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.
D4. 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.
D5. 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.
D6. Validity Interval Indication: A dereference protocol MUST
provide an indication of the location URI validity interval (i.e.,
expiry time) when present.
Motivation: It is important to be able to determine how long a
location URI is to remain useful for, and when it must be
refreshed.
D7. Location URI anonymized: Any location URI whose dereference will
not be subject to authentication and access control MUST be
anonymized.
Motivation: The dereference protocol must define an anonymized
format for location URIs. This format must identify the desired
location information via a random token with at least 128 bits of
entropy (rather than some kind of explicit identifier, such as an
IP address).
Marshall Expires June 1, 2009 [Page 13]
Internet-Draft GEOPRIV LbyR Requirements November 2008
D8. Location Information Masking: The location URI form MUST,
through randomization and uniqueness, ensure that any location
specific information embedded within the location URI itself is
kept obscure during location URI dereferencing.
Motivation: It is important to keep any location information
masked from a casual observing node, requiring instead a discrete
dereference operation in order to return location information.
D9. Location Privacy: The location dereference protocol MUST support
the application of privacy rules to the dissemination of a
requested location object.
Motivation: The dereference server must obey all provisioned
privacy rules that apply to a requested location object.
D10. Location Confidentiality: The dereference protocol MUST
support encryption of messages sent between the location
dereference client and the location dereference server, and MAY
alternatively provide messaging unencrypted.
Motivation: Environmental and local configuration policy will
guide the requirement for encryption for certain transactions. In
some cases, encryption may be the rule, in others, it may be
acceptable to send and receive messages without encryption.
D11. Location URI Authorization Model: The location dereference
protocol SHOULD indicate whether the requested location URI
conforms to the access control authorization model or the
possession authorization model.
Motivation: Downstream dereference clients need to know whether a
location URI provided by the location configuration protocol
conforms to an access control authorization model or a possession
authorization model in order to save time processing dereference
attempts.
Marshall Expires June 1, 2009 [Page 14]
Internet-Draft GEOPRIV LbyR Requirements November 2008
5. Security Considerations
A location URI, regardless of its construction, if public, by itself,
implies no safeguard against anyone being able to dereference and get
the location. The method of constructing the location URI form to
include randomization along with encryption does help prevent some
potential pattern guessing. In the case of one time use location
URIs, (referred to as a pawn ticket), the argument can be made that
possession implies permission, and location URIs that are public are
protected only by privacy rules enforced at the dereference server.
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 June 1, 2009 [Page 15]
Internet-Draft GEOPRIV LbyR Requirements November 2008
6. IANA Considerations
This document does not require actions by the IANA.
Marshall Expires June 1, 2009 [Page 16]
Internet-Draft GEOPRIV LbyR Requirements November 2008
7. Acknowledgements
I would like to thank the present IETF GEOPRIV working group chairs,
Robert Sparks and Richard Barnes for their continued support in
progressing this document along, as well, I wish to thank past
chairs, Andy Newton, Allison Mankin and Randall Gellens, for creating
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 June 1, 2009 [Page 17]
Internet-Draft GEOPRIV LbyR Requirements November 2008
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-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-10 (work in
progress), October 2008.
[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-08 (work in
progress), June 2008.
[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-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
and J. Polk, "Geolocation Policy: A Document Format for
Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-17 (work in progress),
June 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 June 1, 2009 [Page 18]
Internet-Draft GEOPRIV LbyR Requirements November 2008
Appendix A. Change log
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).
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
Marshall Expires June 1, 2009 [Page 19]
Internet-Draft GEOPRIV LbyR Requirements November 2008
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).
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).
Marshall Expires June 1, 2009 [Page 20]
Internet-Draft GEOPRIV LbyR Requirements November 2008
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 June 1, 2009 [Page 21]
Internet-Draft GEOPRIV LbyR Requirements November 2008
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 June 1, 2009 [Page 22]
Internet-Draft GEOPRIV LbyR Requirements November 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Marshall Expires June 1, 2009 [Page 23]
