idnits 2.17.1 draft-ietf-ecrit-lost-sync-00.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 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 414. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 427. 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 (July 7, 2008) is 5765 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) == Outdated reference: A later version (-04) exists of draft-ietf-ecrit-mapping-arch-03 Summary: 1 error (**), 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 July 7, 2008 5 Expires: January 8, 2009 7 Synchronizing Location-to-Service Translation (LoST) Servers 8 draft-ietf-ecrit-lost-sync-00.txt 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 January 8, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 The LoST (Location-to-Service Translation) protocol is used to map 42 locations to service URLs. This document defines a set of LoST 43 extensions that allow LoST servers to synchronize their lists of 44 mappings. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Distributing Mappings via . . . . . . . 4 51 4. Synchronizing Mapping Stores via and 52 . . . . . . . . . . . . . . . . . . . . 6 53 5. Synchronizing Mapping Stores via and 54 . . . . . . . . . . . . . . . . . . . . 6 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 57 7.1. LoST Synchronization Namespace Registration . . . . . . . 9 58 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 59 9. RelaxNG . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 62 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 Intellectual Property and Copyright Statements . . . . . . . . . . 11 66 1. Introduction 68 The LoST (Location-to-Service Translation) protocol [2] maps 69 geographic locations to service URLs. As specified in the LoST 70 architecture description [3], there are a variety of LoST servers 71 that cooperate to provide a global, scalable and resilient mapping 72 service. The LoST protocol specification only describes the protocol 73 used for individual seeker-originated queries. This document adds 74 LoST operations that allow forest guides, resolver clusters and 75 authoritative servers to synchronize their database of mappings. 77 In the LoST architecture, servers can peer, i.e., have an on-going 78 data exchange relationship. Peering relationships are set up 79 manually, based on local policies. A server can peer with any number 80 of other servers. Forest guides peer with other forest guides; 81 resolvers peer with forest guides and other resolvers (in the same 82 cluster); authoritative mapping servers peer with forest guides and 83 other authoritative servers, either in the same cluster or above or 84 below them in the tree. If the type of LoST role does not matter, we 85 refer to LoST protocol participants as LoST nodes. 87 Authoritative mapping servers push coverage regions "up" the tree, 88 i.e., from child nodes to parent nodes. The child informs the parent 89 of the geospatial or civic region that it covers. 91 The coverage regions of different authoritative servers can overlap. 92 This should only happen if the authoritative servers are 93 misconfigured or if there is a political dispute that involves 94 competing claims for the same region. A server MUST detect such 95 colliding claims and implement a policy to resolve the collision, 96 either through an automated policy mechanism or manual intervention. 98 This extension defines two new requests, and 99 , that allow peering servers to exchange 100 mappings. These requests are used for all peering relationships and 101 always contain mapping entries, but naturally the content of the data 102 exchanged differs. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [1]. 110 This document reuses terminology introduced by the mapping 111 architecture document [3]. 113 3. Distributing Mappings via 115 When a LoST node obtains new information that is of interest to its 116 peers, it pushes the new mappings to its peers. This information 117 might arrive through non-LoST means, such as a manual addition to the 118 local mappings database, or through another LoST node, via a 119 request or a described later. 120 Mappings in that request replace existing mappings with the same 'id' 121 parameter and a more recent 'created' parameter. (Enforcing the 122 latter avoids that a crashed node that wakes up injects outdated 123 information into the system.) 125 Each peer keeps track of which peer it has exchanged which mapping 126 elements with. Mapping elements are identified by the 'source', 127 'sourceID' and 'lastUpdated' parameters. A mapping is considered the 128 same if these three attributes match. Nodes never push the same 129 information to the same peer twice. 131 Instead of providing the mappings themselves, the LoST client can 132 include references to mappings that have changed since the last 133 request, by including entries. The server then requests any out- 134 of-date or missing mappings by including a subset of that list as 135 elements in a request. 137 To delete a mapping, the content of the mapping is left empty. The 138 node can delete the mapping from its internal mapping database, but 139 has to remember which peers it has distributed this update to. The 140 mapping is identified only by the 'sourceId' and 'source' parameters; 141 the other parameters are ignored if present. In other words, the 142 delete operation affects all versions of a mapping. 144 The response to is . It 145 only contains elements if there is an error condition. Only 146 the .... errors are defined (TBD). 148 If the set of nodes that are synchronizing their data does not form a 149 tree, it is possible that the same information arrives through 150 several other nodes. This is unavoidable, but generally only imposes 151 a modest overhead. (It would be possible to create a spanning tree 152 in the same fashion as IP multicast, but the complexity does not seem 153 warranted, giving the relatively low volume of data.) 155 An example is shown in Figure 1. In the example, the last mapping, 156 with source nj.us.example and mapping ID 'englewood', is being 157 removed. 159 160 161 162 165 166 Leonia Police Department 167 168 urn:service:sos.police 169 171 173 US 174 NJ 175 Leonia 176 07605 177 178 179 sip:police@leonianj.example.org 180 911 181 183 188 189 New York City Police Department 190 191 urn:service:sos.police 192 193 194 195 196 37.775 -122.4194 197 37.555 -122.4194 198 37.555 -122.4264 199 37.775 -122.4264 200 37.775 -122.4194 201 202 203 204 205 sip:nypd@example.com 206 xmpp:nypd@example.com 207 911 209 211 213 214 216 217 218 220 Figure 1: Example pushMappingsRequest and pushMappingsResponse 222 4. Synchronizing Mapping Stores via and 223 225 Get list of mappings identified by elements. The server may not 226 be able to return all such mappings, but the client can easily tell 227 which mappings were unavailable since it can compare the mapping 228 identifiers to those returned in the mapping elements. 230 Errors TBD. 232 5. Synchronizing Mapping Stores via and 233 235 While the request allows new mappings to 236 propagate, it does not allow a newly-arriving node to acquire all 237 mappings maintained by another node. Therefore, we introduce 238 and to synchronize two 239 mapping stores. A LoST node wanting to synchronize its mapping store 240 with another node issues a , containing an 241 enumeration of the current mapping sources, source identifiers and 242 versions in elements. The recipient of the request compares that 243 list to its own list of mappings. It then returns an unordered set 244 of mappings that are more recent than the ones identified in the 245 . It also returns any mappings that it knows 246 about that are not contained in the list at all. Thus, a querier can 247 get the complete listing of mappings by omitting 'm' elements 248 altogether. 250 The querier can limit the scope of the mappings returned by adding 251 'source', 'sourceId', and 'lastUpdated' attributes to 252 . If the 'source' attribute is specified, only 253 mappings with that particular source attribute are considered. 255 Similarly, the 'sourceId' attribute restricts mappings to those 256 matching the attribute. If 'sourceId' is specified, the 'source' 257 attribute also needs to be provided, since the 'sourceId' attribute 258 is only defined for a particular source. Similarly, if 'lastUpdated' 259 is specified, 'source' and 'sourceId' need to be specified as well. 260 In other words, a querier cannot ask for all mappings last updated 261 today regardless of source, for example. 'm' elements that do not 262 match the attributes are silently ignored. 264 Errors TBD. 266 An example request and response is shown in Figure 2 267 268 270 272 274 276 277 279 280 285 286 New York City Police Department 287 288 urn:service:sos.police 289 290 291 292 293 37.775 -122.4194 294 37.555 -122.4194 295 37.555 -122.4264 296 37.775 -122.4264 297 37.775 -122.4194 298 299 300 301 302 sip:nypd@ny.example.com 303 xmpp:nypd@example.com 304 911 305 306 307 309 Figure 2: Example getMappingsRequest and getMappingsResponse 311 6. Security Considerations 313 The LoST security considerations are discussed in [2]. The 314 operations described in this document involve mutually-trusting LoST 315 nodes. These nodes need to authenticate each other, using mechanisms 316 such as HTTP Digest, HTTP Basic over TLS or TLS client and server 317 certificates. Nodes implementing LoST MUST implement HTTP Basic 318 authentication over TLS and MAY implement other authentication 319 mechanisms. 321 7. IANA Considerations 323 7.1. LoST Synchronization Namespace Registration 325 URI: urn:ietf:params:xml:ns:lost1:sync 326 Registrant Contact: IETF ECRIT Working Group, Henning Schulzrinne 327 (hgs@cs.columbia.edu). 328 XML: 330 BEGIN 331 332 334 335 336 338 LoST Synchronization Namespace 339 340 341

