idnits 2.17.1 draft-ietf-geopriv-lbyr-requirements-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 149 has weird spacing: '...ocation infor...' == Line 153 has weird spacing: '...llation reque...' == Line 353 has weird spacing: '...ipients can't...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 2009) is 5537 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-geopriv-dhcp-lbyr-uri-option-03 == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-13 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-09 == Outdated reference: A later version (-11) exists of draft-ietf-geopriv-loc-filters-03 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-12 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GeoPriv R. Marshall, Ed. 3 Internet-Draft TCS 4 Intended status: Informational February 26, 2009 5 Expires: August 30, 2009 7 Requirements for a Location-by-Reference Mechanism 8 draft-ietf-geopriv-lbyr-requirements-07 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 30, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 This document may contain material from IETF Documents or IETF 45 Contributions published or made publicly available before November 46 10, 2008. The person(s) controlling the copyright in some of this 47 material may not have granted the IETF Trust the right to allow 48 modifications of such material outside the IETF Standards Process. 49 Without obtaining an adequate license from the person(s) controlling 50 the copyright in such materials, this document may not be modified 51 outside the IETF Standards Process, and derivative works of it may 52 not be created outside the IETF Standards Process, except to format 53 it for publication as an RFC or to translate it into languages other 54 than English. 56 Abstract 58 This document defines terminology and provides requirements relating 59 to Location-by-Reference approach using a location URI to handle 60 location information within signaling and other Internet messaging. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3. Overview of Location-by-Reference . . . . . . . . . . . . . . 8 67 3.1. Location URI Usage . . . . . . . . . . . . . . . . . . . . 9 68 3.2. Location URI Expiration . . . . . . . . . . . . . . . . . 9 69 3.3. Location URI Authorization . . . . . . . . . . . . . . . . 10 70 3.4. Location URI Construction . . . . . . . . . . . . . . . . 10 71 4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 12 72 4.1. Requirements for a Location Configuration Protocol . . . . 12 73 4.2. Requirements for a Location Dereference Protocol . . . . . 13 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 80 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 19 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 1. Introduction 85 All location-based services rely on ready access to location 86 information. Using location information can be done one of two ways, 87 either in a direct, Location-by-Value (LbyV) approach, or using an 88 indirect, Location-by-Reference (LbyR) model. 90 For LbyV, location information is conveyed directly in the form of a 91 PIDF-LO ([RFC4119]). Using LbyV might either be infeasible or 92 undesirable in some circumstances. There are cases where LbyR is 93 better able to address location requirements for a specific 94 architecture or application. This document provides a list of 95 requirements for use with the LbyR approach, and leaves the LbyV 96 model explicitly out of scope. 98 As justification for a LbyR model, consider the circumstance that in 99 some mobile networks it is not efficient for the end host to 100 periodically query the LIS for up-to-date location information. This 101 is especially the case when power availability is a constraint or 102 when a location update is not immediately needed. Furthermore, the 103 end host might want to delegate the task of retrieving and publishing 104 location information to a third party, such as to a presence server. 105 Additionally, in some deployments, the network operator may not want 106 to make location information widely available. These kinds of 107 location scenarios provided, and others, such as whether a Target is 108 mobile and whether a mobile device needs to be located on demand or 109 according to some pre-determined interval, together, form the basis 110 of motivation for the LbyR model. 112 The concept of an LbyR mechanism is simple. It is made up of a 113 reference identifier which indirectly references actual location 114 information using some combination of key value and fully qualified 115 domain name. This combination of data elements, in the form of a 116 URI, is referred to specifically as a "location URI". 118 A location URI is thought of as a dynamic reference to the current 119 location of the Target, yet the location value might remain unchanged 120 over specific intervals of time for several reasons. These include: 122 - Limitations in the process used to generate location information 123 mean that cached location might be used. 125 - Policy constraints that may dictate that the location provided 126 remains fixed over time for specified Location Recipients. Without 127 additional information, a Location Recipient cannot assume that the 128 location information provided by any location URI is static, and will 129 never change. 131 The LbyR mechanism works according to an information lifecycle. 132 Within this lifecycle, location URIs are considered temporary 133 identifiers, each undergoing the following uses: Creation; 134 Distribution; Conveyance; Dereference; and Termination. The use of a 135 location URI according to these various states is generally applied 136 in one of the following ways: 138 1. Creation of a location URI, within a location server, based on 139 some request for its creation. 141 2. Distribution of a location URI, via a Location Configuration 142 Protocol, between a target and a location server. 144 3. Conveyance, applied to LbyR, in SIP, is the transporting of the 145 location URI, in this case, between any successive signaling nodes. 147 4. Dereference of a location URI, a request/response between a 148 client having a location URI and a location server holding the 149 location information that the location URI references. 151 5. Termination of a location URI, either due to expiration or 152 cancellation within a location server, and which is based on a target 153 cancellation request or some other action, such as timer 154 expiration. 156 Note that this document makes no differentiation between a LS, per 157 [RFC3693], and a LIS, as shown in [I-D.ietf-geopriv-l7-lcp-ps]), but 158 may refer to either of them as a location server interchangeably. 160 Location determination, different than location configuration or 161 dereferencing, often includes topics related to manual provisioning 162 processes, automated location calculations based on a variety of 163 measurement techniques, and/or location transformations, (e.g., geo- 164 coding), and is beyond the scope of this document. 166 Location Conveyance for either LbyR or LbyV as defined within SIP 167 signaling is considered out of scope for this document (see 168 [I-D.ietf-sip-location-conveyance] for an explanation of location 169 conveyance for either LbyR or LbyV scenarios.) 171 Except for location conveyance, the above stages in the LbyR 172 lifecycle fall into one of two general categories of protocols, 173 either a Location Configuration Protocol or a Location Dereference 174 Protocol. The stages of LbyR Creation, Distribution, and 175 Termination, are each found within the set of Location Configuration 176 Protocols (LCP). The Dereference stage belongs solely to the set of 177 Location Dereference Protocols. 179 The issues around location configuration protocols have been 180 documented in a location configuration protocol problem statement and 181 requirements document [I-D.ietf-geopriv-l7-lcp-ps]. There are 182 currently several examples of a location configuration protocols 183 currently proposed, including, DHCP 184 [I-D.ietf-geopriv-dhcp-lbyr-uri-option], LLDP-MED, and HELD 185 [I-D.ietf-geopriv-http-location-delivery] protocols. 187 For dereferencing of a location URI, depending on the type of 188 reference used, such as a HTTP/HTTPS, or SIP Presence URI, different 189 operations can be performed. While an HTTP/HTTPS URI can be resolved 190 to location information, a SIP Presence URI provides further benefits 191 from the SUBSCRIBE/NOTIFY concept that can additionally be combined 192 with location filters [I-D.ietf-geopriv-loc-filters]. 194 The structure of this document includes terminology, Section 2, 195 followed by a discussion of the basic elements that surround how a 196 location URI is used. These elements, or actors, are discussed in an 197 overview section, Section 3, accompanied by a graph, associated 198 processing steps, and a brief discussion around the use, expiration, 199 authorization, and construction of location URIs. 201 Requirements are outlined accordingly, separated as location 202 configuration requirements, Section 4.1, and location dereference 203 requirements, Section 4.2. 205 2. Terminology 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in RFC 2119 [RFC2119]. 211 This document reuses the terminology of [RFC3693], such as Location 212 Server (LS), Location Recipient (LR), Rule Maker (RM), Target, 213 Location Generator (LG), Location Object (LO), and Using Protocol: 215 Location-by-Value (LbyV): Using location information in the form of 216 a location object (LO), such as a PIDF-LO. 218 Location-by-Reference (LbyR): Representing location information 219 indirectly using a location URI. 221 Location Configuration Protocol: A protocol which is used by a 222 client to acquire either location or a location URI from a 223 location configuration server, based on information unique to the 224 client. 226 Location Dereference Protocol: A protocol that is used by a client 227 to query a location server, based on the location URI input and 228 which returns location information. 230 Location URI: As defined within this document, an identifier that 231 serves as a reference to location information. A location URI is 232 provided by a location server, and is later used as input by a 233 dereference protocol to retrieve location information. 235 3. Overview of Location-by-Reference 237 This section describes the entities and interactions involved in the 238 LbyR model. 240 +---------+---------+ Location +-----------+ 241 | | | Dereference | Location | 242 | LIS - LS +---------------+ Recipient | 243 | | | Protocol | | 244 +----+----+----+----+ (3) +-----+-----+ 245 | * | 246 | Policy * | 247 Location | Exchange * | 248 Configuration | (*) * | Location 249 Protocol | +----+----+ | Conveyance 250 (1) | | Rule | | Protocol 251 | | Maker | | (2) 252 +----+----+ +---------+ | 253 | | | 254 | Target +-------------------------------+ 255 | | 256 +---------+ 258 Figure 1: Location Reference Entities and Interactions 260 Figure 1 shows the assumed communication model for both a layer 7 261 location configuration protocol and a location dereference protocol. 263 1. The Target (a Device) uses a Location Configuration Protocol to 264 acquire a location reference from a LIS, which acts as (or is able to 265 access) an LS. 267 In the case where the Target is also a Rule Maker, the location 268 configuration protocol can be used to convey policy information. In 269 the case where possession of a location URI is the only required form 270 of authorization, (see, Section 3.3), a policy is implied whereby any 271 requester is granted access to location information. This does not 272 preclude other means of providing authorization policies. 274 A Target could also acquire a location URI from the LS directly using 275 alternative means, for example, the acquisition of a presence AoR to 276 be used for location information, in which case, it could be regarded 277 as a location URI. 279 2. The Target conveys the location URI to the Location Recipient 280 (interface out of scope). 282 3. The Location Recipient dereferences the location URI to acquire 283 location information from the LS. 285 The LS controls access to location information based on the policy 286 provided by the Rule Maker. 288 Note A. There is no requirement for using the same protocol in (1) 289 and (3). 291 Note B. Figure 1 includes the interaction between the owner of the 292 Target and the LIS to obtain Rule Maker policies. This interaction 293 needs to happen before the LIS will authorize anything other than 294 what is allowed based on default policies in order to dereference a 295 location request of the Target. This communication path is out of 296 scope for this document. 298 Note C. The Target might take on the role of the Location Recipient, 299 in which case it could attempt to dereference the location URI 300 itself, in order to obtain its own location information. 302 3.1. Location URI Usage 304 An example scenario of how the above might work, is where the Target 305 obtains a location URI in the form of a subscription URI (e.g., a SIP 306 URI) via a location configuration protocol. In this case, the Target 307 is the same as the Recipient, therefore the Target can subscribe to 308 the URI in order to be notified of its current location based on 309 subscription parameters. In the example, parameters are set up for a 310 specific Target/Recipient along with an expressed geospatial 311 boundary, so that the Target/Recipient receives an updated location 312 notification once the boundary is crossed (see 313 [I-D.ietf-geopriv-loc-filters]). 315 3.2. Location URI Expiration 317 Location URIs may have an expiry associated with them, primarily for 318 security considerations, and generally so that the LIS is able to 319 keep track of the location URIs that have been handed out, to know 320 whether a location URI is still valid once the LIS receives it in a 321 request, and in order for a recipient of such a URI from being able 322 to (in some cases) permanently track a host. Expiration of a 323 location URI limits the time that accidental leaking of a location 324 URI introduces. Other justifications for expiration of location URIs 325 include the ability for a LIS to do garbage collection. 327 3.3. Location URI Authorization 329 How a location URI is will ultimately be used within the dereference 330 step is an important consideration at the time that the location URI 331 is requested via a location configuration protocol. Since 332 dereferencing of location URIs can be done according to a variety of 333 authorization models it is important that location configuration 334 protocols indicate the type of a location URI that is being 335 requested, as well as which type is returned. 337 Location URIs manifest themselves in a few different forms. The 338 different ways that a location URI can be represented is based on 339 local policy, and are depicted in the following four scenarios. 341 1. No specific information at all: As is typical, a location URI is 342 used to get location information. However, in this case, the URI 343 representation itself does not need to reveal any specific 344 information at all. Location information is acquired by the 345 dereferencing operation a location URI. 347 2. No user specific information: By default, a location URI MUST NOT 348 reveal any information about the Target other than location 349 information. This is true for the URI itself, (or in the document 350 acquired by dereferencing), unless policy explicitly permits 351 otherwise. 353 3. Access control authorization model (unauthorized recipients can't 354 get the information): If the "access control authorization" model is 355 used, the location URI MUST NOT include any location information 356 in its representation. Location URIs operating under this model 357 could be widely published to recipients that are not authorized to 358 receive this information. 360 4. Possession authorization model (the URI itself is a secret): If 361 the "possession authorization" model is used, the location URI is 362 confidential information shared between the LIS/LS, the Device and 363 all authorized Location Recipients. In this case, possession 364 implies authorization. Because knowledge of the location URI is 365 used to authenticate and authorize access to location information, 366 the URI needs to include sufficient randomness to make guessing 367 its value difficult. A possession model URI can include location 368 information in its representation. 370 3.4. Location URI Construction 372 Depending on local policy, a location URI may be constructed in such 373 a way as to make it difficult to guess. Accordingly, the form of the 374 URI is then constrained by the degree of randomness and uniqueness 375 applied to it. In this case, it may be important to protect the 376 actual location information from inspection by an intermediate node. 377 Construction of a location URI in such a way as to not reveal any 378 domain, user, or device specific information, with the goal of making 379 the location URI appear bland, uninteresting, and generic, may be 380 helpful to some degree in order to keep location information more 381 difficult to detect. Thus, obfuscating the location URI in this way 382 may provide some level of safeguard against the undetected stripping 383 off of what would otherwise be evident location information, since it 384 forces a dereference operation at the location dereference server, an 385 important step for the purpose of providing statistics, audit trails, 386 and general logging for many different kinds of location based 387 services. 389 4. High-Level Requirements 391 This document outlines the requirements for an Location by Reference 392 mechanism which can be used by a number of underlying protocols. 393 Requirements here address two general types of such protocols, a 394 general location configuration protocol, and a general location 395 dereferencing protocol. 397 The requirements are broken into two sections. 399 4.1. Requirements for a Location Configuration Protocol 401 Below, we summarize high-level design requirements needed for a 402 location-by-reference mechanism as used within the location 403 configuration protocol. 405 C1. Location URI support: The location configuration protocol MUST 406 support a location reference in URI form. 408 Motivation: A standardized location reference mechanism increases 409 interoperability. 411 C2. Location URI expiration: When a location URI has a limited 412 validity interval, its lifetime MUST be indicated. 414 Motivation: A location URI may not intend to represent a location 415 forever, and the identifier eventually may need to be recycled, or 416 may be subject to a specific window of validity, after which the 417 location reference fails to yield a location, or the location is 418 determined to be kept confidential. 420 C3. Location URI cancellation: The location configuration protocol 421 MUST support the ability to request a cancellation of a specific 422 location URI. 424 Motivation: If the client determines that in its best interest to 425 destroy the ability for a location URI to effectively be used to 426 dereference a location, then there should be a way to nullify the 427 location URI. 429 C4. Location Information Masking: The location URI MUST, through 430 randomization and uniqueness, ensure that the location URI does 431 not contain location information specific components. 433 Motivation: It is important to keep any location information 434 masked from a casual observing node. 436 C5. User Identity Protection: The location URI MUST NOT contain 437 information that identifies the user or device. Examples include 438 phone extensions, badge numbers, first or last names. 440 Motivation: It is important to protect caller identity or contact 441 address from being included in the form of the location URI itself 442 when it is generated. 444 C6. Reuse indicator: There SHOULD be a way to allow a client to 445 control whether a location URI can be resolved once only, or 446 multiple times. 448 Motivation: The client requesting a location URI may request a 449 location URI which has a 'one-time-use' only characteristic, as 450 opposed to a location URI having multiple reuse capability. 452 C7. Selective disclosure: The location configuration protocol MUST 453 provide a mechanism to control what information is being disclosed 454 about the Target. 456 Motivation: The Rule Maker has to be in control of how much 457 information is revealed during the dereferencing step as part of 458 the privacy features. 460 C8. Location URI Not guessable: As a default, the location 461 configuration protocol MUST return location URIs that are random 462 and unique throughout the indicated lifetime. A location URI with 463 128-bits of randomness is RECOMMENDED. 465 Motivation: Location URIs should be constructed in such a way that 466 an adversary cannot guess them and dereference them without having 467 ever obtained them from the Target. 469 C9. Location URI Optional: In the case of user-provided 470 authorization policies, where anonymous or non-guessable location 471 URIs are not warranted, the location configuration protocol MAY 472 support optional location URI forms, (such as embedded location 473 information within the location URI). 475 Motivation: Users don't always have such strict privacy 476 requirements, but may opt to specify their own location URI, or 477 components thereof. 479 4.2. Requirements for a Location Dereference Protocol 481 Below, we summarize high-level design requirements needed for a 482 location-by-reference mechanism as used within the location 483 dereference protocol. 485 D1. Location URI support: The location dereference protocol MUST 486 support a location reference in URI form. 488 Motivation: It is required that there be consistency of use 489 between location URI formats used in an configuration protocol and 490 those used by a dereference protocol. 492 D2. Authentication: The location dereference protocol MUST include 493 mechanisms to authenticate both the client and the server. 495 Motivation: Although the implementations must support 496 authentication of both parties, any given transaction has the 497 option not to authenticate one or both parties. 499 D3. Dereferenced Location Form: The value returned by the 500 dereference protocol MUST contain a well-formed PIDF-LO document. 502 Motivation: This is in order to ensure that adequate privacy rules 503 can be adhered to, since the PIDF-LO format comprises the 504 necessary structures to maintain location privacy. 506 D4. Location URI Repeated Use: The location dereference protocol 507 MUST support the ability for the same location URI to be resolved 508 more than once, based on dereference server configuration. 510 Motivation: Through dereference server configuration, for example, 511 it may be useful to not only allow more than one dereference 512 request, but, in some cases, to also limit the number of 513 dereferencing attempts by a client. 515 D5. Location Confidentiality: The location dereference protocol MUST 516 support confidentiality protection of messages sent between the 517 Location Recipient and the location server. 519 Motivation: The location URI indicates what type of security 520 protocol has to be provided. An example is a location URI using a 521 HTTPS URI scheme. 523 5. Security Considerations 525 The method of constructing the location URI to include randomized 526 components helps to prevent adversaries from obtaining location 527 information without ever retrieving a location URI. In the 528 possession model, a location URI, regardless of its construction, if 529 made publically available, implies no safeguard against anyone being 530 able to dereference and get the location. Care has to be paid when 531 distribution such a location URI to the trusted location recipients. 532 When this aspect is of concern then the authorization model has to be 533 chosen. Even in this model care has to be taken on how to construct 534 the authorization policies to ensure that only those parties have 535 access to location information that are considered trustworthy enough 536 to enforce the basic rule set that is attached to location 537 information in a PIDF-LO document. 539 Any location URI, by necessity, indicates the server (name) that 540 hosts the location information. Knowledge of the server in some 541 specific domain could therefore reveal something about the location 542 of the Target. This kind of threat may be mitigated somewhat by 543 introducing another layer of indirection: namely the use of a 544 (remote) presence server. 546 6. IANA Considerations 548 This document does not require actions by the IANA. 550 7. Acknowledgements 552 I would like to thank the present IETF GEOPRIV working group chairs, 553 Robert Sparks and Richard Barnes, past chairs, Andy Newton, Allison 554 Mankin and Randall Gellens, for establishing the design team which 555 initiated this requirements work. I'd also like to thank those 556 original design team participants for their inputs, comments, and 557 insightful reviews. The design team included the following folks: 558 Richard Barnes; Martin Dawson; Keith Drage; Randall Gellens; Ted 559 Hardie; Cullen Jennings; Marc Linsner; Rohan Mahy; Allison Mankin; 560 Roger Marshall; Andrew Newton; Jon Peterson; James M. Polk; Brian 561 Rosen; John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes 562 Tschofenig; Martin Thomson; and James Winterbottom. 564 8. References 566 8.1. Normative References 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, March 1997. 571 8.2. Informative References 573 [I-D.ietf-geopriv-dhcp-lbyr-uri-option] 574 Polk, J., "Dynamic Host Configuration Protocol (DHCP) 575 Option for a Location Uniform Resource Identifier (URI)", 576 draft-ietf-geopriv-dhcp-lbyr-uri-option-03 (work in 577 progress), November 2008. 579 [I-D.ietf-geopriv-http-location-delivery] 580 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 581 "HTTP Enabled Location Delivery (HELD)", 582 draft-ietf-geopriv-http-location-delivery-13 (work in 583 progress), February 2009. 585 [I-D.ietf-geopriv-l7-lcp-ps] 586 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 587 Location Configuration Protocol; Problem Statement and 588 Requirements", draft-ietf-geopriv-l7-lcp-ps-09 (work in 589 progress), February 2009. 591 [I-D.ietf-geopriv-loc-filters] 592 Mahy, R. and B. Rosen, "A Document Format for Filtering 593 and Reporting Location Notications in the Presence 594 Information Document Format Location Object (PIDF-LO)", 595 draft-ietf-geopriv-loc-filters-03 (work in progress), 596 November 2008. 598 [I-D.ietf-sip-location-conveyance] 599 Polk, J. and B. Rosen, "Location Conveyance for the 600 Session Initiation Protocol", 601 draft-ietf-sip-location-conveyance-12 (work in progress), 602 November 2008. 604 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 605 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 607 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 608 Format", RFC 4119, December 2005. 610 Appendix A. Change log 612 Changes to this draft in comparison to the previous version (-07 vs. 613 -06): 615 1. deleted text and reference to ID.ietf-geopriv-policy (Thomson 616 2/26/09). 618 2. replaced text in Introduction referring to SIP (Thomson). 620 3. reworded section 3.4 on location URI authorization (Thomson). 622 Changes to this draft in comparison to the previous version (-06 vs. 623 -05): 625 1. replaced diagram (Thomson). 627 2. redefined term, "Location-by-Value" (1/08/2009, Tschofenig). 629 3. redefined term, "Location-by-Reference" (Tschofenig). 631 4. redefined term, "Location Dereference Protocol" (Tschofenig). 633 5. reworded term, "Location URI" (Tschofenig). 635 6. modified steps, text, Figure 1 (Tschofenig). 637 7. deleted redundant text in paragraph, "Because a location URI..." 638 (Tschofenig). 640 8. modified Authorization model text paragraphs, (Tschofenig). 642 9. added qualifying sentence before sentence, "Thus, obfuscating the 643 location URI..." (Marshall based on question from Tschofenig). 645 10. replaced diagram with one that contains both "LIS - LS" labeling 646 (Martin). 648 11. added text to Introduction that a location URI is dynamic and may 649 change over time (Martin, 2/23/09). 651 12. section 3 text changed to make the makeup of a location URI less 652 stringent as to being guessable, etc. (Martin, 2/23/09). 654 13. reordered "C" requirements from those remaining: C8-->C7; 655 C9-->C8; C10-->C9. 657 14. reordered "D" requirements: D3-->D2; D4-->D3; D5-->D4; D10-->D5. 659 15. section-ized the overview, (section 3), for pointing to (Martin, 660 2/23/09) 662 16. edited section 3.4 to make clear that some default requirements 663 may be relaxed ONLY if explicit local policy exists. (RSM based on 664 Martin, 2/23/09). 666 17. added an citation for the geopriv-policy draft reference. 668 18. reworded first couple of paragraphs of Introduction for 669 readability. 671 Changes to this draft in comparison to the previous version (-05 vs. 672 -04): 674 1. Fixed minor spelilng errors. 676 Changes to this draft in comparison to the previous version (-04 vs. 677 -03): 679 1. Changed wording of section 1 "Introduction", (Thomson ~ 7/09/08 680 list comments). 682 1. Relocated text in section 3 "Overview of Location-by-Reference" 683 to section 1 (Intro), (Thomson comments). 685 2. (Sect. 3, con't) Fixed Figure 1. Label, based on (Thomson 686 comments). 688 3. Fixed minor spelling errors, incl. Note B., Note C., etc., based 689 on (Thomson comments). 691 4. Added some qualifying text (security) around possession model, 692 based on (Thomson comments). 694 5. Replaced "use type" labels with "authorization models", "access 695 authorization model", and "possession authorization model", (Thomson 696 comments). 698 6. Changed the entity role of applying security from LIS (Server- 699 side authentication), to the Rule Maker (owner/Target) providing 700 policies to the LIS, (Thomson comments). 702 7. Changed requirement C3 to a MUST, (Thomson comments). 704 8. Added new requirement, C12, "C12. Location URI Lifetime:" as a 705 SHOULD for all, and MUST for possession auth model, (Thomson 706 comments). 708 9. Changed name of requirement C8 to "Location Only", (Thomson 709 comments). 711 10. Reworded C7 and D6 to be less implementation specific, (Thomson 712 comments). 714 11. Changed requirements C11, D11 to SHOULD, (Thomson comments). 716 12. (Section 5:) Removed lead in sentence for readibility, (Thomson 717 comments). 719 13. Remove "pawn ticket" reference - replaced with "possession 720 authorization model", (Thomson comments). 722 14. Added new paragraph to the security section (Thomson, 7/09/08 723 comments). 725 15. Corrected other minor spelling and wording errors and 726 deficiencies (refer to diff 04/03) (-Editor). 728 Changes to this draft in comparison to the previous version (-03 vs. 729 -02): 731 1. Changed wording of section 3 "Overview of Location-by-Reference" 732 (Polk, Thomson, Winterbottom ~ 4/1/08 list comments). 734 2. Added new requirement C4. "Location Information Masking:", based 735 on (Thomson ~4/1/08 list comment). 737 3. Added new requirement C11. "Location URI Use Type:", based on 738 (~4/1/08 list comments). 740 4. Added new requirement D11. "Location URI Use Type:", for deref. 741 based on (~4/1/08 list comments). 743 5. Replaced requirement D8. "Location URI Non-Anonymized" with 744 "Location Information Masking:". 746 Changes to this draft in comparison to the previous version (-02 vs. 747 -01): 749 1. Reworded Introduction (Barnes 12/6 list comments). 751 2. Changed name of "Basic Actors" section to "Overview of Location 752 by Reference" (Barnes). 754 3. Keeping the LCP term away (for now) since it is used as Link 755 Control Protocol elsewhere (IETF). 757 4. Changed formatting of Terminology section (Barnes). 759 5. Requirement C2. changed to indicate that if the URI has a 760 lifetime, it has to have an expiry (Barnes) 762 6. C7. Changed title and wording based on suggested text and dhcp- 763 uri-option example (Polk). 765 7. The new C2 req. describing valid-for, was also added into the 766 deref section, as D6 768 8. Changed C4 based on much list discussion - replaced by 3 new 769 requirements... 771 9. Reworded C5 based on the follow-on C4 thread/discussion on list 772 (~2/18). 774 10. Changed wording of D3 based on suggestion (Barnes). 776 11. Reworded D4 per suggestion (Barnes). 778 12. Changed D5 based on comment (Barnes), and additional title and 779 text changes for clarity. 781 13. Added D9 and D10 per Richard Barnes suggestions - something 782 needed in addition to his own security doc. 784 14. Deleted reference to individual Barnes-loc-sec draft per wg list 785 suggestion (Barnes), but need more text for this draft's security 786 section. 788 Author's Address 790 Roger Marshall (editor) 791 TeleCommunication Systems, Inc. 792 2401 Elliott Avenue 793 2nd Floor 794 Seattle, WA 98121 795 US 797 Phone: +1 206 792 2424 798 Email: rmarshall@telecomsys.com 799 URI: http://www.telecomsys.com