idnits 2.17.1 draft-ietf-geopriv-lbyr-requirements-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 632. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 645. 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 Copyright Line does not match the current year == Line 83 has weird spacing: '...ference clien...' == Line 212 has weird spacing: '...ication model...' == Line 213 has weird spacing: '...ference proto...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2008) is 5905 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-05 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-06 == Outdated reference: A later version (-11) exists of draft-ietf-geopriv-loc-filters-01 == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-14 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-09 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 7 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 25, 2008 5 Expires: August 28, 2008 7 Requirements for a Location-by-Reference Mechanism 8 draft-ietf-geopriv-lbyr-requirements-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 28, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document defines terminology and provides requirements relating 42 to Location-by-Reference approach using a location URI to handle 43 location information within signaling and other Internet messaging. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 3. Overview of Location-by-Reference . . . . . . . . . . . . . . 6 50 4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 9 51 4.1. Requirements for a Location Configuration Protocol . . . 9 52 4.2. Requirements for a Location Dereference Protocol . . . . 11 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 55 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 56 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 57 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 58 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 59 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 18 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 61 Intellectual Property and Copyright Statements . . . . . . . . . . 20 63 1. Introduction 65 Location-based services rely on ready access to location information, 66 which can be through a direct or indirect mechanism. While there are 67 mechanisms for providing location directly, (e.g., as part of the SIP 68 signaling protocol), an alternative mechanism has been developed for 69 handling location indirectly, via a location reference, a pointer to 70 the actual location information. This reference is called a location 71 URI, and is used by the mechanism we generally call the Location-by- 72 Reference mechanism, or simply, LbyR. 74 The use of a location URI is generally applied in one of the 75 following ways: 77 1. Creation/allocation of a location URI, by a location server based 78 on some request mechanism. 80 2. As part of a Location Configuration Protocol, between a target 81 and location server*. 83 3. The location dereference process, (between a dereference client 84 and dereference server). 86 4. Cancellation/expiration of a location URI, by a location server 87 based on either a direct target request or some other action (e.g., 88 timer). 90 *In this document, we make no differentiation between a LS, per 91 RFC3693, and a LIS, but may refer to either of them as a location 92 server interchangeably. 94 These four things fall under two general protocol mechanisms, 95 location configuration protocols and location dereference protocols. 97 A fifth use of location URI is within the context of what is called 98 location conveyance. Location conveyance is defined as part of the 99 SIP protocol, and is out of scope for this document. (see 100 [I-D.ietf-sip-location-conveyance] for an explanation of conveyance 101 of location using a location URI. 103 The issues around location configuration protocols have been 104 documented in a location configuration protocol problem statement and 105 requirements document [I-D.ietf-geopriv-l7-lcp-ps]. 107 There are currently a several examples of a location configuration 108 protocol. These include DHCP, LLDP-MED, and HELD 109 [I-D.ietf-geopriv-http-location-delivery]) protocols. 111 The structure of this document includes terminology, Section 2, 112 followed by a discussion of the basic elements that surround how a 113 location URI is used. These elements, or actors, are discussed in an 114 overview section, Section 3, accompanied by a graph and associated 115 processing steps. 117 Requirements are outlined accordingly, separated as location 118 configuration requirements, Section 4.1, and location dereference 119 requirements, Section 4.2. 121 In contrast to using a location URI as the mechanism to support a 122 Location-by-Reference model, it may be worth mentioning the common 123 alternative model, that of Location-by-Value (LbyV), which provides 124 location directly. LbyV uses a location object, (e.g., a PIDF-LO, 125 [RFC4119]) within SIP signaling. Using the LbyV model for location 126 configuration is considered out of scope for this document (see 127 [I-D.ietf-sip-location-conveyance] for an explanation of location 128 conveyance for either LbyR or LbyV scenarios. 130 Location determination, different than location configuration or 131 dereferencing, often includes topics related to manual provisioning 132 processes, automated measurements, and/or location transformations, 133 (e.g., geo-coding), and are beyond the scope of this document. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 This document reuses the terminology of [RFC3693], such as Location 142 Server (LS), Location Recipient (LR), Rule Maker (RM), Target, 143 Location Generator (LG), Location Object (LO), and Using Protocol: 145 Location-by-Value (LbyV): The mechanism of representing location 146 either in configuration or conveyance protocols, (i.e., the actual 147 included location value). 149 Location-by-Reference (LbyR): The mechanism of representing location 150 by means of a location URI for use in either a location 151 configuration, conveyance, or dereferencing protocol, and which 152 refers to a fully specified location. 154 Location Configuration Protocol: A protocol which is used by a 155 client to acquire either location or a location URI from a 156 location configuration server, based on information unique to the 157 client. 159 Location Dereference Protocol: A protocol which is used by a client 160 to query a location dereference server, based on location URI 161 input and which returns location information. 163 Location URI: An identifier which serves as a pointer to a location 164 record on a remote host (e.g., LIS). Used within an Location-by- 165 Reference mechanism, a location URI is provided by a location 166 configuration server, and is used as input by a dereference 167 protocol to retrieve location from a dereference server. 169 3. Overview of Location-by-Reference 171 In mobile wireless networks it is not efficient for the end host to 172 periodically query the LIS for up-to-date location information. This 173 is especially the case when power is a constraint or a location 174 update is not immediately needed. Furthermore, the end host might 175 want to delegate the task of retrieving and publishing location 176 information to a third party, such as to a presence server. Finally, 177 in some deployments, the network operator may not want to make 178 location information widely available. 180 Different location scenarios, such as whether a Target is mobile and 181 whether a mobile device needs to be located on demand or according to 182 some pre-determined interval motivated the introduction of the LbyR 183 concept. Depending on the type of reference, such as HTTP/HTTPS or 184 SIP Presence URI, different operations can be performed. While an 185 HTTP/HTTPS URI can be resolved to location information, a SIP 186 Presence URI provides further benefits from the SUBSCRIBE/NOTIFY 187 concept that can additionally be combined with location filters 188 [I-D.ietf-geopriv-loc-filters]. 190 +-----------+ Geopriv +-----------+ 191 | | Location | Location | 192 | LIS +---------------+ Recipient | 193 | | Dereference | | 194 +-+---+-----+ Protocol (3) +----+------+ 195 * | -- 196 Rulemaker * | Geopriv -- 197 Policy * | Location -- 198 Exchange * | Configuration -- 199 (1b) * | Protocol -- 200 * | (1a) -- Geopriv 201 * | -- Using Protocol 202 + - - - -*- - - - - -|- - - -+ -- (e.g., SIP) 203 |+------+----+ +-----+-----+ |-- (2) 204 | Rulemaker | | Target / |-- 205 || / owner | | End Host + | 206 | | | | 207 |+-----------+ +-----------+ | 209 | User of Target | 210 + - - - - - - - - - - - - - -+ 212 Figure 1: Shows the assumed communication model for both a layer 7 213 location configuration protocol and a dereference protocol: 215 Figure 1: Shows the assumed communication model for both a layer 7 216 location configuration protocol and a location dereference protocol. 218 (1a). Target requests reference from server; and receives back, a 219 location URI in server response 221 (1b). Rulemaker policy is consulted (interface out of scope) 223 (2). Target conveys reference to recipient (out of scope) 225 (3). Recipient dereferences location URI, by a choice of methods, 226 including a request/response (e.g., HTTP) or publish/subscription 227 (e.g., SIP SUBSCRIBE/NOTIFY) 229 Note A. There is no requirement for using the same protocol in (1a) 230 and (3). 232 Note B. Figure 1 includes the interaction between the owner of the 233 Target and the LIS to establish Rulemaker policies. This is 234 communications path (1b). This interaction needs to be done before 235 the LIS will authorize anything of than default policies to a 236 dereference request for location of the Target. 238 Note C. that the Target may take on the role of the Location 239 Recipient whereby it would dereference the location URI to obtain its 240 own location information. 242 An example scenario of how this might work, is where the Target 243 obtains a location URI in the form of a subscription URI (e.g., a SIP 244 URI) via HELD, (a Geopriv layer 7 location configuration protocol). 245 Since, in this case the Target equals Recipient, then the Target can 246 subscribe to the URI in order to be notified of its current location 247 based on subscription parameters (see 248 [I-D.ietf-geopriv-loc-filters]). Additionally, a geospatial boundary 249 can be expressed (ref. [I-D.ietf-geopriv-policy]), so that the 250 Target/Recipient will get its updated location notification once it 251 crosses the specified boundary. 253 Location URIs may have an life expiration associated to them, so the 254 LIS needs to be able to keep track of the location URIs that have 255 been handed out, in addition, to also know about validity information 256 for each location URI. Location URIs need to expire to prevent the 257 recipient of such a URI from being able to (in some cases) 258 permanently track a host. Another example of the usefulness of an 259 expiration mechanism is to offer garbage collection capabilities to 260 the LIS. 262 It is important to prevent adversaries from obtaining any information 263 about a Target through the location URI itself, or even a Target's 264 location if the owner of the Target wants to protect it. Therefore, 265 each location URI must be constructed with security safeguards in 266 mind. There are two general cases assumed, both having to do with 267 the form of the location URI when it is created. 269 Case 1. Where access to the location URI is limited by policy: This 270 is the case where the LIS applies authentication and access 271 control at location configuration step and again at the 272 dereference step. In this case, the URI can be of any form chosen 273 by the LIS. 275 Case 2. Access limited by distribution: The LIS does not apply 276 authentication and access control at the time that the location 277 URI is dereferenced. In this case, the location URI must be 278 difficult to guess (so that possession can be used to imply 279 authorization). 281 4. High-Level Requirements 283 This document outlines the requirements for an Location by Reference 284 mechanism which can be used by a number of underlying protocols. 285 Requirements here address two general types of such protocols, a 286 general location configuration protocol, and a general location 287 dereferencing protocol. Given that either of these two general 288 protocols can take the form of different protocols implementations 289 for either location configuration vs. location dereference, (e.g., 290 HELD/DHCP/LLDP-MED, vs. HTTP GET/SIP SUBSCRIBE/NOTIFY, respectively). 291 Because each of these specific protocol implementations has its own 292 unique client and server interactions, the requirements here are not 293 intended to state what a client or server is expected to do, but 294 rather which requirements must be met separately by either a location 295 configuration protocol, or a location dereference protocol, for the 296 purposes of using a location URI. 298 The requirements are broken into two sections. 300 4.1. Requirements for a Location Configuration Protocol 302 Below, we summarize high-level design requirements needed for a 303 location-by-reference mechanism as used within the location 304 configuration protocol. 306 C1. Location URI support: The configuration protocol MUST support a 307 location reference in URI form. 309 Motivation: It is helpful to have a consistent form of key for the 310 LbyR mechanism. 312 C2. Location URI expiration: When a location URI has a limited 313 validity interval, its lifetime MUST be indicated. 315 Motivation: A location URI may not intend to represent a location 316 forever, and the identifier eventually may need to be recycled, or 317 may be subject to a specific window of validity, after which the 318 location reference fails to yield a location, or the location is 319 determined to be kept confidential. 321 C3. Location URI cancellation: The location configuration protocol 322 SHOULD support the ability to request a cancellation of a specific 323 location URI. 325 Motivation: If the client determines that in its best interest to 326 destroy the ability for a location URI to effectively be used to 327 dereference a location, then there should be a way to nullify the 328 location URI. 330 C4. [Deleted, replaced by C8,C9,C10]: 332 C5. User Identity Protection: The location URI MUST NOT contain any 333 user identifying information that identifies the user, device or 334 address of record, (e.g., which includes phone extensions, badge 335 numbers, first or last names, etc.), within the URI form. 337 Motivation: It is important to protect caller identity or contact 338 address from being included in the form of the location URI itself 339 when it is generated. 341 C6. Reuse indicator: There SHOULD be a way to allow a client to 342 control whether a location URI can be resolved once only, or 343 multiple times. 345 Motivation: The client requesting a location URI may request a 346 location URI which has a 'one-time-use' only characteristic, as 347 opposed to a location URI having multiple reuse capability. 349 C7. Location URI Valid-for: A location URI validity interval, if 350 used, MUST include the validity time, in seconds, as an indication 351 of how long the client can consider a location URI to be valid. 353 Motivation: It is important to be able to determine how long a 354 location URI is to remain useful for, and when it must be 355 refreshed. 357 C8. Location URI Anonymous: The location URI MUST NOT reveal any 358 information about the Target other than it's location. 360 Motivation: A user should have the option to control how much 361 information is revealed about them. This provides that control by 362 not forcing the inclusion of other information with location, 363 (e.g., to not include any identification information in the 364 location URI.) 366 C9. Location URI Not guessable: Location URIs that do not require 367 authentication and authorization MUST NOT be guessable, based on 368 the use of a cryptographically random sequence somewhere within 369 the URI. (Note that the number of bits depends to some extent on 370 the number of active location URIs that might exist at the one 371 time; 128-bit is most likely enough for the short term.) 373 Motivation: Location URIs without access control reveal private 374 information, and a guessable location URI could be easily 375 exploited to obtain private information. 377 C10. Location URI Optional: In the case of user-provided 378 authorization policies, where anonymous or non-guessable location 379 URIs are not warranted, the location configuration protocol MAY 380 support optional location URI forms. 382 Motivation: Users don't always have such strict privacy 383 requirements, but may opt to specify their own location URI, or 384 components thereof. 386 4.2. Requirements for a Location Dereference Protocol 388 Below, we summarize high-level design requirements needed for a 389 location-by-reference mechanism as used within the location 390 dereference protocol. 392 D1. Location URI support: The location dereference protocol MUST 393 support a location reference in URI form. 395 Motivation: It is required that there be consistency of use 396 between location URI formats used in an configuration protocol and 397 those used by a dereference protocol. 399 D2. Location URI expiration indicator: The location dereference 400 protocol MUST support an indicator showing that, if it is the 401 case, that a location URI is no longer valid due to expiration. 403 Motivation: Location URIs are expected to expire, based on 404 location configuration protocol parameters, and it is therefore 405 useful to convey the expired status of the location URI in the 406 location dereference protocol. 408 D3. Authentication: The location dereference protocol MUST include 409 mechanisms to authenticate both the client and the server. 411 Motivation: Although the implementations must support 412 authentication of both parties, any given transaction has the 413 option not to authenticate one or both parties. 415 D4. Dereferenced Location Form: The value returned by the 416 dereference protocol MUST contain a well-formed PIDF-LO document. 418 Motivation: This is in order to ensure that adequate privacy rules 419 can be adhered to, since the PIDF-LO format comprises the 420 necessary structures to maintain location privacy. 422 D5. Location URI Repeated Use: The location dereference protocol 423 MUST support the ability for the same location URI to be resolved 424 more than once, based on dereference server configuration. 426 Motivation: Through dereference server configuration, for example, 427 it may be useful to not only allow more than one dereference 428 request, but, in some cases, to also limit the number of 429 dereferencing attempts by a client. 431 D6. Location URI Valid-for: A location URI validity interval, if 432 used, MUST include the validity time, in seconds, as an indication 433 of how long the client can consider a location URI to be valid. 435 Motivation: It is important to be able to determine how long a 436 location URI is to remain useful when dereferencing a location 437 URI. 439 D7. Location URI anonymized: Any location URI whose dereference will 440 not be subject to authentication and access control MUST be 441 anonymized. 443 Motivation: The dereference protocol must define an anonymized 444 format for location URIs. This format must identify the desired 445 location information via a random token with at least 128 bits of 446 entropy (rather than some kind of explicit identifier, such as an 447 IP address). 449 D8. Location URI non-anonymized: The dereference protocol MAY define 450 a more general, non-anonymized URI format. 452 Motivation: Only location URIs for which dereference is subject to 453 access-control policy by the LIS may use this format. 455 D9. Location Privacy: The location dereference protocol MUST support 456 the application of privacy rules to the dissemination of a 457 requested location object. 459 Motivation: The dereference server must obey all provisioned 460 privacy rules that apply to a requested location object. 462 D10. Location Confidentiality: The dereference protocol MUST 463 support encryption of messages sent between the location 464 dereference client and the location dereference server, and MAY 465 alternatively provide messaging unencrypted. 467 Motivation: Environmental and local configuration policy will 468 guide the requirement for encryption for certain transactions. In 469 some cases, encryption may be the rule, in others, it may be 470 acceptable to send and receive messages without encryption. 472 5. Security Considerations 474 The LbyR mechanism currently addresses security issues as follows. 476 A location URI, regardless of its construction, if public, implies 477 no safeguard against anyone being able to dereference and get the 478 location. The method of constructing a location URI in its naming 479 does help prevent some potential guessing, according to some 480 defined pattern. In the instance of one-time-use location URIs, 481 which function similarly to a pawn ticket, the argument can be 482 made that with a pawn ticket, possession implies permission, and 483 location URIs which are public are protected only by privacy rules 484 enforced at the dereference server. 486 6. IANA Considerations 488 This document does not require actions by the IANA. 490 7. Acknowledgements 492 We would like to thank the IETF GEOPRIV working group chairs, Andy 493 Newton, Allison Mankin and Randall Gellens, for creating the design 494 team which initiated this requirements work. We'd also like to thank 495 those design team participants for their inputs, comments, and 496 reviews. The design team included the following folks: Richard 497 Barnes; Martin Dawson; Keith Drage; Randall Gellens; Ted Hardie; 498 Cullen Jennings; Marc Linsner; Rohan Mahy; Allison Mankin; Roger 499 Marshall; Andrew Newton; Jon Peterson; James M. Polk; Brian Rosen; 500 John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes 501 Tschofenig; Martin Thomson; and James Winterbottom. 503 8. References 505 8.1. Normative References 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, March 1997. 510 8.2. Informative References 512 [I-D.ietf-geopriv-http-location-delivery] 513 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 514 "HTTP Enabled Location Delivery (HELD)", 515 draft-ietf-geopriv-http-location-delivery-05 (work in 516 progress), February 2008. 518 [I-D.ietf-geopriv-l7-lcp-ps] 519 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 520 Location Configuration Protocol; Problem Statement and 521 Requirements", draft-ietf-geopriv-l7-lcp-ps-06 (work in 522 progress), November 2007. 524 [I-D.ietf-geopriv-loc-filters] 525 Mahy, R., "A Document Format for Filtering and Reporting 526 Location Notications in the Presence Information Document 527 Format Location Object (PIDF-LO)", 528 draft-ietf-geopriv-loc-filters-01 (work in progress), 529 March 2007. 531 [I-D.ietf-geopriv-policy] 532 Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 533 and J. Polk, "Geolocation Policy: A Document Format for 534 Expressing Privacy Preferences for Location Information", 535 draft-ietf-geopriv-policy-14 (work in progress), 536 February 2008. 538 [I-D.ietf-sip-location-conveyance] 539 Polk, J. and B. Rosen, "Location Conveyance for the 540 Session Initiation Protocol", 541 draft-ietf-sip-location-conveyance-09 (work in progress), 542 November 2007. 544 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 545 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 547 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 548 Format", RFC 4119, December 2005. 550 Appendix A. Change log 552 Changes to this draft in comparison to the previous version (-02 vs. 553 -01): 555 1. Reworded Introduction (Barnes 12/6 list comments). 557 2. Changed name of "Basic Actors" section to "Overview of Location 558 by Reference" (Barnes). 560 3. Keeping the LCP term away (for now) since it is used as Link 561 Control Protocol elsewhere (IETF). 563 4. Changed formatting of Terminology section (Barnes). 565 5. Requirement C2. changed to indicate that if the URI has a 566 lifetime, it has to have an expiry (Barnes) 568 6. C7. Changed title and wording based on suggested text and dhcp- 569 uri-option example (Polk). 571 7. The new C2 req. describing valid-for, was also added into the 572 deref section, as D6 574 8. Changed C4 based on much list discussion - replaced by 3 new 575 requirements... 577 9. Reworded C5 based on the follow-on C4 thread/discussion on list 578 (~2/18). 580 10. Changed wording of D3 based on suggestion (Barnes). 582 11. Reworded D4 per suggestion (Barnes). 584 12. Changed D5 based on comment (Barnes), and additional title and 585 text changes for clarity. 587 13. Added D9 and D10 per Richard Barnes suggestions - something 588 needed in addition to his own security doc. 590 14. Deleted reference to individual Barnes-loc-sec draft per wg list 591 suggestion (Barnes), but need more text for this draft's security 592 section. 594 Author's Address 596 Roger Marshall (editor) 597 TeleCommunication Systems, Inc. 598 2401 Elliott Avenue 599 2nd Floor 600 Seattle, WA 98121 601 US 603 Phone: +1 206 792 2424 604 Email: rmarshall@telecomsys.com 605 URI: http://www.telecomsys.com 607 Full Copyright Statement 609 Copyright (C) The IETF Trust (2008). 611 This document is subject to the rights, licenses and restrictions 612 contained in BCP 78, and except as set forth therein, the authors 613 retain all their rights. 615 This document and the information contained herein are provided on an 616 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 617 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 618 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 619 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 620 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 621 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 623 Intellectual Property 625 The IETF takes no position regarding the validity or scope of any 626 Intellectual Property Rights or other rights that might be claimed to 627 pertain to the implementation or use of the technology described in 628 this document or the extent to which any license under such rights 629 might or might not be available; nor does it represent that it has 630 made any independent effort to identify any such rights. Information 631 on the procedures with respect to rights in RFC documents can be 632 found in BCP 78 and BCP 79. 634 Copies of IPR disclosures made to the IETF Secretariat and any 635 assurances of licenses to be made available, or the result of an 636 attempt made to obtain a general license or permission for the use of 637 such proprietary rights by implementers or users of this 638 specification can be obtained from the IETF on-line IPR repository at 639 http://www.ietf.org/ipr. 641 The IETF invites any interested party to bring to its attention any 642 copyrights, patents or patent applications, or other proprietary 643 rights that may cover technology that may be required to implement 644 this standard. Please address the information to the IETF at 645 ietf-ipr@ietf.org. 647 Acknowledgment 649 Funding for the RFC Editor function is provided by the IETF 650 Administrative Support Activity (IASA).