idnits 2.17.1 draft-ietf-geopriv-lbyr-requirements-06.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 152 has weird spacing: '...ocation infor...' == Line 156 has weird spacing: '...llation reque...' -- 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 5535 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-12 == 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 (-27) exists of draft-ietf-geopriv-policy-20 == 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-06 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 Models . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 20 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 83 1. Introduction 85 All location-based services rely on ready access to location 86 information. Within this document, the use of location information 87 is constrained according to specific policies included in 88 [I-D.ietf-geopriv-policy]. Using location information according to 89 these policies can be done one of two ways, either in a direct, 90 Location-by-Value (LbyV) approach, or using an indirect, Location-by- 91 Reference (LbyR) model. Despite the standard technique of passing 92 location directly in SIP, in the form of a PIDF-LO, (Presence 93 Information Document Format - Location Object, [RFC4119]), there are 94 some cases where LbyV is not desirable. In cases where additional 95 location requirements apply to specific applications and/or location 96 architectures, and when can only be met by an indirect location 97 mechanism, there is the Location-by-Reference model. This document 98 provides a list of requirements for use with the LbyR approach, and 99 leaves the LbyV model as explicitly out of scope. 101 As justification for a LbyR model, consider the following. In some 102 mobile networks it is not efficient for the end host to periodically 103 query the LIS for up-to-date location information. This is 104 especially the case when power is a constraint or when a location 105 update is not immediately needed. Furthermore, the end host might 106 want to delegate the task of retrieving and publishing location 107 information to a third party, such as to a presence server. 108 Additionally, in some deployments, the network operator may not want 109 to make location information widely available. These kinds of 110 location scenarios, and more, such as whether a Target is mobile and 111 whether a mobile device needs to be located on demand or according to 112 some pre-determined interval, together form the basis of motivation 113 for the LbyR concept. 115 The concept of an LbyR mechanism is simple. It is made up of a 116 pointer which makes reference to the actual location information by 117 some combination of key value and fully qualified domain name. This 118 combination of data elements, in the form of a URI, is referred to 119 specifically as a "location URI". 121 A location URI is thought of as a dynamic reference to the current 122 location of the Target, yet the location value might remain unchanged 123 over specific intervals of time for several reasons: 125 - Limitations in the process used to generate location information 126 mean that cached location might be used. 128 - Policy constraints that may dictate that the location provided 129 remains fixed over time for specified Location Recipients. Without 130 additional information, a Location Recipient cannot assume that the 131 location information provided by any location URI is static, and will 132 never change. 134 The LbyR mechanism works according to an information lifecycle. 135 Within this lifecycle, location URIs are considered temporary 136 identifiers, each undergoing the following uses: Creation; 137 Distribution; Conveyance; Dereference; and Termination. The use of a 138 location URI according to these various states is generally applied 139 in one of the following ways: 141 1. Creation of a location URI, within a location server, based on 142 some request for its creation. 144 2. Distribution of a location URI, via a Location Configuration 145 Protocol, between a target and a location server. 147 3. Conveyance, applied to LbyR, in SIP, is the transporting of the 148 location URI, in this case, between any successive signaling nodes. 150 4. Dereference of a location URI, a request/response between a 151 client having a location URI and a location server holding the 152 location information that the location URI references. 154 5. Termination of a location URI, either due to expiration or 155 cancellation within a location server, and which is based on a target 156 cancellation request or some other action, such as timer 157 expiration. 159 Note that this document makes no differentiation between a LS, per 160 [RFC3693], and a LIS, as shown in [I-D.ietf-geopriv-l7-lcp-ps]), but 161 may refer to either of them as a location server interchangeably. 163 Location determination, different than location configuration or 164 dereferencing, often includes topics related to manual provisioning 165 processes, automated location calculations based on a variety of 166 measurement techniques, and/or location transformations, (e.g., geo- 167 coding), and is beyond the scope of this document. 169 Location Conveyance for either LbyR or LbyV as defined within SIP 170 signaling is considered out of scope for this document (see 171 [I-D.ietf-sip-location-conveyance] for an explanation of location 172 conveyance for either LbyR or LbyV scenarios.) 174 Except for location conveyance, the above stages in the LbyR 175 lifecycle fall into one of two general categories of protocols, 176 either a Location Configuration Protocol or a Location Dereference 177 Protocol. The stages of LbyR Creation, Distribution, and 178 Termination, are each found within the set of Location Configuration 179 Protocols (LCP). The Dereference stage belongs solely to the set of 180 Location Dereference Protocols. 182 The issues around location configuration protocols have been 183 documented in a location configuration protocol problem statement and 184 requirements document [I-D.ietf-geopriv-l7-lcp-ps]. There are 185 currently several examples of a location configuration protocols 186 currently proposed, including, DHCP 187 [I-D.ietf-geopriv-dhcp-lbyr-uri-option], LLDP-MED, and HELD 188 [I-D.ietf-geopriv-http-location-delivery] protocols. 190 For dereferencing of a location URI, depending on the type of 191 reference used, such as a HTTP/HTTPS, or SIP Presence URI, different 192 operations can be performed. While an HTTP/HTTPS URI can be resolved 193 to location information, a SIP Presence URI provides further benefits 194 from the SUBSCRIBE/NOTIFY concept that can additionally be combined 195 with location filters [I-D.ietf-geopriv-loc-filters]. 197 The structure of this document includes terminology, Section 2, 198 followed by a discussion of the basic elements that surround how a 199 location URI is used. These elements, or actors, are discussed in an 200 overview section, Section 3, accompanied by a graph, associated 201 processing steps, and a brief discussion around the use, expiration, 202 authorization, and construction of location URIs. 204 Requirements are outlined accordingly, separated as location 205 configuration requirements, Section 4.1, and location dereference 206 requirements, Section 4.2. 208 2. Terminology 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in RFC 2119 [RFC2119]. 214 This document reuses the terminology of [RFC3693], such as Location 215 Server (LS), Location Recipient (LR), Rule Maker (RM), Target, 216 Location Generator (LG), Location Object (LO), and Using Protocol: 218 Location-by-Value (LbyV): Location information in the format of a 219 PIDF-LO (or related encoding). 221 Location-by-Reference (LbyR): A location URI pointing to location 222 information. 224 Location Configuration Protocol: A protocol which is used by a 225 client to acquire either location or a location URI from a 226 location configuration server, based on information unique to the 227 client. 229 Location Dereference Protocol: A protocol that is used by a client 230 to query a location server, based on the location URI input and 231 which returns location information. 233 Location URI: As defined within this document, an identifier that 234 serves as a pointer to a location information. A location URI is 235 provided by a location server, and is later used as input by a 236 dereference protocol to retrieve location information. 238 3. Overview of Location-by-Reference 240 This section describes the entities and interactions involved in the 241 LbyR model. 243 +---------+---------+ Location +-----------+ 244 | | | Dereference | Location | 245 | LIS - LS +---------------+ Recipient | 246 | | | Protocol | | 247 +----+----+----+----+ (3) +-----+-----+ 248 | * | 249 | Policy * | 250 Location | Exchange * | 251 Configuration | (*) * | Location 252 Protocol | +----+----+ | Conveyance 253 (1) | | Rule | | Protocol 254 | | Maker | | (2) 255 +----+----+ +---------+ | 256 | | | 257 | Target +-------------------------------+ 258 | | 259 +---------+ 261 Figure 1: Location Reference Entities and Interactions 263 Figure 1 shows the assumed communication model for both a layer 7 264 location configuration protocol and a location dereference protocol. 266 1. The Target (a Device) uses a Location Configuration Protocol to 267 acquire a location reference from a LIS, which acts as (or is able to 268 access) an LS. 270 In the case where the Target is also a Rule Maker, the location 271 configuration protocol can be used to convey policy information. In 272 the case where possession of a location URI is the only required form 273 of authorization, (see, Section 3.3), a policy is implied whereby any 274 requester is granted access to location information. This does not 275 preclude other means of providing authorization policies. 277 A Target could also acquire a location URI from the LS directly using 278 alternative means, for example, the acquisition of a presence AoR to 279 be used for location information, in which case, it could be regarded 280 as a location URI. 282 2. The Target conveys the location URI to the Location Recipient 283 (interface out of scope). 285 3. The Location Recipient dereferences the location URI to acquire 286 location information from the LS. 288 The LS controls access to location information based on the policy 289 provided by the Rule Maker. 291 Note A. There is no requirement for using the same protocol in (1) 292 and (3). 294 Note B. Figure 1 includes the interaction between the owner of the 295 Target and the LIS to obtain Rule Maker policies. This interaction 296 needs to happen before the LIS will authorize anything other than 297 what is allowed based on default policies in order to dereference a 298 location request of the Target. This is communications path, (*), 299 out of scope for this document. 301 Note C. The Target might take on the role of the Location Recipient, 302 in which case it could attempt to dereference the location URI 303 itself, in order to obtain its own location information. 305 3.1. Location URI Usage 307 An example scenario of how the above might work, is where the Target 308 obtains a location URI in the form of a subscription URI (e.g., a SIP 309 URI) via a location configuration protocol. In this case, the Target 310 is the same as the Recipient, therefore the Target can subscribe to 311 the URI in order to be notified of its current location based on 312 subscription parameters. In the example, parameters are set up for a 313 specific Target/Recipient along with an expressed geospatial 314 boundary, so that the Target/Recipient receives an updated location 315 notification once the boundary is crossed (see 316 [I-D.ietf-geopriv-loc-filters]). 318 3.2. Location URI Expiration 320 Location URIs may have an expiry associated with them, primarily for 321 security considerations, and generally so that the LIS is able to 322 keep track of the location URIs that have been handed out, to know 323 whether a location URI is still valid once the LIS receives it in a 324 request, and in order for a recipient of such a URI from being able 325 to (in some cases) permanently track a host. Expiration of a 326 location URI limits the time that accidental leaking of a location 327 URI introduces. Other justifications for expiration of location URIs 328 include the ability for a LIS to do garbage collection. 330 3.3. Location URI Authorization Models 332 How a location URI is will ultimately be used within the dereference 333 step is an important consideration at the time that the location URI 334 is requested via a location configuration protocol. Since 335 dereferencing of location URIs could be done according to one of two 336 authorization models, either an "access control authorization model" 337 or a "possession authorization model", it is important that location 338 configuration protocols indicate the type of a location URI that is 339 being requested, as well as which type is returned). 341 1. Access Control Authorization. 343 Access to the location URI is limited by policy. In this model it 344 is assumed that the Rule Maker provides authorization policies to 345 the LIS and these policies are attached to a location URI and 346 control the dereferencing process. 348 2. Possession Authorization. 350 The possession authorization model is described as not having 351 policies associated to the location URI aside from only possessing 352 the location URI itself. In this case, possession implies 353 authorization. Access to the location URI is limited by 354 distribution only. Whoever possesses the location URI has the 355 ability to dereference it. Possession authorization models may be 356 used within specified domains only, or might be used across wide 357 open public networks. 359 3.4. Location URI Construction 361 Depending on local policy, a location URI may be constructed in such 362 a way as to make it difficult to guess. Accordingly, the form of the 363 URI is then constrained by the degree of randomness and uniqueness 364 applied to it. In this case, it may be important to protect the 365 actual location information from inspection by an intermediate node. 366 Construction of a location URI in such a way as to not reveal any 367 domain, user, or device specific information, with the goal of making 368 the location URI appear bland, uninteresting, and generic, may be 369 helpful to some degree in order to keep location information more 370 difficult to detect. Thus, obfuscating the location URI in this way 371 may provide some level of safeguard against the undetected stripping 372 off of what would otherwise be evident location information, since it 373 forces a dereference operation at the location dereference server, an 374 important step for the purpose of providing statistics, audit trails, 375 and general logging for many different kinds of location based 376 services. 378 Where local policy explicitly relaxes the limitations around the 379 information provided within the structure of the location URI itself, 380 default restrictions may not exist. Under such conditions, it may be 381 reasonable, for example, to have the location URI be the AoR itself. 383 4. High-Level Requirements 385 This document outlines the requirements for an Location by Reference 386 mechanism which can be used by a number of underlying protocols. 387 Requirements here address two general types of such protocols, a 388 general location configuration protocol, and a general location 389 dereferencing protocol. 391 The requirements are broken into two sections. 393 4.1. Requirements for a Location Configuration Protocol 395 Below, we summarize high-level design requirements needed for a 396 location-by-reference mechanism as used within the location 397 configuration protocol. 399 C1. Location URI support: The location configuration protocol MUST 400 support a location reference in URI form. 402 Motivation: A standardized location reference mechanism increases 403 interoperability. 405 C2. Location URI expiration: When a location URI has a limited 406 validity interval, its lifetime MUST be indicated. 408 Motivation: A location URI may not intend to represent a location 409 forever, and the identifier eventually may need to be recycled, or 410 may be subject to a specific window of validity, after which the 411 location reference fails to yield a location, or the location is 412 determined to be kept confidential. 414 C3. Location URI cancellation: The location configuration protocol 415 MUST support the ability to request a cancellation of a specific 416 location URI. 418 Motivation: If the client determines that in its best interest to 419 destroy the ability for a location URI to effectively be used to 420 dereference a location, then there should be a way to nullify the 421 location URI. 423 C4. Location Information Masking: The location URI MUST, through 424 randomization and uniqueness, ensure that the location URI does 425 not contain location information specific components. 427 Motivation: It is important to keep any location information 428 masked from a casual observing node. 430 C5. User Identity Protection: The location URI MUST NOT contain 431 information that identifies the user or device. Examples include 432 phone extensions, badge numbers, first or last names. 434 Motivation: It is important to protect caller identity or contact 435 address from being included in the form of the location URI itself 436 when it is generated. 438 C6. Reuse indicator: There SHOULD be a way to allow a client to 439 control whether a location URI can be resolved once only, or 440 multiple times. 442 Motivation: The client requesting a location URI may request a 443 location URI which has a 'one-time-use' only characteristic, as 444 opposed to a location URI having multiple reuse capability. 446 C7. Selective disclosure: The location configuration protocol MUST 447 provide a mechanism to control what information is being disclosed 448 about the Target. 450 Motivation: The Rule Maker has to be in control of how much 451 information is revealed during the dereferencing step as part of 452 the privacy features. 454 C8. Location URI Not guessable: As a default, the location 455 configuration protocol MUST return location URIs that are random 456 and unique throughout the indicated lifetime. A location URI with 457 128-bits of randomness is RECOMMENDED. 459 Motivation: Location URIs should be constructed in such a way that 460 an adversary cannot guess them and dereference them without having 461 ever obtained them from the Target. 463 C9. Location URI Optional: In the case of user-provided 464 authorization policies, where anonymous or non-guessable location 465 URIs are not warranted, the location configuration protocol MAY 466 support optional location URI forms, (such as embedded location 467 information within the location URI). 469 Motivation: Users don't always have such strict privacy 470 requirements, but may opt to specify their own location URI, or 471 components thereof. 473 4.2. Requirements for a Location Dereference Protocol 475 Below, we summarize high-level design requirements needed for a 476 location-by-reference mechanism as used within the location 477 dereference protocol. 479 D1. Location URI support: The location dereference protocol MUST 480 support a location reference in URI form. 482 Motivation: It is required that there be consistency of use 483 between location URI formats used in an configuration protocol and 484 those used by a dereference protocol. 486 D2. Authentication: The location dereference protocol MUST include 487 mechanisms to authenticate both the client and the server. 489 Motivation: Although the implementations must support 490 authentication of both parties, any given transaction has the 491 option not to authenticate one or both parties. 493 D3. Dereferenced Location Form: The value returned by the 494 dereference protocol MUST contain a well-formed PIDF-LO document. 496 Motivation: This is in order to ensure that adequate privacy rules 497 can be adhered to, since the PIDF-LO format comprises the 498 necessary structures to maintain location privacy. 500 D4. Location URI Repeated Use: The location dereference protocol 501 MUST support the ability for the same location URI to be resolved 502 more than once, based on dereference server configuration. 504 Motivation: Through dereference server configuration, for example, 505 it may be useful to not only allow more than one dereference 506 request, but, in some cases, to also limit the number of 507 dereferencing attempts by a client. 509 D5. Location Confidentiality: The location dereference protocol MUST 510 support confidentiality protection of messages sent between the 511 Location Recipient and the location server. 513 Motivation: The location URI indicates what type of security 514 protocol has to be provided. An example is a location URI using a 515 HTTPS URI scheme. 517 5. Security Considerations 519 The method of constructing the location URI to include randomized 520 components helps to prevent adversaries from obtaining location 521 information without ever retrieving a location URI. In the 522 possession model, a location URI, regardless of its construction, if 523 made publically available, implies no safeguard against anyone being 524 able to dereference and get the location. Care has to be paid when 525 distribution such a location URI to the trusted location recipients. 526 When this aspect is of concern then the authorization model has to be 527 chosen. Even in this model care has to be taken on how to construct 528 the authorization policies to ensure that only those parties have 529 access to location information that are considered trustworthy enough 530 to enforce the basic rule set that is attached to location 531 information in a PIDF-LO document. 533 Any location URI, by necessity, indicates the server (name) that 534 hosts the location information. Knowledge of the server in some 535 specific domain could therefore reveal something about the location 536 of the Target. This kind of threat may be mitigated somewhat by 537 introducing another layer of indirection: namely the use of a 538 (remote) presence server. 540 6. IANA Considerations 542 This document does not require actions by the IANA. 544 7. Acknowledgements 546 I would like to thank the present IETF GEOPRIV working group chairs, 547 Robert Sparks and Richard Barnes, past chairs, Andy Newton, Allison 548 Mankin and Randall Gellens, for establishing the design team which 549 initiated this requirements work. I'd also like to thank those 550 original design team participants for their inputs, comments, and 551 insightful reviews. The design team included the following folks: 552 Richard Barnes; Martin Dawson; Keith Drage; Randall Gellens; Ted 553 Hardie; Cullen Jennings; Marc Linsner; Rohan Mahy; Allison Mankin; 554 Roger Marshall; Andrew Newton; Jon Peterson; James M. Polk; Brian 555 Rosen; John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes 556 Tschofenig; Martin Thomson; and James Winterbottom. 558 8. References 560 8.1. Normative References 562 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 563 Requirement Levels", BCP 14, RFC 2119, March 1997. 565 8.2. Informative References 567 [I-D.ietf-geopriv-dhcp-lbyr-uri-option] 568 Polk, J., "Dynamic Host Configuration Protocol (DHCP) 569 Option for a Location Uniform Resource Identifier (URI)", 570 draft-ietf-geopriv-dhcp-lbyr-uri-option-03 (work in 571 progress), November 2008. 573 [I-D.ietf-geopriv-http-location-delivery] 574 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 575 "HTTP Enabled Location Delivery (HELD)", 576 draft-ietf-geopriv-http-location-delivery-12 (work in 577 progress), January 2009. 579 [I-D.ietf-geopriv-l7-lcp-ps] 580 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 581 Location Configuration Protocol; Problem Statement and 582 Requirements", draft-ietf-geopriv-l7-lcp-ps-09 (work in 583 progress), February 2009. 585 [I-D.ietf-geopriv-loc-filters] 586 Mahy, R. and B. Rosen, "A Document Format for Filtering 587 and Reporting Location Notications in the Presence 588 Information Document Format Location Object (PIDF-LO)", 589 draft-ietf-geopriv-loc-filters-03 (work in progress), 590 November 2008. 592 [I-D.ietf-geopriv-policy] 593 Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 594 and J. Polk, "Geolocation Policy: A Document Format for 595 Expressing Privacy Preferences for Location Information", 596 draft-ietf-geopriv-policy-20 (work in progress), 597 February 2009. 599 [I-D.ietf-sip-location-conveyance] 600 Polk, J. and B. Rosen, "Location Conveyance for the 601 Session Initiation Protocol", 602 draft-ietf-sip-location-conveyance-12 (work in progress), 603 November 2008. 605 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 606 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 608 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 609 Format", RFC 4119, December 2005. 611 Appendix A. Change log 613 Changes to this draft in comparison to the previous version (-06 vs. 614 -05): 616 1. replaced diagram (Thomson). 618 2. redefined term, "Location-by-Value" (1/08/2009, Tschofenig). 620 3. redefined term, "Location-by-Reference" (Tschofenig). 622 4. redefined term, "Location Dereference Protocol" (Tschofenig). 624 5. reworded term, "Location URI" (Tschofenig). 626 6. modified steps, text, Figure 1 (Tschofenig). 628 7. deleted redundant text in paragraph, "Because a location URI..." 629 (Tschofenig). 631 8. modified Authorization model text paragraphs, (Tschofenig). 633 9. added qualifying sentence before sentence, "Thus, obfuscating the 634 location URI..." (Marshall based on question from Tschofenig). 636 10. replaced diagram with one that contains both "LIS - LS" labeling 637 (Martin). 639 11. added text to Introduction that a location URI is dynamic and may 640 change over time (Martin, 2/23/09). 642 12. section 3 text changed to make the makeup of a location URI less 643 stringent as to being guessable, etc. (Martin, 2/23/09). 645 13. reordered "C" requirements from those remaining: C8-->C7; 646 C9-->C8; C10-->C9. 648 14. reordered "D" requirements: D3-->D2; D4-->D3; D5-->D4; D10-->D5. 650 15. section-ized the overview, (section 3), for pointing to (Martin, 651 2/23/09) 653 16. edited section 3.4 to make clear that some default requirements 654 may be relaxed ONLY if explicit local policy exists. (RSM based on 655 Martin, 2/23/09). 657 17. added an citation for the geopriv-policy draft reference. 659 18. reworded first couple of paragraphs of Introduction for 660 readability. 662 Changes to this draft in comparison to the previous version (-05 vs. 663 -04): 665 1. Fixed minor spelilng errors. 667 Changes to this draft in comparison to the previous version (-04 vs. 668 -03): 670 1. Changed wording of section 1 "Introduction", (Thomson ~ 7/09/08 671 list comments). 673 1. Relocated text in section 3 "Overview of Location-by-Reference" 674 to section 1 (Intro), (Thomson comments). 676 2. (Sect. 3, con't) Fixed Figure 1. Label, based on (Thomson 677 comments). 679 3. Fixed minor spelling errors, incl. Note B., Note C., etc., based 680 on (Thomson comments). 682 4. Added some qualifying text (security) around possession model, 683 based on (Thomson comments). 685 5. Replaced "use type" labels with "authorization models", "access 686 authorization model", and "possession authorization model", (Thomson 687 comments). 689 6. Changed the entity role of applying security from LIS (Server- 690 side authentication), to the Rule Maker (owner/Target) providing 691 policies to the LIS, (Thomson comments). 693 7. Changed requirement C3 to a MUST, (Thomson comments). 695 8. Added new requirement, C12, "C12. Location URI Lifetime:" as a 696 SHOULD for all, and MUST for possession auth model, (Thomson 697 comments). 699 9. Changed name of requirement C8 to "Location Only", (Thomson 700 comments). 702 10. Reworded C7 and D6 to be less implementation specific, (Thomson 703 comments). 705 11. Changed requirements C11, D11 to SHOULD, (Thomson comments). 707 12. (Section 5:) Removed lead in sentence for readibility, (Thomson 708 comments). 710 13. Remove "pawn ticket" reference - replaced with "possession 711 authorization model", (Thomson comments). 713 14. Added new paragraph to the security section (Thomson, 7/09/08 714 comments). 716 15. Corrected other minor spelling and wording errors and 717 deficiencies (refer to diff 04/03) (-Editor). 719 Changes to this draft in comparison to the previous version (-03 vs. 720 -02): 722 1. Changed wording of section 3 "Overview of Location-by-Reference" 723 (Polk, Thomson, Winterbottom ~ 4/1/08 list comments). 725 2. Added new requirement C4. "Location Information Masking:", based 726 on (Thomson ~4/1/08 list comment). 728 3. Added new requirement C11. "Location URI Use Type:", based on 729 (~4/1/08 list comments). 731 4. Added new requirement D11. "Location URI Use Type:", for deref. 732 based on (~4/1/08 list comments). 734 5. Replaced requirement D8. "Location URI Non-Anonymized" with 735 "Location Information Masking:". 737 Changes to this draft in comparison to the previous version (-02 vs. 738 -01): 740 1. Reworded Introduction (Barnes 12/6 list comments). 742 2. Changed name of "Basic Actors" section to "Overview of Location 743 by Reference" (Barnes). 745 3. Keeping the LCP term away (for now) since it is used as Link 746 Control Protocol elsewhere (IETF). 748 4. Changed formatting of Terminology section (Barnes). 750 5. Requirement C2. changed to indicate that if the URI has a 751 lifetime, it has to have an expiry (Barnes) 753 6. C7. Changed title and wording based on suggested text and dhcp- 754 uri-option example (Polk). 756 7. The new C2 req. describing valid-for, was also added into the 757 deref section, as D6 759 8. Changed C4 based on much list discussion - replaced by 3 new 760 requirements... 762 9. Reworded C5 based on the follow-on C4 thread/discussion on list 763 (~2/18). 765 10. Changed wording of D3 based on suggestion (Barnes). 767 11. Reworded D4 per suggestion (Barnes). 769 12. Changed D5 based on comment (Barnes), and additional title and 770 text changes for clarity. 772 13. Added D9 and D10 per Richard Barnes suggestions - something 773 needed in addition to his own security doc. 775 14. Deleted reference to individual Barnes-loc-sec draft per wg list 776 suggestion (Barnes), but need more text for this draft's security 777 section. 779 Author's Address 781 Roger Marshall (editor) 782 TeleCommunication Systems, Inc. 783 2401 Elliott Avenue 784 2nd Floor 785 Seattle, WA 98121 786 US 788 Phone: +1 206 792 2424 789 Email: rmarshall@telecomsys.com 790 URI: http://www.telecomsys.com