wdiff draft-ietf-geopriv-lbyr-requirements-01.txt draft-ietf-geopriv-lbyr-requirements-02.txt

GeoPriv R. Marshall, Ed.
Internet-Draft TCS
Intended status: Informational October 11, 2007 February 25, 2008
Expires: April 13, August 28, 2008

Requirements for a Location-by-Reference Mechanism
draft-ietf-geopriv-lbyr-requirements-01
draft-ietf-geopriv-lbyr-requirements-02

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 April 13, August 28, 2008.

Abstract

This document defines terminology and provides requirements relating
to Location-by-Reference approach using a location URI to handling handle
location information within signaling and other Internet messaging.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Basic Actors . . . . . . . . . . .
3. Overview of Location-by-Reference . . . . . . . . . . . . . . 6
5.
4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 8
5.1. 9
4.1. Requirements for a Location Configuration Protocol . . . 8
5.2. 9
4.2. Requirements for a Location Dereference Protocol . . . . 9
6. 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 17
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 15 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 19
Intellectual Property and Copyright Statements . . . . . . . . . . 17 20

1. Introduction

Location-based services rely on ready access to location information,
which can be through a direct or indirect mechanism. While there is
already a direct mechanism which exists to provide are
mechanisms for providing location directly, (e.g., as part of the SIP
signaling protocol, protocol), an alternative mechanism has been developed for
handling location indirectly, via a location reference, a reference which points pointer to
the actual location information. This reference is called the a location
URI, and is used by the mechanism we generally call Location-by-Reference, the Location-by-
Reference mechanism, or simply, LbyR.

Each

The use of the actions by which a location URI can be used is
represented generally applied in one of the
following ways:

1. Creation/allocation of a location URI, by specific individual protocol. For example, a location server based
on some request mechanism.

2. As part of a Location Configuration Protocol, is used between a target
and location server*.

3. The location dereference process, (between a dereference client
and dereference server).

4. Cancellation/expiration of a location URI, by a device location server
based on either a direct target request or middlebox some other action (e.g.,
timer).

*In this document, we make no differentiation between a LS, per
RFC3693, and a LIS, but may refer to acquire either of them as a location which already exists (examples of this
server interchangeably.

These four things fall under two general protocol include
DHCP, LLDP-MED, and HELD [I-D.ietf-geopriv-http-location-delivery]).
The mechanisms,
location configuration protocol problem statement protocols and
requirements document can be found in [I-D.ietf-geopriv-l7-lcp-ps].
The action location dereference protocols.

A fifth use of conveying a location URI along from node to node
according to specific rules in SIP, for example, is known as a
conveyance protocol. A within the context of what is called
location dereferencing conveyance. Location conveyance is defined as part of the
SIP protocol, and is used by a
client to resolve out of scope for this document. (see
[I-D.ietf-sip-location-conveyance] for an explanation of conveyance
of location using a location URI URI.

The issues around location configuration protocols have been
documented in exchange for a location information
from configuration protocol problem statement and
requirements document [I-D.ietf-geopriv-l7-lcp-ps].

There are currently a dereference server (e.g., several examples of a LIS). location configuration
protocol. These include DHCP, LLDP-MED, and HELD
[I-D.ietf-geopriv-http-location-delivery]) protocols.

The structure of this document first defines includes terminology, or points
to the appropriate draft where defined, in Section 3. Then 2,
followed by a short discussion on of the basic elements which show LbyR. This section on that surround how a
location URI is used. These elements, or actors, are discussed in an
overview section, Section 4 includes 3, accompanied by a basic model, graph and describes the steps
which the LbyR mechanism takes. associated
processing steps.

Requirements are outlined separately for accordingly, separated as location configuration,
configuration requirements, Section 5.1, followed by those for a dereferencing protocol, 4.1, and location dereference
requirements, Section 5.2.

Location-by-Value, called LbyV, in 4.2.