Namespace for LoST server synchronization

342

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

343

See RFCXXXX 344 [NOTE TO IANA/RFC-EDITOR: 345 Please replace XXXX with the RFC number of this 346 specification.].

347 348 349 END 351 8. Acknowledgments 353 Andrew Newton and Cullen Jennings provided helpful input. 355 9. RelaxNG 357 TBD 359 10. References 361 10.1. Normative References 363 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 364 Levels", BCP 14, RFC 2119, March 1997. 366 [2] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, 367 "LoST: A Location-to-Service Translation Protocol", 368 draft-ietf-ecrit-lost-10 (work in progress), May 2008. 370 10.2. Informative References 372 [3] Schulzrinne, H., "Location-to-URL Mapping Architecture and 373 Framework", draft-ietf-ecrit-mapping-arch-03 (work in progress), 374 September 2007. 376 Author's Address 378 Henning Schulzrinne 379 Columbia University 380 Department of Computer Science 381 450 Computer Science Building 382 New York, NY 10027 383 US 385 Phone: +1 212 939 7004 386 Email: hgs+ecrit@cs.columbia.edu 387 URI: http://www.cs.columbia.edu 389 Full Copyright Statement 391 Copyright (C) The IETF Trust (2008). 393 This document is subject to the rights, licenses and restrictions 394 contained in BCP 78, and except as set forth therein, the authors 395 retain all their rights. 397 This document and the information contained herein are provided on an 398 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 399 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 400 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 401 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 402 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 403 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 405 Intellectual Property 407 The IETF takes no position regarding the validity or scope of any 408 Intellectual Property Rights or other rights that might be claimed to 409 pertain to the implementation or use of the technology described in 410 this document or the extent to which any license under such rights 411 might or might not be available; nor does it represent that it has 412 made any independent effort to identify any such rights. Information 413 on the procedures with respect to rights in RFC documents can be 414 found in BCP 78 and BCP 79. 416 Copies of IPR disclosures made to the IETF Secretariat and any 417 assurances of licenses to be made available, or the result of an 418 attempt made to obtain a general license or permission for the use of 419 such proprietary rights by implementers or users of this 420 specification can be obtained from the IETF on-line IPR repository at 421 http://www.ietf.org/ipr. 423 The IETF invites any interested party to bring to its attention any 424 copyrights, patents or patent applications, or other proprietary 425 rights that may cover technology that may be required to implement 426 this standard. Please address the information to the IETF at 427 ietf-ipr@ietf.org. 429 Acknowledgment 431 Funding for the RFC Editor function is provided by the IETF 432 Administrative Support Activity (IASA).