idnits 2.17.1 draft-ietf-ecrit-lost-sync-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 548. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 554. 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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 2, 2008) is 5653 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-04) exists of draft-ietf-ecrit-mapping-arch-03 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT H. Schulzrinne 3 Internet-Draft Columbia U. 4 Intended status: Standards Track H. Tschofenig 5 Expires: May 6, 2009 NSN 6 November 2, 2008 8 Synchronizing Location-to-Service Translation (LoST) Servers 9 draft-ietf-ecrit-lost-sync-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 6, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 The LoST (Location-to-Service Translation) protocol is used to map 43 locations to service URLs. This document defines a set of LoST 44 extensions that allow LoST servers to synchronize their lists of 45 mappings. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Distributing Mappings via and 52 . . . . . . . . . . . . . . . . . . . . 4 53 4. Synchronizing Mapping Stores via and 54 . . . . . . . . . . . . . . . . . . . . 6 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 57 6.1. LoST Synchronization Namespace Registration . . . . . . . 8 58 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 59 8. RelaxNG . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 62 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 64 Intellectual Property and Copyright Statements . . . . . . . . . . 13 66 1. Introduction 68 The LoST (Location-to-Service Translation) protocol [RFC5222] maps 69 geographic locations to service URLs. As specified in the LoST 70 architecture description [I-D.ietf-ecrit-mapping-arch], there are a 71 variety of LoST servers that cooperate to provide a global, scalable 72 and resilient mapping service. The LoST protocol specification only 73 describes the protocol used for individual seeker-originated queries. 74 This document adds LoST operations that allow forest guides, resolver 75 clusters and authoritative servers to synchronize their database of 76 mappings. 78 In the LoST architecture, servers can peer, i.e., have an on-going 79 data exchange relationship. Peering relationships are set up 80 manually, based on local policies. A server can peer with any number 81 of other servers. Forest guides peer with other forest guides; 82 resolvers peer with forest guides and other resolvers (in the same 83 cluster); authoritative mapping servers peer with forest guides and 84 other authoritative servers, either in the same cluster or above or 85 below them in the tree. If the type of LoST role does not matter, we 86 refer to LoST protocol participants as LoST nodes. 88 Authoritative mapping servers push coverage regions "up" the tree, 89 i.e., from child nodes to parent nodes. The child informs the parent 90 of the geospatial or civic region that it covers. 92 The coverage regions of different authoritative servers can overlap. 93 This should only happen if the authoritative servers are 94 misconfigured or if there is a political dispute that involves 95 competing claims for the same region. A server MUST detect such 96 colliding claims and implement a policy to resolve the collision, 97 either through an automated policy mechanism or manual intervention. 99 This extension defines two new requests, and 100 , that allow peering servers to exchange mappings. 101 These requests are used for all peering relationships and always 102 contain mapping entries, but naturally the content of the data 103 exchanged differs. allows a peer to send newer 104 mappings to another peer; with a query, a node can 105 obtain mappings that are newer than those it already has. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 This document reuses terminology introduced by the mapping 114 architecture document [I-D.ietf-ecrit-mapping-arch]. 116 3. Distributing Mappings via and 118 When a LoST node obtains new information that is of interest to its 119 peers, it pushes the new mappings to its peers. This information 120 might arrive through non-LoST means, such as a manual addition to the 121 local mappings database, or through another LoST node, via a 122 request or a described later. 124 Each peer keeps track of which peer it has exchanged which mapping 125 elements with. As discussed in Section 5.1 of [RFC5222], mapping 126 elements are identified by the 'source', 'sourceID' and 'lastUpdated' 127 attributes. A mapping is considered the same if these three 128 attributes match. Nodes never push the same information to the same 129 peer twice. 131 To delete a mapping, the content of the mapping is left empty. The 132 node can delete the mapping from its internal mapping database, but 133 has to remember which peers it has distributed this update to. The 134 'expires' attribute is required, but ignored. If the querier 135 attempts to remove a non-existent mapping, the query is silently 136 ignored. 138 The response to a request is a , 139 currently without additional elements, if the request was successful 140 or an response if the request failed. Only the 141 , , or errors 142 defined in Section 13.1 of [RFC5222] are used. Neither the 143 nor the messages are used for this query. 145 If the set of nodes that are synchronizing their data does not form a 146 tree, it is possible that the same information arrives through 147 several other nodes. This is unavoidable, but generally only imposes 148 a modest overhead. (It would be possible to create a spanning tree 149 in the same fashion as IP multicast, but the complexity does not seem 150 warranted, giving the relatively low volume of data.) 152 A newly received mapping M' replaces an existing mapping M if all of 153 the following conditions hold: 154 1. M'.source equals M.source, ignoring case 155 2. M'.sourceID' equals M.sourceID, ignoring case 156 3. M'.lastUpdated greater or equal to M.lastUpdated 158 An example is shown in Figure 1. In the example, the mappings with 159 sourceId 7e3f40b098c711dbb6060800200c9a66 sourceId 160 7e3f40b098c711dbb606011111111111 are added by the recipient. The 161 last mapping, with source 'nj.us.example' and sourceID 'englewood', 162 is removed. 164 165 169 170 174 175 Leonia Police Department 176 177 urn:service:sos.police 178 180 182 US 183 NJ 184 Leonia 185 07605 186 187 188 sip:police@leonianj.example.org 189 911 190 192 196 197 New York City Police Department 198 199 urn:service:sos.police 200 201 202 203 204 37.775 -122.4194 205 37.555 -122.4194 206 37.555 -122.4264 207 37.775 -122.4264 208 37.775 -122.4194 209 210 211 212 213 sip:nypd@example.com 214 xmpp:nypd@example.com 215 911 216 218 223 224 226 Figure 1: Example 228 In response, the peer performs the necessary operation and updates 229 its mapping database. In particular, it will check whether the 230 querier is authorized to perform the update and whether the elements 231 and attributes contain values that it understands. In our example, a 232 positive response is returned as shown in Figure 2. 234 235 236 238 Figure 2: Example 240 4. Synchronizing Mapping Stores via and 241 243 Instead of pushing mappings to another LoST node, a LoST client can 244 declare all the mappings it has, via a sequence of elements in 245 the , and then obtain any missing or outdated mappings 246 in the . Specifying the existing mappings 247 avoids retransmitting data that the querier has already stored. 249 If the query has no attributes, the 250 contains all mappings that are either newer 251 than the elements or not contained in the sequence of 252 elements. The querier can restrict the mappings returned by adding 253 'source' and 'sourceId' attributes to the query. Only 254 the combinations 255 o source 256 o source, sourceID 257 are allowed. 259 If the 'source' attribute is specified, only mappings with that 260 particular source attribute are considered. Similarly, the 261 'sourceId' attribute restricts mappings to those matching the 262 attribute from the 'source' named. 264 elements MUST only contain the 'source', 'sourceId' and 265 'lastUpdated' attributes that are not contained in the 266 element itself. Extra attributes that do not match the values of the 267 attributes are silently ignored. (This structure 268 reduces the query size for the common case that there are many 269 mappings from the same source.) 271 Processing a message may lead to a successful response 272 in the form of a &tl;getMappingsResponse> or an message. 273 Only the , , , 274 errors defined in [RFC5222] are used. Neither the nor the 275 messages are used for this query. 277 An example request is shown in Figure 3, the corresponding response 278 in Figure 4. In the example, the queried node did not have anything 279 newer for mapping 7e3f40b098c711dbb606011111111111, but did have a 280 mapping with sourceId 7b7c9630-a93b-11dd-ad8b-0800200c9a66 that 281 matched the source parameter 'authoritative.example'. 283 284 286 288 290 Figure 3: Example request 292 293 296 297 303 Englewood Police Department 304 305 urn:service:sos.police 306 307 ... 308 309 sip:police@englewood.example.com 310 911 311 312 313 315 Figure 4: Example 317 5. Security Considerations 319 The LoST security considerations are discussed in [RFC5222]. The 320 operations described in this document involve mutually-trusting LoST 321 nodes. These nodes need to authenticate each other, using mechanisms 322 such as HTTP Digest [RFC2617], HTTP Basic [RFC2617] over TLS 323 [RFC5246] or TLS client and server certificates. Nodes implementing 324 LoST MUST implement HTTP Basic authentication over TLS and MAY 325 implement other authentication mechanisms. 327 6. IANA Considerations 329 6.1. LoST Synchronization Namespace Registration 331 URI: urn:ietf:params:xml:ns:lost1:sync 332 Registrant Contact: IETF ECRIT Working Group, Henning Schulzrinne 333 (hgs@cs.columbia.edu). 335 XML: 337 BEGIN 338 339 341 342 343 345 LoST Synchronization Namespace 346 347 348