In contrast to LbyR, is using a direct location conveyance approach and includes URI as the mechanism to support a
Location-by-Reference model, it may be worth mentioning the common
alternative model, that of Location-by-Value (LbyV), which provides
location directly. LbyV uses a location object, e.g., (e.g., a PIDF-LO [RFC4119] in the PIDF-LO,
[RFC4119]) within SIP signaling. Location conveyance Using the LbyV model for location
configuration is considered out of scope for this document (see
[I-D.ietf-sip-location-conveyance] for an explanation of conveyance of location including both
conveyance for either LbyR and or LbyV scenarios.

Location determination, which may include the processes of different than location configuration or
dereferencing, often includes topics related to manual
provisioning, provisioning
processes, automated measurements, or and/or location transformations,
(e.g., geo-coding), and are beyond the scope of this document.

A detailed discussion of Identity information related to the caller,
subscriber, or device, as associated to location or location URI, is
also out of scope.

2. Requirements 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].

3. Terminology

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:

3.1. Terms

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
either
by means of a location URI for use in either a location
configuration, conveyance, or in dereferencing protocols
as an identifier protocol, and which
refers to a fully specified location,
(i.e., a pointer to the actual location value). 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.

4. Basic Actors

3. Overview of Location-by-Reference

In mobile wireless 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 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. Finally,
in some deployments, the network operator may not want to make
location information widely available.

These use scenarios

Different location scenarios, 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 motivated the introduction of the LbyR
concept. Depending on the type of reference, such as HTTP/HTTPS or
SIP Presence URI, different operations can be performed. While an HTTP/
HTTPS
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].

+-----------+ Geopriv +-----------+
| | Location | Location |
| LIS +---------------+ Recipient |
| | Dereference | |
+-----+-----+
+-+---+-----+ Protocol (3) +----+------+
* | --
Rulemaker * | Geopriv --
Policy * | Location --
Exchange * | Configuration --
(1b) * | Protocol --
* | (1) (1a) -- Geopriv
* | -- Using Protocol
|
+ - - - -*- - - - - -|- - - -+ -- (e.g., SIP)
|+------+----+ +-----+-----+ -- |-- (2)
| Rulemaker | | Target / |--
|| / owner | | End Host + |
| | | |
|+-----------+ +-----------+ |

| User of Target |
+ - - - - - - - - - - - - - -+

Figure 1: Shows the assumed communication model for both a layer 7
location configuration protocol and a dereference protocol:

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 that there A. There is no requirement for using the same protocol in (1) (1a)
and (3).

The following list describes the location subscription approach:

1. The end host discovers

Note B. Figure 1 includes the LIS.

2. The target (end host) sends a request to interaction between the LIS asking for a
location URI, as shown in (1) owner of Figure 1.

3. The LIS responds to the request and includes a location object
along with a subscription URI.

4. The
Target puts the subscription URI into a SIP message and
forwards it the LIS to a Location Recipient via a using protocol, as shown in
(2) of Figure 1. The Location Recipient subscribes establish Rulemaker policies. This is
communications path (1b). This interaction needs to be done before
the obtained
subscription URI (see (3) LIS will authorize anything of Figure 1) and potentially uses a
location filter (see [I-D.ietf-geopriv-loc-filters]) than default policies to limit the
notification rate.

5. If the Target moves outside a certain area, indicated by a
dereference request for location filter, of the Location Recipient will receive a notification. Target.

Note C. that the Target may also act in take on the role of the Location
Recipient whereby it would subscribe dereference the location URI to obtain its
own location information.
For example,

An example scenario of how this might work, is where the Target
obtains a subscription location URI from in the form of a subscription URI (e.g., a SIP
URI) via HELD, (a Geopriv
L7 Location Configuration Protocol. It subscribes layer 7 location configuration protocol).
Since, in this case the Target equals Recipient, then the Target can
subscribe to the URI in order to obtain be notified of its current location information. A service
based on subscription parameters (see
[I-D.ietf-geopriv-loc-filters]). Additionally, a geospatial boundary
indicates the bounded extent up to which the device
can move without be expressed (ref. [I-D.ietf-geopriv-policy]), so that the need to have an
Target/Recipient will get its updated location, since a re-query with any location within the boundary would result in notification once it
crosses the same answer returned
from a location-based service.

For LbyR, specified boundary.

