idnits 2.17.1 draft-ietf-geopriv-lbyr-requirements-08.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 151 has weird spacing: '...ocation infor...' == Line 155 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 (September 2, 2009) is 5343 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-05 == Outdated reference: A later version (-11) exists of draft-ietf-geopriv-loc-filters-05 Summary: 1 error (**), 0 flaws (~~), 5 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 September 2, 2009 5 Expires: March 6, 2010 7 Requirements for a Location-by-Reference Mechanism 8 draft-ietf-geopriv-lbyr-requirements-08 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 March 6, 2010. 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 Uniform Resource 60 Identifier (URI) to handle location information within signaling and 61 other Internet messaging. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3. Overview of Location-by-Reference . . . . . . . . . . . . . . 8 68 3.1. Location URI Usage . . . . . . . . . . . . . . . . . . . . 9 69 3.2. Location URI Expiration . . . . . . . . . . . . . . . . . 9 70 3.3. Location URI Authorization . . . . . . . . . . . . . . . . 10 71 3.4. Location URI Construction . . . . . . . . . . . . . . . . 10 72 4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 12 73 4.1. Requirements for a Location Configuration Protocol . . . . 12 74 4.2. Requirements for a Location Dereference Protocol . . . . . 14 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 81 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 20 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 1. Introduction 86 All location-based services rely on ready access to location 87 information. Using location information can be done one of two ways, 88 either in a direct, Location-by-Value (LbyV) approach, or using an 89 indirect, Location-by-Reference (LbyR) model. 91 For LbyV, location information is conveyed directly in the form of a 92 Presence Information Data Format-Location Object (PIDF-LO) 93 ([RFC4119]). Using LbyV might either be infeasible or undesirable in 94 some circumstances. There are cases where LbyR is better able to 95 address location requirements for a specific architecture or 96 application. This document provides a list of requirements for use 97 with the LbyR approach, and leaves the LbyV model explicitly out of 98 scope. 100 As justification for a LbyR model, consider the circumstance that in 101 some mobile networks it is not efficient for the end host to 102 periodically query the Location Information Server (LIS) for up-to- 103 date location information. This is especially the case when ower 104 availability is a constraint or when a location update is not 105 immediately needed. Furthermore, the end host might want to delegate 106 the task of retrieving and publishing location information to a third 107 party, such as to a presence server. Additionally, in some 108 deployments, the network operator may not want to make location 109 information widely available. These kinds of location scenarios form 110 the basis of motivation for the LbyR model. 112 The concept of an LbyR mechanism is simple. An LbyR is made up of a 113 URI scheme, a domain and a randomized component. This combination of 114 data elements, in the form of a URI, is referred to specifically as a 115 "location URI". 117 A location URI is thought of as a reference to the current location 118 of the Target, yet the location value might remain unchanged over 119 specific intervals of time for several reasons. The type of location 120 information returned as part of the dereferencing step may, for 121 example, be influenced by the following factors: 123 - Limitations in the process used to generate location information 124 mean that cached location might be used. 126 - Policy constraints that may dictate that the location provided 127 remains fixed over time for specified Location Recipients. Without 128 additional information, a Location Recipient cannot assume that the 129 location information provided by any location URI is static, and will 130 never change. 132 The LbyR mechanism works according to an information lifecycle. 133 Within this lifecycle, location URIs are considered temporary 134 identifiers, each undergoing the following uses: Creation; 135 Distribution; Conveyance; Dereference; and Termination. The use of a 136 location URI according to these various states is generally applied 137 in one of the following ways: 139 1. Creation of a location URI, within a location server, based on 140 some request for its creation. 142 2. Distribution of a location URI, via a Location Configuration 143 Protocol, between a Target and a location server. 145 3. Conveyance, applied to LbyR, for example in SIP (Session 146 Inititiation Protocol), is the transporting of the location URI, in 147 this case, between any successive signaling nodes. 149 4. Dereference of a location URI, a request/response between a 150 client having a location URI and a location server holding the 151 location information that the location URI references. 153 5. Termination of a location URI, either due to expiration or 154 cancellation within a location server, and which is based on a Target 155 cancellation request or some other action, such as timer 156 expiration. 158 Note that this document makes no differentiation between a Location 159 Server (LS), per [RFC3693], and a Location Information Server (LIS), 160 as shown in [I-D.ietf-geopriv-l7-lcp-ps]), but may refer to either of 161 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 documented location configuration 186 protocols, namely DHCP DHCP [I-D.ietf-geopriv-dhcp-lbyr-uri-option], 187 LLDP-MED [LLDP-MED], and HELD 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], 213 with the important qualification that, unless otherwise stated, these 214 terms apply to the design of the Location Configuration Protocol and 215 the Location Dereferencing Protocol, not its implementation or 216 application. 218 This document reuses the terminology of [RFC3693], such as Location 219 Server (LS), Location Recipient (LR), Rule Maker (RM), Target, 220 Location Object (LO). Furthermore, the following terms are defined 221 in this document: 223 Location-by-Value (LbyV): Using location information in the form of 224 a location object (LO), such as a PIDF-LO. 226 Location-by-Reference (LbyR): Representing location information 227 indirectly using a location URI. 229 Location Configuration Protocol: A protocol that is used by a Target 230 to acquire either location or a location URI from a location 231 configuration server, based on information unique to the Target. 233 Location Dereference Protocol: A protocol that is used by a client 234 to query a location server, based on the location URI input and 235 which returns location information. 237 Location URI: As defined within this document, an identifier that 238 serves as a reference to location information. A location URI is 239 provided by a location server, and is later used as input by a 240 dereference protocol to retrieve location information. 242 3. Overview of Location-by-Reference 244 This section describes the entities and interactions involved in the 245 LbyR model. 247 +---------+---------+ Location +-----------+ 248 | | | Dereference | Location | 249 | LIS - LS +---------------+ Recipient | 250 | | | Protocol | | 251 +----+----+----+----+ (3) +-----+-----+ 252 | * | 253 | Policy * | 254 Location | Exchange * | 255 Configuration | (*) * | Location 256 Protocol | +----+----+ | Conveyance 257 (1) | | Rule | | Protocol 258 | | Maker | | (2) 259 +----+----+ +---------+ | 260 | | | 261 | Target +-------------------------------+ 262 | | 263 +---------+ 265 Figure 1: Location Reference Entities and Interactions 267 Figure 1 shows the assumed communication model for both a layer 7 268 location configuration protocol and a location dereference protocol. 270 1. The Target (an end device) uses a Location Configuration Protocol 271 to acquire a location reference from a LIS, which acts as (or is able 272 to access) an LS. 274 In the case where the Target is also a Rule Maker, the location 275 configuration protocol can be used to convey policy information. In 276 the case where possession of a location URI is the only required form 277 of authorization, see Section 3.3, a policy is implied whereby any 278 requester is granted access to location information. This does not 279 preclude other means of providing authorization policies. 281 A Target could also acquire a location URI from the LS directly using 282 alternative means, for example, the acquisition of a presence AoR to 283 be used for location information, in which case, it could be regarded 284 as a location URI. 286 2. The Target conveys the location URI to the Location Recipient 287 (interface out of scope). 289 3. The Location Recipient dereferences the location URI to acquire 290 location information from the LS. 292 The LS controls access to location information based on the policy 293 provided by the Rule Maker. 295 Note A. There is no requirement for using the same protocol in (1) 296 and (3). 298 Note B. Figure 1 includes the interaction between the owner of the 299 Target and the LIS to obtain Rule Maker policies. This interaction 300 needs to happen before the LIS will authorize anything other than 301 what is allowed based on default policies in order to dereference a 302 location request of the Target. This communication path is out of 303 scope for this document. 305 Note C. The Target might take on the role of the Location Recipient, 306 in which case it could attempt to dereference the location URI 307 itself, in order to obtain its own location information. 309 3.1. Location URI Usage 311 An example scenario of how the above location configuration and 312 location dereference steps might work using SIP, is where a Target 313 obtains a location URI in the form of a subscription URI (e.g., a SIP 314 URI) via a location configuration protocol. In this case, the Target 315 is the same as the Recipient, therefore the Target can subscribe to 316 the URI in order to be notified of its current location based on 317 subscription parameters. In the example, parameters are set up for a 318 specific Target/Recipient along with an expressed geospatial 319 boundary, so that the Target/Recipient receives an updated location 320 notification once the boundary is crossed (see 321 [I-D.ietf-geopriv-loc-filters]). 323 3.2. Location URI Expiration 325 Location URIs may have an expiry associated with them, primarily for 326 security considerations, and generally so that the LIS is able to 327 keep track of the location URIs that have been handed out, to know 328 whether a location URI is still valid once the LIS receives it in a 329 request, and in order for a recipient of such a URI from being able 330 to (in some cases) permanently track a host. Expiration of a 331 location URI limits the time that accidental leaking of a location 332 URI introduces. Other justifications for expiration of location URIs 333 include the ability for a LIS to do garbage collection. 335 3.3. Location URI Authorization 337 How a location URI will ultimately be used within the dereference 338 step is an important consideration at the time the location URI is 339 requested via a location configuration protocol. The process of 340 dereferencing location URIs will be influenced by the specific 341 authorization model applied by the Location Information Server and 342 the URI scheme that indicates the protocol to be used to resolve the 343 reference to a location object. 345 Location URIs manifest themselves in a few different forms. The 346 different ways that a location URI can be represented is based on 347 local policy, and are depicted in the following four scenarios. 349 1. No specific information at all: As is typical, a location URI is 350 used to get location information. However, in this case, the URI 351 representation itself does not need to reveal any specific 352 information at all. Location information is acquired by the 353 dereferencing operation a location URI. 355 2. No Target specific information: By default, a location URI MUST 356 NOT reveal any information about the Target other than location 357 information. This is true for the URI itself, (or in the document 358 acquired by dereferencing), unless policy explicitly permits 359 otherwise. 361 3. Access control authorization model: If the "access control 362 authorization model" is used, the location URI MUST NOT include 363 any location information in its representation. Location URIs 364 operating under this model could be widely published to recipients 365 that are not authorized to receive this information. 367 4. Possession authorization model (the URI itself is a secret): If 368 the "possession authorization" model is used, the location URI is 369 confidential information shared between the LIS/LS, the Target and 370 all authorized Location Recipients. In this case, possession 371 implies authorization. Because knowledge of the location URI is 372 used to authenticate and authorize access to location information, 373 the URI needs to include sufficient randomness to make guessing 374 its value difficult. A possession model URI can include location 375 information in its representation. 377 3.4. Location URI Construction 379 Depending on local policy, a location URI may be constructed in such 380 a way as to make it difficult to guess. Accordingly, the form of the 381 URI is then constrained by the degree of randomness and uniqueness 382 applied to it. In this case, it may be important to protect the 383 actual location information from inspection by an intermediate node. 384 Construction of a location URI in such a way as to not reveal any 385 Target specific, (e.g., user or device), information, with the goal 386 of making the location URI appear bland, uninteresting, and generic, 387 may be helpful to some degree in order to keep location information 388 more difficult to detect. Thus, obfuscating the location URI in this 389 way may provide some level of safeguard against the undetected 390 stripping off of what would otherwise be evident location 391 information, since it forces a dereference operation at the location 392 dereference server, an important step for the purpose of providing 393 statistics, audit trails, and general logging for many different 394 kinds of location based services. 396 4. High-Level Requirements 398 This document outlines the requirements for an Location by Reference 399 mechanism which can be used by a number of underlying protocols. 400 Requirements here address two general types of such protocols, a 401 general location configuration protocol, and a general location 402 dereferencing protocol. 404 The requirements are broken into two sections. 406 4.1. Requirements for a Location Configuration Protocol 408 Below, we summarize high-level design requirements needed for a 409 location-by-reference mechanism as used within the location 410 configuration protocol. 412 C1. Location URI support: The location configuration protocol MUST 413 support a location reference in URI form. 415 Motivation: A standardized location reference mechanism increases 416 interoperability. 418 C2. Location URI expiration: When a location URI has a limited 419 validity interval, its lifetime MUST be indicated. 421 Motivation: A location URI may not intend to represent a location 422 forever, and the identifier eventually may need to be recycled, or 423 may be subject to a specific window of validity, after which the 424 location reference fails to yield a location, or the location is 425 determined to be kept confidential. 427 C3. Location URI cancellation: The location configuration protocol 428 MUST support the ability to request a cancellation of a specific 429 location URI. 431 Motivation: If the Target determines that in its best interest to 432 destroy the ability for a location URI to effectively be used to 433 dereference a location, then there should be a way to nullify the 434 location URI. 436 C4. Location Information Masking: The location URI MUST, through 437 randomization and uniqueness, ensure that the location URI does 438 not contain location information specific components. 440 Motivation: It is important to keep any location information 441 masked from a casual observing node. 443 C5. Target Identity Protection: The location URI MUST NOT contain 444 information that identifies the Target (e.g., user or device). 445 Examples include phone extensions, badge numbers, first or last 446 names. 448 Motivation: It is important to protect caller identity or contact 449 address from being included in the form of the location URI itself 450 when it is generated. 452 C6. Reuse indicator: There SHOULD be a way to allow a Target to 453 control whether a location URI can be resolved once only, or 454 multiple times. 456 Motivation: The Target requesting a location URI may request a 457 location URI which has a 'one-time-use' only characteristic, as 458 opposed to a location URI having multiple reuse capability. This 459 would allow the server to return an error with or without location 460 during the subsequent dereference operation. 462 C7. Selective disclosure: The location configuration protocol MUST 463 provide a mechanism to control what information is being disclosed 464 about the Target. 466 Motivation: The Rule Maker has to be in control of how much 467 information is revealed during the dereferencing step as part of 468 the privacy features. 470 C8. Location URI Not guessable: As a default, the location 471 configuration protocol MUST return location URIs that are random 472 and unique throughout the indicated lifetime. A location URI with 473 128-bits of randomness is RECOMMENDED. 475 Motivation: Location URIs should be constructed in such a way that 476 an adversary cannot guess them and dereference them without having 477 ever obtained them from the Target. 479 C9. Location URI Options: In the case of user-provided authorization 480 policies, where anonymous or non-guessable location URIs are not 481 warranted, the location configuration protocol MAY support a 482 variety of optional location URI conventions, as requested by a 483 Target to a location configuration server, (e.g., embedded 484 location information within the location URI). 486 Motivation: Users don't always have such strict privacy 487 requirements, but may opt to specify their own location URI, or 488 components to be included within a location URI. 490 4.2. Requirements for a Location Dereference Protocol 492 Below, we summarize high-level design requirements needed for a 493 location-by-reference mechanism as used within the location 494 dereference protocol. 496 D1. Location URI support: The location dereference protocol MUST 497 support a location reference in URI form. 499 Motivation: It is required that there be consistency of use 500 between location URI formats used in an configuration protocol and 501 those used by a dereference protocol. 503 D2. Authentication: The location dereference protocol MUST include 504 mechanisms to authenticate both the client and the server. 506 Motivation: Although the implementations must support 507 authentication of both parties, any given transaction has the 508 option not to authenticate one or both parties. 510 D3. Dereferenced Location Form: The value returned by the 511 dereference protocol MUST contain a well-formed PIDF-LO document. 513 Motivation: This is in order to ensure that adequate privacy rules 514 can be adhered to, since the PIDF-LO format comprises the 515 necessary structures to maintain location privacy. 517 D4. Location URI Repeated Use: The location dereference protocol 518 MUST support the ability for the same location URI to be resolved 519 more than once, based on dereference server configuration. 521 Motivation: Through dereference server configuration, for example, 522 it may be useful to not only allow more than one dereference 523 request, but, in some cases, to also limit the number of 524 dereferencing attempts by a client. 526 D5. Location Confidentiality: The location dereference protocol MUST 527 support confidentiality protection of messages sent between the 528 Location Recipient and the location server. 530 Motivation: The location URI indicates what type of security 531 protocol has to be provided. An example is a location URI using a 532 HTTPS URI scheme. 534 5. Security Considerations 536 The method of constructing the location URI to include randomized 537 components helps to prevent adversaries from obtaining location 538 information without ever retrieving a location URI. In the 539 possession model, a location URI, regardless of its construction, if 540 made publically available, implies no safeguard against anyone being 541 able to dereference and get the location. Care has to be paid when 542 distribution such a location URI to the trusted location recipients. 543 When this aspect is of concern then the authorization model has to be 544 chosen. Even in this model care has to be taken on how to construct 545 the authorization policies to ensure that only those parties have 546 access to location information that are considered trustworthy enough 547 to enforce the basic rule set that is attached to location 548 information in a PIDF-LO document. 550 Any location URI, by necessity, indicates the server (name) that 551 hosts the location information. Knowledge of the server in some 552 specific domain could therefore reveal something about the location 553 of the Target. This kind of threat may be mitigated somewhat by 554 introducing another layer of indirection: namely the use of a 555 (remote) presence server. 557 A covert channel for protocol message exchange is an important 558 consideration, given an example scenario where user A subscribes to 559 location information for user B, then every time A gets a location 560 update an (external) observer of the subscription notification may 561 know that B has moved. One mitigation to this is to have periodic 562 notification, so that user B may appear to have moved, even when 563 static. 565 6. IANA Considerations 567 This document does not require actions by the IANA. 569 7. Acknowledgements 571 I would like to thank the present IETF GEOPRIV working group chairs, 572 Alissa Cooper and Richard Barnes, past chairs, Robert Sparks, Andy 573 Newton, Allison Mankin and Randall Gellens, who established a design 574 team that initiated this requirements work. I'd also like to thank 575 those original design team participants for their inputs, comments, 576 and insightful reviews. The design team included the following 577 folks: Richard Barnes; Martin Dawson; Keith Drage; Randall Gellens; 578 Ted Hardie; Cullen Jennings; Marc Linsner; Rohan Mahy; Allison 579 Mankinl; Andrew Newton; Jon Peterson; James M. Polk; Brian Rosen; 580 John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes 581 Tschofenig; Martin Thomson; and James Winterbottom. 583 8. References 585 8.1. Normative References 587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 588 Requirement Levels", BCP 14, RFC 2119, March 1997. 590 8.2. Informative References 592 [I-D.ietf-geopriv-dhcp-lbyr-uri-option] 593 Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 594 and IPv6 Option for a Location Uniform Resource 595 Identifier (URI)", 596 draft-ietf-geopriv-dhcp-lbyr-uri-option-05 (work in 597 progress), July 2009. 599 [I-D.ietf-geopriv-http-location-delivery] 600 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 601 "HTTP Enabled Location Delivery (HELD)", 602 draft-ietf-geopriv-http-location-delivery-16 (work in 603 progress), August 2009. 605 [I-D.ietf-geopriv-l7-lcp-ps] 606 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 607 Location Configuration Protocol; Problem Statement and 608 Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in 609 progress), July 2009. 611 [I-D.ietf-geopriv-loc-filters] 612 Mahy, R., Rosen, B., and H. Tschofenig, "A Document Format 613 for Filtering and Reporting Location Notications in the 614 Presence Information Document Format Location Object 615 (PIDF-LO)", draft-ietf-geopriv-loc-filters-05 (work in 616 progress), July 2009. 618 [I-D.ietf-sip-location-conveyance] 619 Polk, J. and B. Rosen, "Location Conveyance for the 620 Session Initiation Protocol", 621 draft-ietf-sip-location-conveyance-13 (work in progress), 622 March 2009. 624 [LLDP-MED] 625 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 626 Endpoint Discovery". 628 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 629 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 631 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 632 Format", RFC 4119, December 2005. 634 Appendix A. Change log 636 Changes to this draft in comparison to the previous version (-08 vs. 637 -07), as part of the IESG review process: 639 1. changes sent 09/02/2009 based on IESG Security comments from 640 Hilarie Orman, 06/08/2009. 642 2. changes sent 09/02/2009 based on Operational Directorate comments 643 from Hannes Tschofenig, 06/11/2009. 645 Changes to this draft in comparison to the previous version (-07 vs. 646 -06): 648 1. deleted text and reference to ID.ietf-geopriv-policy (Thomson 649 2/26/09). 651 2. replaced text in Introduction referring to SIP (Thomson). 653 3. reworded section 3.4 on location URI authorization (Thomson). 655 Changes to this draft in comparison to the previous version (-06 vs. 656 -05): 658 1. replaced diagram (Thomson). 660 2. redefined term, "Location-by-Value" (1/08/2009, Tschofenig). 662 3. redefined term, "Location-by-Reference" (Tschofenig). 664 4. redefined term, "Location Dereference Protocol" (Tschofenig). 666 5. reworded term, "Location URI" (Tschofenig). 668 6. modified steps, text, Figure 1 (Tschofenig). 670 7. deleted redundant text in paragraph, "Because a location URI..." 671 (Tschofenig). 673 8. modified Authorization model text paragraphs, (Tschofenig). 675 9. added qualifying sentence before sentence, "Thus, obfuscating the 676 location URI..." (Marshall based on question from Tschofenig). 678 10. replaced diagram with one that contains both "LIS - LS" labeling 679 (Martin). 681 11. added text to Introduction that a location URI is dynamic and may 682 change over time (Martin, 2/23/09). 684 12. section 3 text changed to make the makeup of a location URI less 685 stringent as to being guessable, etc. (Martin, 2/23/09). 687 13. reordered "C" requirements from those remaining: C8-->C7; 688 C9-->C8; C10-->C9. 690 14. reordered "D" requirements: D3-->D2; D4-->D3; D5-->D4; D10-->D5. 692 15. section-ized the overview, (section 3), for pointing to (Martin, 693 2/23/09) 695 16. edited section 3.4 to make clear that some default requirements 696 may be relaxed ONLY if explicit local policy exists. (RSM based on 697 Martin, 2/23/09). 699 17. added an citation for the geopriv-policy draft reference. 701 18. reworded first couple of paragraphs of Introduction for 702 readability. 704 Changes to this draft in comparison to the previous version (-05 vs. 705 -04): 707 1. Fixed minor spelilng errors. 709 Changes to this draft in comparison to the previous version (-04 vs. 710 -03): 712 1. Changed wording of section 1 "Introduction", (Thomson ~ 7/09/08 713 list comments). 715 1. Relocated text in section 3 "Overview of Location-by-Reference" 716 to section 1 (Intro), (Thomson comments). 718 2. (Sect. 3, con't) Fixed Figure 1. Label, based on (Thomson 719 comments). 721 3. Fixed minor spelling errors, incl. Note B., Note C., etc., based 722 on (Thomson comments). 724 4. Added some qualifying text (security) around possession model, 725 based on (Thomson comments). 727 5. Replaced "use type" labels with "authorization models", "access 728 authorization model", and "possession authorization model", (Thomson 729 comments). 731 6. Changed the entity role of applying security from LIS (Server- 732 side authentication), to the Rule Maker (owner/Target) providing 733 policies to the LIS, (Thomson comments). 735 7. Changed requirement C3 to a MUST, (Thomson comments). 737 8. Added new requirement, C12, "C12. Location URI Lifetime:" as a 738 SHOULD for all, and MUST for possession auth model, (Thomson 739 comments). 741 9. Changed name of requirement C8 to "Location Only", (Thomson 742 comments). 744 10. Reworded C7 and D6 to be less implementation specific, (Thomson 745 comments). 747 11. Changed requirements C11, D11 to SHOULD, (Thomson comments). 749 12. (Section 5:) Removed lead in sentence for readibility, (Thomson 750 comments). 752 13. Remove "pawn ticket" reference - replaced with "possession 753 authorization model", (Thomson comments). 755 14. Added new paragraph to the security section (Thomson, 7/09/08 756 comments). 758 15. Corrected other minor spelling and wording errors and 759 deficiencies (refer to diff 04/03) (-Editor). 761 Changes to this draft in comparison to the previous version (-03 vs. 762 -02): 764 1. Changed wording of section 3 "Overview of Location-by-Reference" 765 (Polk, Thomson, Winterbottom ~ 4/1/08 list comments). 767 2. Added new requirement C4. "Location Information Masking:", based 768 on (Thomson ~4/1/08 list comment). 770 3. Added new requirement C11. "Location URI Use Type:", based on 771 (~4/1/08 list comments). 773 4. Added new requirement D11. "Location URI Use Type:", for deref. 774 based on (~4/1/08 list comments). 776 5. Replaced requirement D8. "Location URI Non-Anonymized" with 777 "Location Information Masking:". 779 Changes to this draft in comparison to the previous version (-02 vs. 780 -01): 782 1. Reworded Introduction (Barnes 12/6 list comments). 784 2. Changed name of "Basic Actors" section to "Overview of Location 785 by Reference" (Barnes). 787 3. Keeping the LCP term away (for now) since it is used as Link 788 Control Protocol elsewhere (IETF). 790 4. Changed formatting of Terminology section (Barnes). 792 5. Requirement C2. changed to indicate that if the URI has a 793 lifetime, it has to have an expiry (Barnes) 795 6. C7. Changed title and wording based on suggested text and dhcp- 796 uri-option example (Polk). 798 7. The new C2 req. describing valid-for, was also added into the 799 deref section, as D6 801 8. Changed C4 based on much list discussion - replaced by 3 new 802 requirements... 804 9. Reworded C5 based on the follow-on C4 thread/discussion on list 805 (~2/18). 807 10. Changed wording of D3 based on suggestion (Barnes). 809 11. Reworded D4 per suggestion (Barnes). 811 12. Changed D5 based on comment (Barnes), and additional title and 812 text changes for clarity. 814 13. Added D9 and D10 per Richard Barnes suggestions - something 815 needed in addition to his own security doc. 817 14. Deleted reference to individual Barnes-loc-sec draft per wg list 818 suggestion (Barnes), but need more text for this draft's security 819 section. 821 Author's Address 823 Roger Marshall (editor) 824 TeleCommunication Systems, Inc. 825 2401 Elliott Avenue 826 2nd Floor 827 Seattle, WA 98121 828 US 830 Phone: +1 206 792 2424 831 Email: rmarshall@telecomsys.com 832 URI: http://www.telecomsys.com