Namespace for LoST server synchronization

349

urn:ietf:params:xml:ns:lost1:sync

350

See RFCXXXX 351 [NOTE TO IANA/RFC-EDITOR: 352 Please replace XXXX with the RFC number of this 353 specification.].

354 355 356 END 358 7. Acknowledgments 360 Robins George, Cullen Jennings and Andrew Newton provided helpful 361 input. Jari Urpalainen assisted with the Relax NG schema. 363 8. RelaxNG 365 367 372 374 376 Location-to-Service Translation (LoST) 377 Synchronization Protocol 379 380 381 382 383 384 385 387 388 389 390 391 392 393 395 396 397 399 400 401 402 403 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 424 425 427 428 429 430 431 433 435 436 438 439 440 441 442 444 445 446 447 448 449 450 451 453 454 455 456 457 458 459 460 461 462 463 465 467 9. References 469 9.1. Normative References 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, March 1997. 474 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 475 Leach, P., Luotonen, A., and L. Stewart, "HTTP 476 Authentication: Basic and Digest Access Authentication", 477 RFC 2617, June 1999. 479 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 480 Tschofenig, "LoST: A Location-to-Service Translation 481 Protocol", RFC 5222, August 2008. 483 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 484 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 486 9.2. Informative References 488 [I-D.ietf-ecrit-mapping-arch] 489 Schulzrinne, H., "Location-to-URL Mapping Architecture and 490 Framework", draft-ietf-ecrit-mapping-arch-03 (work in 491 progress), September 2007. 493 Authors' Addresses 495 Henning Schulzrinne 496 Columbia University 497 Department of Computer Science 498 450 Computer Science Building 499 New York, NY 10027 500 US 502 Phone: +1 212 939 7004 503 Email: hgs+ecrit@cs.columbia.edu 504 URI: http://www.cs.columbia.edu 506 Hannes Tschofenig 507 Nokia Siemens Networks 508 Linnoitustie 6 509 Espoo 02600 510 Finland 512 Phone: +358 (50) 4871445 513 Email: Hannes.Tschofenig@gmx.net 514 URI: http://www.tschofenig.priv.at 516 Full Copyright Statement 518 Copyright (C) The IETF Trust (2008). 520 This document is subject to the rights, licenses and restrictions 521 contained in BCP 78, and except as set forth therein, the authors 522 retain all their rights. 524 This document and the information contained herein are provided on an 525 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 526 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 527 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 528 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 529 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 530 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 532 Intellectual Property 534 The IETF takes no position regarding the validity or scope of any 535 Intellectual Property Rights or other rights that might be claimed to 536 pertain to the implementation or use of the technology described in 537 this document or the extent to which any license under such rights 538 might or might not be available; nor does it represent that it has 539 made any independent effort to identify any such rights. Information 540 on the procedures with respect to rights in RFC documents can be 541 found in BCP 78 and BCP 79. 543 Copies of IPR disclosures made to the IETF Secretariat and any 544 assurances of licenses to be made available, or the result of an 545 attempt made to obtain a general license or permission for the use of 546 such proprietary rights by implementers or users of this 547 specification can be obtained from the IETF on-line IPR repository at 548 http://www.ietf.org/ipr. 550 The IETF invites any interested party to bring to its attention any 551 copyrights, patents or patent applications, or other proprietary 552 rights that may cover technology that may be required to implement 553 this standard. Please address the information to the IETF at 554 ietf-ipr@ietf.org. 556 Acknowledgment 558 Funding for the RFC Editor function is provided by the IETF 559 Administrative Support Activity (IASA).