Location URIs may have an life expiration associated to them, so the
LIS needs to maintain a list be able to keep track of randomized the location URIs that have
been handed out, in addition, to also know about validity information
for each host, timing out each of these URIs after the reference
expires. location URI. Location URIs need to expire to prevent the
recipient of such a URI from being able to (in some cases)
permanently track a host. Furthermore, Another example of the usefulness of an
expiration mechanism also offers is to offer garbage collection capability for capabilities to
the LIS.

Location URIs must be designed

It is important to prevent adversaries from obtaining any information
about a Target through the location URI itself, or even a known Target's location.
location if the owner of the Target wants to protect it. Therefore,
each location URI must be constructed with security safeguards in
mind. There are at least two approaches: The
location URI contains a random component which helps obscure
sequential updates general cases assumed, both having to location, yet still allows any holder do with
the form of the location URI when it is created.

Case 1. Where access to obtain the location information. Alternatively, URI is limited by policy: This
is the case where the LIS applies authentication and access
control at location configuration step and again at the
dereference step. In this case, the URI can remain public and be of any form chosen
by the LIS.

Case 2. Access limited by distribution: The LIS performs does not apply
authentication and access control
via a separate authentication mechanism, such as HTTP digest or TLS
client side authentication, when resolving at the time that the reference to a location object.

5.
URI is dereferenced. In this case, the location URI must be
difficult to guess (so that possession can be used to imply
authorization).

4. High-Level Requirements

This document outlines only the requirements for an LbyR Location by Reference
mechanism which
is can be used by a number of underlying protocols.
Requirements here address two different general types of such protocols, a
general location configuration protocol, and a general location
dereferencing protocol. Each Given that either of these two general
protocols can take the form of different protocols implementations
for either location configuration vs. location dereference, (e.g.,
HELD/DHCP/LLDP-MED, vs. HTTP GET/SIP SUBSCRIBE/NOTIFY, respectively).
Because each of these specific protocol implementations has its own
unique client and server interactions, and 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 either the a location
configuration protocol, or dereferencing protocol itself.

5.1. a 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: The lifetime of When a location URI SHOULD has a limited
validity interval, its lifetime MUST be indicated.

Motivation: Location URIs are A location URI may not intended 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
SHOULD 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. Random Generated: The location URI MUST be hard to guess, i.e.,
it MUST contain a cryptographically random component.

Motivation: There is some benefit to the client if the location
URI is generated in an obscured manner so that its sequence, for
example in the case of a client's location update, can't be easy
guessed. [Deleted, replaced by C8,C9,C10]:

C5. User Identity Protection: The location URI MUST NOT contain any
user identifying information that identifies the user, device or
address of record 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. Location timestamp: There SHOULD be URI Valid-for: A location URI validity interval, if
used, MUST include the validity time, in seconds, as an indication
of how long the client can consider a way location URI to allow a client be valid.

Motivation: It is important to be able to determine whether the dereferenced how long a
location URI is to remain useful for, and when it must be
refreshed.

C8. Location URI Anonymous: The location URI MUST NOT reveal any
information refers 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: Location URIs that do not require
authentication and authorization MUST NOT be guessable, based on
the use of a cryptographically random sequence somewhere within
the Target URI. (Note that the number of bits depends to some extent on
the number of active location URIs that might exist at the time when one
time; 128-bit is most likely enough for the short term.)

Motivation: Location URIs without access control reveal private
information, and a guessable location URI was
created could be easily
exploited to obtain private information.

C10. Location URI Optional: In the case of user-provided
authorization policies, where anonymous or when it was dereferenced. non-guessable location
URIs are not warranted, the location configuration protocol MAY
support optional location URI forms.

Motivation: It is important Users don't always have such strict privacy
requirements, but may opt to distinguish between an original and
an updated location.

5.2. 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.

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. Location URI expiration status: indicator: The location dereference
protocol MUST support a message indicating an indicator showing that, if it is the
case, that for a location URI
which is no longer valid, that the location URI has expired. valid due to expiration.

Motivation: Location URIs are expected to expire, based on
location configuration protocol parameters, and it is therefore
useful to convey the expired status of the location URI in the
location dereference protocol.

D3. Authentication: The location dereference protocol MUST support
either client-side include
mechanisms to authenticate both the client and server-side authentication. the server.

Motivation: It is reasonable to expect Although the implementations of must support
authentication to vary. Some implementations may choose to
implement of both client-side and server-side authentication, might
implement parties, any given transaction has the
option not to authenticate one only, or may implement neither. both parties.

D4. Dereferenced Location Form: The dereferenced location value returned by the
dereference protocol MUST
result in contain a well-formed PIDF-LO. 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: Use: The location dereference protocol
MUST support the ability for the same location URI to be resolved
more than once, based on dereference server settings and configuration server parameters. configuration.

Motivation: According to configuration Through dereference server parameters, configuration, for example,
it may be necessary useful to have a not only allow more than one dereference
request, but, in some cases, to also limit on the number of
dereferencing
attempts.

6. attempts by a client.

D6. Location URI Valid-for: A location URI validity interval, if
used, MUST include the validity time, in seconds, as an indication
of how long the client can consider a location URI to be valid.

Motivation: It is important to be able to determine how long a
location URI is to remain useful when dereferencing a location
URI.

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).

D8. Location URI non-anonymized: The dereference protocol MAY define
a more general, non-anonymized URI format.

Motivation: Only location URIs for which dereference is subject to
access-control policy by the LIS may use this format.

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.

5. Security Considerations

The LbyR mechanism currently addresses security issues as follows.

A location URI, regardless of its randomized construction, if public, implies
no safeguard against anyone being able to dereference and get the
location. The randomization method of constructing a location URI in its naming
does help prevent some potential guessing, according to some
defined pattern. In the instance of one-time-
use one-time-use location URIs,
which function similarly to a pawn ticket, the argument can be
made that with a pawn ticket, possession implies permission, and
location URIs which are public are protected only by privacy rules
enforced at the dereference server.

Additional security issues will be discussed in the geopriv draft,
draft-barnes-geopriv-lo-sec-00.txt.

6. IANA Considerations

This document does not require actions by the IANA.

7. Acknowledgements

We would like to thank the IETF GEOPRIV working group chairs, Andy
Newton, Allison Mankin and Randall Gellens, for creating the design
team which initiated this requirements work. We'd also like to thank
those design team participants for their inputs, comments, and
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.

8. References

9.1.

8.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2.

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-02
draft-ietf-geopriv-http-location-delivery-05 (work in
progress), September 2007. February 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-05 draft-ietf-geopriv-l7-lcp-ps-06 (work in
progress), September November 2007.

[I-D.ietf-geopriv-loc-filters]
Mahy, R., "A Document Format for Filtering and Reporting
Location Notications in the Presence Information Document
Format Location Object (PIDF-LO)",
draft-ietf-geopriv-loc-filters-01 (work in progress),
March 2007.

[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-14 (work in progress),
February 2008.

[I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol",
draft-ietf-sip-location-conveyance-08
draft-ietf-sip-location-conveyance-09 (work in progress),
July
November 2007.

[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.

Appendix A. Change log

Changes to this draft in comparison to the -00 version: previous version (-02 vs.
-01):

1. Shortened Abstract and Introduction. Reworded Introduction (Barnes 12/6 list comments).

2. LDP term gone. Expansion Changed name of Location Dereferencing Protocol,
deletion "Basic Actors" section to "Overview of "LDP" acronym throughout, since LDP stands for Label
Distribution Protocol elsewhere in the IETF. Location
by Reference" (Barnes).

3. Keeping the LCP term is also gone. LCP away (for now) since it is used as Link
Control Protocol elsewhere (IETF).

4. Reduced the number Changed formatting of terms in the doc. Referenced other drafts
or RFCs for repeated terms. Terminology section (Barnes).

5. Requirement C2. changed to indicate that if the URI has a lifetime.

6. C3. Softened by changing from a MUST
lifetime, it has to a SHOULD.

7. C6. Reworded for clarity.

8. 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 MUST to a SHOULD to reflect a more appropriate
level.
deref section, as D6

8. Changed C4 based on much list discussion - replaced by 3 new
requirements...

9. D6. Replaced 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 make it clearer.

10. D7. his own security doc.

14. Deleted the requirement since it wasn't an appropriate task reference to individual Barnes-loc-sec draft per wg list
suggestion (Barnes), but need more text for the protocol.

11. Referenced Richard's this draft's security document

12. Cleaned up some text.
section.

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

Full Copyright Statement

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.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).